Re: [Foxgui-users]FXApp

[Jeroen <jv...@cf...>]

On Monday 15 January 2001 17:42, you wrote:
> Hi Jereon,
>
> I have been going through FXApp to get  an understanding of how it works. 
> I understand most of it but I dont understand how FXInvocation works -
> whats the purpose?.


FXInvocation keeps a linked list for recursive event loop invocations.
This is frequently needed when e.g. running a modal dialog (where we
process events, but don't return until the dialog closes).

I need to keep a linked list of recursive event loops, so each (or some)
recursive event loops can be terminated.  For example, if you kick off
a modal dialog "B" from another modal dialig "A", and close "A", then
"B" is also marked as closed (the corresponding invocation record's
done-flag is set).

Likewise, when the application is stopped, ALL recursive loops are similarly
marked, and control returns from run() at the earliest convenience.



> ie
> the run() method calls runOnce(), which calls getNextEvent() - OK
> If we now handle FXApp::ID_QUIT in our app, we then call getApp()->exit() -
> OK
> FXApp::exit calls stop() which then loops through the FXInvocation - what
> is it doing here?


It is setting the invocation's done-flag.  This causes all modal dialogs to
behave as if they had been closed.


> The reason that I am asking is that I am creating an event loop (based on
> FXApp) which doesn't refer to any GUI.  That way we can have non-GUI based
> FOX applications.  I am having a problem where the FXInvocation loop is
> core'ing on inv->done=TRUE, during the third loop pass.

I don't see how that could happen.  I will need to know more about what
you're trying to do.

Calling FXApp::stop() while not actually in a loop should be a no-op.

> ALSO:
> I think I have found a bug in getNextEvent() for the handling of signals. I
> beleive that it is necesary to return afer handling the signal(s) (eg after
> the sig[].target->handle()  refresh()).  Otherwise, a signal catch (of say
> SIGINT) doesn't exit the event loop, but rather, the event loop gets caught
> in the subsequent select().  - this is non-WIN32

This is what it is supposed to do.

FYI, there are two ways to deal with signals:- the safe way, and the immediate
way.  Let me explain: when your program gets a signal, it pushes the current
context on the stack and then executes the signal handler.  Your normal execution
can be interrupted by a signal at any moment, i.e. even at "inconvenient times".

The recommended (safe) way to deal with signals is to use the "non-immediate" mode;
in this mode, the signal handler just sets a flag to let the system know a signal
has been raised, and we will invoke the callback at the time when we return to
the event loop (at that time, we issue callbacks for all outstanding signals).

The unsafe way is to invoke the callback right away, when the signal is received;
in this case, the callback handler is invoked immediately.  As we don't know if
the program is in a consistent state, this callback is *very limited* in what it
can do.



Hope this explains,



		Jeroen


-- 
+-------------------------------+--------------------------------------------+
| E-Mail : jv...@cf...        | The FOX Platform Independent GUI Toolkit:  |
| USMail : 215 Wynn Drive,      |                                            |
|          Huntsville, AL 35805 |  Official Site:                            |
| Phone  : (256) 726-4820       |     http://www.cfdrc.com/FOX/fox.html      |
| Fax    : (256) 726-4806       |     ftp://ftp.cfdrc.com/pub/FOX            |
| WWW    : http://www.cfdrc.com |                                            |
+-------------------------------+--------------------------------------------+
| Copyright (C) 08:10 01/16/2001 Jeroen van der Zijp.   All Rights Reserved. |
+----------------------------------------------------------------------------+