Re: [Foxgui-users]Problem with label redraw

[Sander J. <s.j...@gm...>]

I personally make FXGUISignal a member of my thread class (see
http://fox-toolkit.net/cgi-bin/wiki.pl?Cookbook/Create_A_Thread_Class_That_=
Can_Send_A_Message_To_GUI
)

Any chance we could change the message type to something else than
SEL_IO_READ. Something that at least is guessable without looking into
the source code. Like SEL_COMMAND or SEL_THREAD or.... . Or at least
mention it in the header file what type  of message is send.

    Sander

On 11/23/05, Jeroen van der Zijp <je...@fo...> wrote:
> On Wednesday 23 November 2005 07:33 am, Virginie Lefort wrote:
> > Well, i have tried, and i cannot find how it works :-(
> >
> >  So, in the run() function of my thread i do :
> >   while (_stop=3D=3D0) {
> >         _info->change(); //_info is a pointer to a struct that contains=
 the informations
> >        FXGUISignal signal(_win->getApp(),_win,FXSEL(SEL_COMMAND,MyWindo=
w::ID_INFOUPDATE), _info);
> >        signal.signal();
> >      }
> >    }
>
> No!!
>
> Here's how it works:- you establish a FXGUISignal *in your main thread*, =
i.e. the thread
> running the GUI.  The FXGUISignal needs to persist throughout the program=
 [or at least
> as long as your program wants to run with multiple threads].
>
> Do it like:
>
>         // Persistent variable, e.g. inside your MyMainWindow's construct=
or (lets say).
>         // After this call, a kernel object is added [using app->addInput=
()],
>         // for the gui-thread to watch.  When it becomes signalled, the g=
ui-thread
>         // dispatches to a handler
>         guisignal=3Dnew FXGUISignal(getApp(),this,ID_INFOUPDATE);
>
> Then you write a callback handler for the message SEL_IO_READ, ID_INFOUPD=
ATE
>
>
>         FXMAPFUNC(SEL_IO_READ,MyMainWindow::ID_INFOUPDATE,MyMainWindow::o=
nSgnlInfoUpdate),
>
>
> You write the handler code for onSgnlInfoUpdate().  What it does depends =
on your application;
> its possible it does nothing at all, in which case the notification from =
the thread has no
> effect other than to wake up the main gui-thread so as to cause it to run=
 through its GUI-
> update process and refresh all the widgets.
>
> Your thread calls:
>
>
>         guisignal->signal();
>
>
> This will "kick" the gui thread from its slumber.
>
>
> What actually happens:
>
> 1) when you create a FXGUISignal, a unix pipe is created and the reading =
end of it is
>    added to FXApp's addInput() routine.  This causes the event loop to wa=
tch the pipe
>    for activity.
>
> 2) The call to signal from the worker thread simply writes a byte into th=
e pipe, if there's
>    nothing in the pipe yet.  This makes the pipe filedescriptor which the=
 FXApp is watching
>    become "signalled".
>
> 3) The system call select() which is used to watch all sockets and pipes =
in FXApp falls through,
>    and after figuring out which file descriptor was the signalled one, FX=
App dispatches to
>    FXGUISignal::onSignal.  This routine drains the pipe [thereby making i=
t unsignalled again!]
>    and then turns around and calls your onSgnlInfoUpdate callback handler=
.
>
>
> As you write multi-threaded code, note that GUI and worker thread may run=
 at THE SAME TIME and
> thus care must be exercised with critical sections and so on.  FXApp prov=
ides one "blanket"
> mutex, which is essentially a critical section around any callback exerci=
sed by the main
> thread.  This is the FXApp's global mutex.
>
> In realistic multi-threaded applications you're likely to have many more =
fine-grained critical
> sections.
>
> Hope this explains,
>
>                                 - Jeroen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=3D7628&alloc_id=3D16845&op=3Dclick
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> https://lists.sourceforge.net/lists/listinfo/foxgui-users
>