http://www.purebasic.com
https://www.purebasic.fr/english/
Since you firstly check the #PB_Event_... value, there's no problem when it's zero.mestnyi wrote: Sun Nov 10, 2024 6:31 pmThat's true, but Fred doesn't want to fix this situation in any way. moreover, I do not understand how the event value can be zero.mk-soft wrote: Sat Nov 09, 2024 11:54 pm EventType() = #Null is ...Code: Select all
Debug #PB_EventType_LeftClick
yes, at least because it is illogical why this theme was created, and because it is more logical that there should be a change in the event rather than a click event. I have a counter question, why was the loop banned inside bindevent?mk-soft wrote: Sun Nov 10, 2024 7:02 pm Why should this be corrected? It's fine the way it is.
They are constants that Fred has defined, just as you can create constants for your purposes in your programme.
Code: Select all
if eventtype()
;
endifThe EventType() value of zero for a checkbook gadget is incorrect because the defined event types for a checkbox is the empty set not the set containing zero.mestnyi wrote: Mon Nov 11, 2024 8:26 pmyes, at least because it is illogical why this theme was created, and because it is more logical that there should be a change in the event rather than a click event. I have a counter question, why was the loop banned inside bindevent?mk-soft wrote: Sun Nov 10, 2024 7:02 pm Why should this be corrected? It's fine the way it is.
They are constants that Fred has defined, just as you can create constants for your purposes in your programme.
why is the value 0 incorrect, for example, such use is not possibleCode: Select all
if eventtype() ; endif
Faulty logic. If there is no event, then its type does not exist. If an event has arrived, then it must have a type. Defining an event by the absence of a type is absurd. If you assume that you would like to check for the absence of a type before checking 5 different types in order to speed up the code, then the disappointment is that even if there was a value that determines the absence of a type, it still would not help you, since the number is not a the absence of a type and it would still force you to make checks with all five types. Roughly speaking, if you want to ignore an event by type, then simply call EventGadget() first, and if there is no event, then there will be no type.
This is exactly the same infallible logic.AZJIO wrote: Mon Nov 11, 2024 9:48 pmFaulty logic. If there is no event, then its type does not exist. If an event has arrived, then it must have a type. Defining an event by the absence of a type is absurd. If you assume that you would like to check for the absence of a type before checking 5 different types in order to speed up the code, then the disappointment is that even if there was a value that determines the absence of a type, it still would not help you, since the number is not a the absence of a type and it would still force you to make checks with all five types. Roughly speaking, if you want to ignore an event by type, then simply call EventGadget() first, and if there is no event, then there will be no type.
Code: Select all
Enumeration CheckBoxes
#__CheckBox_index_start = 1000
#myCheckBox1
#myCheckBox2
#__CheckBox_index_end
EndEnumeration
If OpenWindow(0,0,0,270,170,"CheckBoxGadget",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
CheckBox_index = #__CheckBox_index_end
CheckBoxGadget(CheckBox_index, 10,70,250,20,~"\"runtime CheckBox\"")
CheckBox_index+1
CheckBoxGadget(CheckBox_index, 10,100,250,20,~"\"runtime CheckBox\"")
CheckBox_index+1
CheckBoxGadget(#myCheckBox1, 10,10,250,20,"standard CheckBox")
CheckBoxGadget(#myCheckBox2, 10,40,250,20,"standard CheckBox")
StringGadget(0,10,130,250,20,"")
Repeat
ev=WaitWindowEvent()
If ev=#PB_Event_Gadget
if EventType() = #PB_EventType_Change or EventGadget() > #__CheckBox_index_start
Debug "Gadget changed: " + EventGadget()
EndIf
EndIf
Until ev=#PB_Event_CloseWindow
EndIfCode: Select all
Define GadgetChanged
If OpenWindow(0, 0, 0, 270, 100, "Changed", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
CheckBoxGadget(0, 10, 10, 250, 20, "CheckBox standard")
StringGadget(1, 10, 40, 250, 20, "")
OptionGadget(2, 10, 70, 120, 20, "Option 1")
OptionGadget(3, 140, 70, 120, 20, "Option 2")
Repeat
ev=WaitWindowEvent()
If ev=#PB_Event_Gadget And IsGadget(EventGadget())
Select GadgetType(EventGadget())
Case #PB_GadgetType_ComboBox, #PB_GadgetType_Date, #PB_GadgetType_Editor, #PB_GadgetType_ExplorerList, #PB_GadgetType_ExplorerTree,
#PB_GadgetType_Image, #PB_GadgetType_ListIcon, #PB_GadgetType_Spin, #PB_GadgetType_String, #PB_GadgetType_Tree ;#PB_GadgetType_Panel
If EventType()=#PB_EventType_Change
GadgetChanged = #True
EndIf
Case #PB_GadgetType_CheckBox
GadgetChanged = #True
Case #PB_GadgetType_Option
;State = GetGadgetState(EventGadget())
; it can't be done like this, because we don't receive an event if we click on another option of the same group
;If State <> GetGadgetData(EventGadget())
; SetGadgetData(EventGadget(), State)
GadgetChanged = #True
;EndIf
EndSelect
If GadgetChanged
Debug "Either a CheckBox or StringGadget changed"
GadgetChanged=0 ;Reset for testing other changes in this example
EndIf
EndIf
Until ev= #PB_Event_CloseWindow
EndIfCan the result of EventGadget() change when it is repeated? I’ll ask differently: is the call of WaitwindowEvent() filling a certain structure, after which the functions of the EventGadget() and EventType() functions and others simply receive data from this structure?ChrisR wrote: Fri Feb 07, 2025 1:41 amCode: Select all
If ev=#PB_Event_Gadget And IsGadget(EventGadget()) Select GadgetType(EventGadget())
New events are retrieved from the event queue only when WaitWindowEvent() or WindowEvent() is called. The event retrieved becomes the most recent event.AZJIO wrote: Fri Feb 07, 2025 3:09 am However, WaitwindowEvent () returns a new event each time. If it is logically reasoning, then other functions should not return the codes from other events, given that even the mouse movement can create a dozen events per second. So the function cachs the value associated with the captured event.
