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." ------------------------------------------------------------------------------ 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