[Gambas-devel] Event design choice

[tobi]

On Mon, 07 May 2012, Benoît Minisini wrote:
> 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
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
> 

Sounds like it complicates things even more ;) Actually a good idea, for both parties. Although, it
intermixes Window and Screen class again... Of course, this is better than raising with a default
"Window" event name... I don't know if I'm content with that, I hoped to get rid of that focused
Window but it simplified that much. However, good to learn new things every day (GB.CanRaise()), but
I have to set up this idea a little further: I watch the input queue associated with a screen using
my (not already commited) input module which then would utilise the @focused window and something
like an @active screen (for now, there is only one auto-creatable screen but that will change as
needed). The input module first checks if the @focused window has an event handler (of course it
has, since I will raise an error if a Window.SetFocus() is done on a window which has no event name
- with that in mind, it sounds not that confusing anymore!) and if it is NULL, the screen raises the
event.
OK, convinced, I have to rewrite the documentation anyway :)

Great idea, actually.

Regards,
Tobi