wxAppConsole child class cleanup code possible?
Andrew Smart
using wxFileSystemWatcher, which is working great.
The code is similar to what is shown here:
http://www.google.com/codesearch/p?hl=en#3yeaCJTLIMc/pub/2.8.0/wxOS2-2.8.0.tar.gz|h_piYfxNfUA/wxOS2-2.8.0/tests/test.cpp&q=wxAppConsole
But without overriding wxAppConsole::OnRun().
The problem is that neither my derived class's destructor or my
overriden wxAppConsole::OnExit() are being called. I'd like to be
able to save data out to a file before the application closes. Where/
how do I do it?
Joerg Toellner has noticed the same behavior: "But i already do my
cleanup in wxAppConsole::OnExit(). But somehow this is not called,
when i exit the application other than returning from
wxAppConsole::OnRun." http://groups.google.com/group/wx-users/browse_thread/thread/2259bd063f5dd430
I too notice that both my overridden wxAppConsole::OnExit() and the
destructor(s) are called when I override wxAppConsole::OnRun() and
return something from it. Is there any way I could use the default
event loop, not override wxAppConsole::OnRun(), and still have my
overridden wxAppConsole::OnExit() and the destructor(s) be called?
I've tinkered with wxAppConsole::FilterEvent(); it doesn't receive any
events on app shutdown.
I've also tried this code inside OnRun():
wxEventLoop* loop = new wxEventLoop();
ProcessPendingEvents();
loop->Run(); // The custom loop works great with
wxFileSystemWatcher. But after closing the app, execution doesn't
progress to the next line. OnExit() and the destructor are still not
called.
return 0;
Andrew Smart
> I'm using a class derived from wxAppConsole for the event loop. I'm
> using wxFileSystemWatcher, which is working great.
>
Looks like the link wasn't set up properly, the vertical bar in the
URL messed things up. First use this:
http://www.google.com/codesearch/p?hl=en#3yeaCJTLIMc/pub/2.8.0/wxOS2-2.8.0.tar.gz|
Then append this to it:
h_piYfxNfUA/wxOS2-2.8.0/tests/test.cpp&q=wxAppConsole
I don't know what the problem is. I guess the application close event
is handled by the platform (MSW) and not wxWidgets? This doesn't give
wxWidgets a chance to clean itself up? Am I correct in saying that
intercepting that close event would be dependent on MSW (not cross
platform)?
I think it is bizarre how the destructors are not being called (the
breakpoints in each are not hit).
-Andrew Smart
Andrew Smart
> using wxFileSystemWatcher, which is working great.
>
Andrew Smart
> On Feb 8, 5:34 pm, Andrew Smart <andrew.j.smart1...@gmail.com> wrote:
> > I'm using a class derived from wxAppConsole for the event loop. I'm
> > using wxFileSystemWatcher, which is working great.
>
> > The code is similar to what is shown here:<snip>
>
> Looks like the link wasn't set up properly, the vertical bar in the
> URL messed things up. First use this:
> h_piYfxNfUA/wxOS2-2.8.0/tests/test.cpp&q=wxAppConsole
>
> I don't know what the problem is. I guess the application close event
> is handled by the platform (MSW) and not wxWidgets? This doesn't give
> wxWidgets a chance to clean itself up? Am I correct in saying that
> intercepting that close event would be dependent on MSW (not cross
> platform)?
>
> I think it is bizarre how the destructors are not being called (the
> breakpoints in each are not hit).
Groups interface and hit refresh and then the back button.
Instead of looking at that old test with wxAppConsole in it, I wrote
up a class which demonstrates what I mean:
http://pastebin.com/download.php?i=rcR0pzPQ
Use comment out the #defines near the top to cause different
behavior. I write out events to "events.txt". Notice if an event
loop is used, and the application
is closed by the user, no destructors are called, and the overridden
wxAppConsole::OnExit() is not called. On the contrary, if no event
loop is used (meaning wxAppConsole::OnRun() is overridden and a value
is returned from it), the overridden wxAppConsole::OnExit() will be
called, and the destructors will be called.
Is this the intended behavior? What exactly is occurring which causes
the program to end before the destructors are called? This implies to
me that the application is not terminating normally.
I'll try the atexit function from cstdlib and see if it works as a
workaround:
http://www.cplusplus.com/reference/clibrary/cstdlib/atexit/
-Andrew Smart
Vadim Zeitlin
AS> Instead of looking at that old test with wxAppConsole in it, I wrote
AS> up a class which demonstrates what I mean:
AS> http://pastebin.com/download.php?i=rcR0pzPQ
AS> Use comment out the #defines near the top to cause different
AS> behavior.
What version of wx do you use to test this and how do you build your
application, as a console or as a GUI program?
AS> I write out events to "events.txt". Notice if an event
AS> loop is used, and the application
AS> is closed by the user,
I don't understand how can it be closed by user if it's a console
application and I don't understand how can you use wxAppConsole if it
isn't. IOW I'm quite confused, could you please explain how does this work?
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Carlos Rodriguez Llodrá
I assume your user is exiting the application by pressing Ctrl-C, or
something similar... in that case it's the same thing I was testing
right now, and works by installing a simple signal handler which
terminates the main loop, ie:
Add this function somewere:
static void my_signal_handler (int sig)
{
// Caught signal 'sig'
wxGetApp ().ExitMainLoop ();
}
And add this to your MyAppConsole's constructor:
signal (SIGINT, my_signal_handler);
This worked for me at least on linux (SIGINT catches Ctrl-C), don't know
if it will work on Windows (you may need to call 'SetConsoleCtrlHandler'
instead of 'signal'; see
http://www.cplusplus.com/forum/beginner/1501/#msg5410 )
Regards,
--
========================
Carlos Rodriguez Llodrá
carlos....@gmail.com
Andrew Smart
> What version of wx do you use to test this and how do you build your
> application, as a console or as a GUI program?
linker).
> I don't understand how can it be closed by user if it's a console
> application and I don't understand how can you use wxAppConsole if it
> isn't. IOW I'm quite confused, could you please explain how does this work?
with an event loop that handled events (specifically
wxFileSystemWatcherEvent events). It won't do anything else but sit
there. I wrongly assumed that OnExit was supposed to be called or an
event was supposed to be generated when:
The user pressed Ctrl-C or,
When the user pressed the X on the window with their mouse.
I didn't need any GUI stuff but I wanted the event loop; wxAppConsole
made that possible. Though it looks like the custom C signal handlers
won't be happy with stuff like I/O inside them:
http://msdn.microsoft.com/en-us/library/xdkz3x12.aspx
I don't see anything involving I/O as possible using wxAppConsole,
even with signal handlers; and I don't want to use MS specific stuff
('SetConsoleCtrlHandler'). I think in order to get the I/O I want
done on app shutdown, I will need to use wxApp as the entry point and
a wxFrame with the cleanup code in the wxFrame.
Thank you Carlos and Vadim!
-Andrew Smart
Andrew Smart
> I don't see anything involving I/O as possible using wxAppConsole,
Any cleanup involving I/O inside a signal handler using wxAppConsole
with an event loop I meant.
Thanks!
-Andrew Smart
Vadim Zeitlin
AS> So the plan was to have this wxAppConsole executable running 24/7,
AS> with an event loop that handled events (specifically
AS> wxFileSystemWatcherEvent events). It won't do anything else but sit
AS> there. I wrongly assumed that OnExit was supposed to be called or an
AS> event was supposed to be generated when:
AS> The user pressed Ctrl-C or,
AS> When the user pressed the X on the window with their mouse.
No, both result in an abnormal termination. You do need to use Win32
SetConsoleCtrlHandler() function to handle both of the above events but
wxWidgets doesn't wrap it currently (maybe it should).
AS> I don't see anything involving I/O as possible using wxAppConsole,
AS> even with signal handlers; and I don't want to use MS specific stuff
AS> ('SetConsoleCtrlHandler').
Why not? It's the right function to use here and you can isolate the
platform-specific part from the rest of your code quite easily (under Unix
you have a completely functionally equivalent signal(SIGINT)). Or, with
some more effort, you could isolate it even more thoroughly by submitting a
patch to wx adding a virtual OnConsoleInterrupt() method to wxAppConsole.