[Gambas-user] Setting a checkbox value

[Doriano Blengino]

nospam.nospam.nospam at ...626... ha scritto:
> Doriano Blengino wrote:
>   
>> bbb888 ha scritto:
>>     
>>> Benoit,
>>>
>>> Why oh why should setting checkbox value in code generate a click
>>> event?
>>>
>>>       
>> I join.
>> I think that events should be fired by user, never by code.
>>     
>
> You'd be saying exactly the opposite if gambas was badly designed and didn't 
> generate the event on a coded change when you needed it to. You would have 
> no way in hell of easily detecting it, not ever. Besides that, firing events 
> for code-set attributes is normal practice in a GUI. All you need do is set 
> a flag and test it in the event code. 
>   
No. How can you say I would say the opposite? Are you a magician? 
Probably you think I am counter-gambas in every situation, but this is 
not true. Anyway, who cares. I give you permission of thinking and 
saying whatever you want about me. Your words will speak for yourself.

Automatic firing of events could be a matter of taste - ok. Without it, 
you can set a property and, if you want, call the relevant event 
handler. With automatic firing, you must declare a global variable, set 
it before setting the property, reset it just after, and modify the 
event handler to check for the global variable. Again, the microsoft 
way: to complicate simple things.

To Fabien, which wrote:
> but in this case it will work
>
> Object.lock(checkbox)
> Checkbox.value=true
> Object.Unlock(checkbox)
>
> so then the events are fired ... it is just blocked during the variable setting
>   
You say so, and you are 99% right, because "Checkbox.value" is a single 
and fast instruction. But I still think that there is a probability of 
1% that the user clicks on the checkbox exactly in that moment, and user 
clicks should never be ignored. This 1% raises to 100% in my 
filemanager. I would like to know an explanation from Benoit: why, at a 
certain point of gambas developing, he needed to invent an object.lock() 
and object.unlock()? I think because GTK and probably QT do this stupid 
thing of automatically firing events. If you want to prevent the user to 
click a button, for example, you disable it - the botton goes gray and 
the user is notified of that. I don't see a reason to have lock and 
unlock, apart from that quirk of GTK and QT.

In Delphi under windows there is a mix of things. Some widgets 
(checkboxes for example) raise an event when modified by code. Others 
(trackbars, for example) do not. My thought about this is a mix of 
things too: I do respect Borland and I hate microsoft, so I can not know 
where this inconsistency rises up - probably from win32, and Borland 
simply reflected it. But I am sure that, using trackbars which don't 
raise events, if I need them I add a "tbSpeed.Change(NIL)": 6 keystrokes 
and no worries. With checkboxes and perhaps others, if I don't want 
automatic events, I have to modify the code in at least three points, 
and this is frustrating.

Regards (especially to Nospam -:),

-- 
Doriano Blengino

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