nospam.nospam.nos...@gmail.com 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." ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user