[Gambas-user] Setting a checkbox value

[Doriano Blengino]

Benoît Minisini ha scritto:
>>> bbb888 ha scritto:
>>>       
>>>> Benoit,
>>>>
>>>> Why oh why should setting checkbox value in code generate a click
>>>> event?
>>>>
>>>> bruce
>>>>         
>>> I join.
>>> I think that events should be fired by user, never by code.
>>>
>>> Regards,
>>>       
>> Why should we make a difference between the user and the code? Most of the
>> time it is useless, so when you need that, just block events explicitely.
>>
>> Regards,
>>
>>     
>
> To give more details about my point of view...
>
> 1) You cannot know that an event comes "from the user" in every case.
>   
Unless you know that events *always* come from user - I am speaking of 
"click", "change" and so on, not "data" event or "icon".
> 2) This time, I agree with nospam x 3 :-). If events coming from the user do 
> not raise events, how could you catch them when needed? After many years of 
> GUI programming, I find my way the better one.
>   
Events coming from the user *should always* raise events.
> 3) It is more consistent to always raise events, as do the underlying toolkits 
> used by Gambas, than sometimes raising them, especially when you can't be sure 
> that an event comes from the user or not.
>   
When needed: you don't raise an event - you call the event handler 
directly (which is different, and impossible in gambas).

There is a subtle distinction between events, hooks and methods. A 
button lies on a form awaiting for an event (a user click). When the 
click arrives, the button executes a method which repaints it depressed, 
and calls a hook to let the main program do something useful. The 
confusion arrives when event, hook and method are not separated. 
Intercepting the event, we make the button insensitive, because it never 
sees a user clicked on it. Intercepting the hook we can launch our 
handler, to make our program do useful things. Lastly, we can call the 
button method to repaint it depressed. By having these three elements 
(event, hook and method) separated, we have all the control on the 
button - think that a button is a really simple gadget. It would be ok 
to have event-hook-method connected by default. If we want to simplify 
this scheme, forcibly we have to loose some functionality.

Note that in other cases, such as the Data event or Icon event, they 
should not be events - they should be hooks. Events are asynchronous and 
queueable, while hooks are not. Characters arriving from a serial port 
are events (asynchronous) and, if the program does not handle them fast 
enough, they should be stacked or queued. In fact, serial ports always 
have a buffer. Icon event is not an event: who raises those events 
(treeview or fileview) can not stack them - it waits until the main 
program handles them (a hook). And, in fact, they do not have a buffer.

Now, it is nice to simplify GUI programming by eliminating three things 
and have only one: most of the time it is ok; but this doesn't mean 
event and hooks are the same...

Regards,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."