[Gambas-user] Setting a checkbox value

[Benoît Minisini]

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

It does not matter if *you* know that an event comes from the user. The 
toolkit just receives events from X-Window : it cannot know if this event 
comes directly from an input device (i.e. from the user) or if it is a 
consequence of running code previously. Of course, *some* events do not come 
from X-Window, but are internally managed by the toolkit. But no toolkit 
behave the same, and so you cannot be sure that a X-Window event comes "from 
the user", and so there is no way to know that for Gambas events too.

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

Sorry, I forgot a "not" before "coming".

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

I agree that I merged hooks and event handler in Gambas. For simplicity, and 
because Gambas events are not queued. Unless of course if the toolkit does 
that, but the interpreter has no control on that. And for delayed events, but 
this is an exception mainly used for having event sbehave the same in gb.qt 
and in gb.gtk.

Regards,

-- 
Benoît Minisini