Code question: Self:owner:quit() => quits the app, but it obviously still runs??
Andi
// close Application
Self:owner:quit()
//Call garbage collector if it isn't just active:
If .NOT. Incollect()
CollectForced()
// If other app-events occur, process them in between
ApplicationExec(ExecWhileEvent)
Endif
//Close Shell window:
Super:close(oEvent)
Question: What is self:owner:quit() good for? I know it is called to
close the app but if processing time can still be delegated to the
application dispatcher through <ApplicationExec(ExecWhileEvent)>
obviously the app is still running. Closing of the App actually seems
to be accomplished by <Super:close(oEvent)>, that is by destroying the
shell window.
What is the difference here?
Could someone explain?
Jean-Alain Baeyens
quit() is a method of class app and owner is app object that have
called shell window (see start method). self:close() is to close shell
window. You can close shell window without closing application. Your
application is in this case in backgroung whit any interface. you can
show it in taskmanager.
Geoff Schaller
Largely you are just placing messages in the queue. Hence, you cannot expect
a linear response and most of what you wrote is totally unecessary, assuming
you want to close the app. For example, you can replace ALL that code with
one function call: _Quit() ! If you have the SDK you can look up all these
methods to see what they do.
> Method Close (oEvent) Class winShell
> // close Application
> Self:owner:quit()
Yep... it will, assuming Class App does in fact own the shell.
> //Call garbage collector if it isn't just active:
> If .NOT. Incollect()
> CollectForced()
No - this is totally unecessary. Also, the "If !InCollect()" is 100%
redundant as the CollectForced() call does this internally. But you simply
don't need to do this because the runtime will call the GC as part of its
shutdown sequence.
> // If other app-events occur, process them in between
> ApplicationExec(ExecWhileEvent)
Now you are really wasting your time <g>. You've called quit! Your
application is already cycling the message pump and you are not processing
in a tight loop or anything like that so again this call is 100% useless.
Norm will it cause any harm - it just won't do anything good.
> //Close Shell window:
> Super:close(oEvent)
Forget it! This will happen automatically and in point of fact, only places
more messages in the queue to process. You have called quit so the shell
will be destroyed in due process. In fact, calling this just slows down the
closure process because there are more messages to process!
HTH
Geoff
David Earl
I know what you're talking about. Perhaps a better example would be
something like:
METHOD SomeMethodCalledFromMenu CLASS ShellWindow
DO WHILE TRUE
ENDDO
RETURN NIL
The point of the infinite loop is that it never exits. It's only an
abstract example. The point is that the application is off doing
something, however the message pump is still happily shoveling
messages at the ShellWindow, since it is modeless. That means that the
worker loop (or basically any routine) will continue it's processing
until it is done, regardless of whether running some straight
calculations, walking a database, or whatever. If the user then tells
the ShellWindow to quit, the ShellWindow (and the app object and the
message pump) will be destroyed, however, because the loop does not
check the status of these items, it continues to work until it is
done.
If the process blindly assumes that these items still exist, it will
generate a 5333, for attempting to access (let's say) the ShellWindow
(which the user has in the meantime destroyed). For example:
METHOD SomeMethodCalledFromMenu CLASS ShellWindow
DO WHILE TRUE
Self:Status
ENDDO
RETURN NIL
In that case, the loop should generate the 5333 almost immediately
after the App:Quit() is called, because the loop is so tight. If we
adjust that to something real, like:
METHOD WalkADatabase CLASS ShellWindow
oDatabase:GoTop()
DO WHILE ! oDatabase:EOF
// Process the record
oDatabase:Skip( 1L)
// App:Exec( EXECWHILEEVENT) would just make the
// problem worse, because then the message pump
// gets more time, during which it might receive the
// WM_QUIT message...of course, it could help the GC
// but that's not under consideration in this example.
ENDDO
Self:Statusbar:SetMessage( "Process finished", MESSAGEMENU)
RETURN
and we say that the user selects File|Exit while the database is still
being processed, the ShellWindow (etc.) disappear, but the process
keeps running, and should 5333 on the last line, because it is
accessing objects, which no longer exist.
The only solution really is to write code against such situations, so
that the process can either:
1) check if the App is still active, and exit gracefully.
2) disable the exit option (or the entire menu) until the process has
been completed (which seems preferable).
A progress bar could be displayed, so that the user knows that the
process is doing something; an hourglass cursor could try to fool the
user into thinking that the app is busy; however, neither of these
will really stop the user from selecting the exit option.
David.
On 24 May 2002 00:00:51 -0700,