[Gambas-devel] Event design choice

Benoît Minisini gambas at ...1...
Mon May 7 23:33:24 CEST 2012


Le 07/05/2012 20:15, tobi a écrit :
> Hi,
>
> embarrassing but I want to ask for advice: Regarding Window and Screen class meaning spheres (Screen
> being a terminal screen on which several Windows reside) in gb.ncurses, I already moved some and am
> going to move other symbols from the former to the latter - yippi, the component is experimental! ;)
> (this is entirely to unwind the whole sources and ease the addition of controls)
> Seriously, I'm stuck at one point: the Window class raises a Read event when data arrives at the
> input queue. Since there can be more Windows on one Screen which all share the same input queue (one
> per screen), there must be a Window that is _solely explicitly_ allowed to raise that Read event, in
> order to prevent concurrently raised events which will then issue, e.g., a blocking read call on the
> input queue because the multiple instances steal each other input... - it was like what I mentioned
> before this horror scenario and works.
> As now the Screen class develops, it could be better to unwind that mess and let only the Screen
> class raise a Read event, since there is one input queue per Screen - the point: simplification.
> On the other side, we can have multiple event names for the numerous Windows and set focus (the
> focused Window will raise Read event) on that one, we are currently operating on (think of: a dialog
> box), that means if I do DialogWindow.SetFocus(), the DialogBox_Read() event will be risen instead
> of the former, e.g., MainWindow_Read() event. That procedure could equally ease program flow for the
> cautious programmer as well as it will create spaghetti code for the unexperienced one. (The
> aforementioned effect could be achieved by using flags, too, of course...)
>
> That's my dilemma now. Has anyone remarks on either solution that may help me decide? I wonder if
> there could be a way to niftily implement a ShowModal() method...
>
> Regards,
> Tobi
>

You can do both. :-)

When there is something to read, you can do that:

1) Check if the Window having the focus has an event handler for the 
read event, with the GB.CanRaise() API.

2) If it has the event handler, let the window raise the event.

3) Otherwise, let the screen raise the event.

What do you think about that?

-- 
Benoît Minisini




More information about the Devel mailing list