CalendarGadget Bug oder Feature

[hjbremer]

Beim 1.Aufruf eines Calendargadgets wird das aktuelle Datum markiert.
Nun drückt man via Mausclick darauf um es ins Stringgadget zu schieben
und siehe da, nix passiert.
Man muß erst ein anderes Datum anklicken und dann wieder das Aktuelle damit es im Gadget erscheint.

Code: Alles auswählen

#win = 10
#gad = 11
#cal = 12

If OpenWindow(#win, 0, 0, 250, 250, "CalendarGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
   CalendarGadget(#cal, 10, 10, 230, 180) 
   StringGadget(#gad, 10, 200, 230, 24, "")
   
     
   Repeat
     Event = WaitWindowEvent()
     
     Select Event
     
       Case #PB_Event_Gadget
         Select EventGadget()
            Case #cal 
               Debug "ein Event"
               
                  SetGadgetText(#gad, FormatDate("%dd.%mm.%yy", GetGadgetState(#cal)))
                         
         EndSelect
       
     EndSelect
   Until Event = #PB_Event_CloseWindow

  EndIf

PS: kann man natürlich mittels Callback reparieren, aber muß das so sein ?

[RSBasic]

Der Grund ist, du kannst nicht auf ein Datum klicken, welches bereits ausgewählt wurde. Damit wird sichergestellt, dass keine Duplikate der Events ausgelöst werden. (Wahrscheinlich von PB so gewollt.) D.h. wenn du auf den 20.11. klickst und anschließend erneut, dann hast du genau das gleiche Problem.
Hier ist meine Callback-Version (ja, andere Möglichkeit gibt es nicht), die sogar besser ist, als die von PB, weil mein Callback sogar alle Daten (Mehrzahl von Datum^^) vor 1970 und nach 2038 ermitteln kann:

Code: Alles auswählen

EnableExplicit

#win = 10
#gad = 11
#cal = 12

#MCN_SELCHANGE = #MCN_FIRST + 1
#MCN_SELECT = #MCN_FIRST + 4

Procedure WinCallback(hWnd, uMsg, wParam, lParam)
  Protected *NMHDR.NMHDR
  Protected SYSTEMTIME.SYSTEMTIME
  
  Select uMsg
    Case #WM_NOTIFY
      *NMHDR = lParam
      Select *NMHDR\hwndFrom
        Case GadgetID(#cal)
          Select *NMHDR\code
            Case #MCN_SELECT
              Debug "ein Event"
              SendMessage_(GadgetID(#cal), #MCM_GETCURSEL, 0, SYSTEMTIME)
              SetGadgetText(#gad, Str(SYSTEMTIME\wDay) + "." + Str(SYSTEMTIME\wMonth) + "." + Str(SYSTEMTIME\wYear))
          EndSelect
      EndSelect
  EndSelect
  
  ProcedureReturn #PB_ProcessPureBasicEvents
EndProcedure

If OpenWindow(#win, 0, 0, 500, 400, "Window", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  CalendarGadget(#cal, 10, 10, 200, 200, Date())
  StringGadget(#gad, 10, 200, 230, 24, "")
  
  SetWindowCallback(@WinCallback())
  
  Repeat
    Select WaitWindowEvent()
      Case #PB_Event_CloseWindow
        End
    EndSelect
  ForEver
EndIf

[hjbremer]

Der Grund ist, du kannst nicht auf ein Datum klicken, welches bereits ausgewählt wurde.

Ja aber eben nicht von mir (Anwender) !!!

Ich könnte natürlich vor Aufrufen des CalendarGadgets das dort markierte Datum ins Eingabefeld setzen,

aber 50 prozentig führt das zu falschen Eingaben/Datumsangaben.

Mich stört dieses verhalten.

Noch schlimmer ist aber, das es mir erst jetzt wirklich auffällt.
Liegt aber wohl am Konto-Programm wo man zweimal hinsehen muß was man da einbaut.

[RSBasic]

Ja, es wird beim Start standardmäßig das aktuelle Datum vorausgewählt. Du kannst aber dafür sorgen, dass beim Start automatisch ein Event ausgelöst wird:

Code: Alles auswählen

#win = 10
#gad = 11
#cal = 12

If OpenWindow(#win, 0, 0, 250, 250, "CalendarGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  CalendarGadget(#cal, 10, 10, 230, 180)
  StringGadget(#gad, 10, 200, 230, 24, "")
  
  PostEvent(#PB_Event_Gadget, #win, #cal)
  
  Repeat
    Event = WaitWindowEvent()
    
    Select Event
        
      Case #PB_Event_Gadget
        Select EventGadget()
          Case #cal
            Debug "ein Event"
            
            SetGadgetText(#gad, FormatDate("%dd.%mm.%yy", GetGadgetState(#cal)))
            
        EndSelect
        
    EndSelect
  Until Event = #PB_Event_CloseWindow
  
EndIf

Dann hast du das Problem beim Start nicht und dein Event wird am Anfang immer ausgelöst und das Datum wird in dein StringGadget gesetzt.

[DarkSoul]

Unter Ubuntu geht es wie gewünscht.

Vielleicht auch einfach von vorneherein einmal

Code: Alles auswählen

SetGadgetText(#gad, FormatDate("%dd.%mm.%yy", GetGadgetState(#cal)))

aufrufen, so dass der User gar keinen Anlass hat, das bereits markierte Datum überhaupt nochmal zu klicken.

Und wenn er nochmal klickt, ist es Latte, ob das nochmal das Event auslöst, weil es ist ja bereits gewählt.

Der User denkt höchstwahrscheinlich: Der Tag, den ich will, ist heute - fein! schon vorausgewählt... also gar nichts daran machen und weiter (oder wie auch immer nach Auswahl fortzufahren ist).

[RSBasic]

@DarkSoul
Das Datum ist ja (jedenfalls unter Windows) bereits vorausgewählt und der User muss nicht nochmal klicken, aber darum geht es ja nicht.
Es geht ihm darum, dass er am Anfang kein initiales Event bekommt, weil sein StringGadget am Anfang leer ist und hjbremer möchte, dass beim Programmstart sein StringGadget automatisch mit dem Datum gefüllt wird, ohne dass er das Datum manuell reinschreiben muss.

@hjbremer
Hast du es inzwischen meinen neuen Code getestet? Eine Bestätigung wäre immer schön, ob es auch funktioniert hat und ob man dir auch erfolgreich geholfen hat. Ansonsten ist ein kommentarloses und dankloses Nehmen der Lösung unhöflich oder respektlos, meiner Meinung nach.

[Kiffi]

Seltsamerweise erzeugt das CalendarGadget laut Dokumentation kein von PureBasic per EventType() auswertbares Ereignis.

Siehe: https://www.purebasic.com/documentation ... ttype.html Hier ist das CalendarGadget nicht aufgelistet.

Das einzige Event, das durch das CalendarGadget ausgelöst wird, ist gleich 0, was wohl einem #PB_EventType_LeftClick entsprechen könnte.

Allerdings sollte dieses Ereignis auch dann ausgelöst werden, wenn ein bereits ausgewähltes Datum angeklickt wird (LeftClick) und nicht erst dann, wenn ein anderes Datum ausgewählt wird.

Grüße ... Peter

[RSBasic]

Jupp, es scheint so, dass PB unter Windows nur auf #MCN_SELCHANGE abfragt. Es wäre besser, wenn man auf #MCN_SELECT abfragt, damit auch ein Event ausgelöst wird, wenn man auf das bereits ausgewählte Datum erneut klickt.
So arbeitet PB:

Code: Alles auswählen

EnableExplicit

#win = 10
#gad = 11
#cal = 12

#MCN_SELCHANGE = #MCN_FIRST + 1
#MCN_SELECT = #MCN_FIRST + 4

Procedure WinCallback(hWnd, uMsg, wParam, lParam)
  Protected *NMHDR.NMHDR
  Protected SYSTEMTIME.SYSTEMTIME
 
  Select uMsg
    Case #WM_NOTIFY
      *NMHDR = lParam
      Select *NMHDR\hwndFrom
        Case GadgetID(#cal)
          Select *NMHDR\code
            Case #MCN_SELCHANGE
              Debug "ein Event"
          EndSelect
      EndSelect
  EndSelect
 
  ProcedureReturn #PB_ProcessPureBasicEvents
EndProcedure

If OpenWindow(#win, 0, 0, 500, 400, "Window", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  CalendarGadget(#cal, 10, 10, 200, 200, Date())
  StringGadget(#gad, 10, 200, 230, 24, "")
 
  SetWindowCallback(@WinCallback())
 
  Repeat
    Select WaitWindowEvent()
      Case #PB_Event_CloseWindow
        End
    EndSelect
  ForEver
EndIf

Mit #MCN_SELECT würde jeder Klick ausgewertet werden.

[RSBasic]

Da diese Unterscheidung zwischen Click und Change für mich auch nützlich ist, habe ich im englischen Forum einen Wunsch-Thread erstellst: https://www.purebasic.fr/english/viewto ... =3&t=71797

[hjbremer]

so da bin ich wieder.

Das mit der Vorauswahl ist ja gut gemeint und auch ok, und das man das StringGadget mit diesem Datum beim Programmstart füllen könnte ist ja kein Problem. Genauso wie einen Callback schreiben.

Die Unterscheidung von Click und Change kann schon wichtig sein.

Es störte mich halt das beim 1.Aufruf beim Click auf das voreingestellte Datum kein Event kam.
Der Erfinder des CalendarGadgets hat es sich unter Windows halt einfach gemacht und in den meisten Fällen mag das ausreichend sein.