Re[2]: [lmi] Overriding wx member functions

[Vadim Zeitlin]

On Sat, 25 Mar 2006 23:18:14 +0000 Greg Chicares <address@hidden> wrote:

GC> I don't want wx's command-line parser. I use GNU getopt instead;
GC> I use it for separate command-line-only builds of lmi, too. To
GC> avoid using wx's, I override OnInit() and don't call the base-
GC> class version, which is what I think the documentation suggests.

 This is indeed the way to do it currently.

GC> Now, wxAppConsole::OnInit() currently (20050323 cvs) just calls
GC> the command-line parser, but that could change in a later version.
GC> To be sure, I guess I'd have to read each new version's sources,
GC> for wxAppConsole, wxAppBase, and the gtk and msw versions of
GC> wxApp. That sounds like a lot of deferred maintenance.

 OnInit() will continue to do command line parsing, although it might do it
via another function call (see "better way" below). But a worse danger, at
least in theory, is that OnInit() starts doing something else which you
wouldn't necessarily want to avoid. In practice I don't think base class
OnInit() is going to change like this because a lot of the existing code
doesn't call it and so putting any important initialization code in it
would be unwise. So I guess I want to say there is no big problem with your
current approach.

GC> Or I could look for a configure option to undefine
GC>   wxUSE_CMDLINE_PARSER
GC> but then my wx build may not work for other applications that use
GC> the wx parser--some interesting sample program, for example. And
GC> manipulating the library's configury seems like the wrong way to
GC> change runtime behavior in a particular app.

 I totally agree.

GC> Is there a better way?

 Without modifying wx I can only suggest overriding all of OnCmdLineXXX() 
and do nothing there. This is, of course, not very elegant as the parsing
is still done unnecessarily.

 A better way could be to modify wx to do the command line parsing in
DoParseCmdLine() virtual function -- which you could then override to do
nothing.

GC> Further questions arise wrt wxApp::OnExit(), which is called iff
GC> OnInit() returns true. My OnInit() may return either true or false
GC> depending on whether that important customer selects console or
GC> GUI behavior. Today, at least, wxAppConsole::OnExit() deletes the
GC> wxConfig object, which I create in the ctor and want to delete
GC> unconditionally, after saving file history. I've been deleting it
GC> with an OnExit() override, but now I review the code and surmise
GC> that this function doesn't get called for the console behavior.

 No.

GC> So maybe I should implement an OnExit() override that does nothing
GC> and put OnExit() behavior in the dtor.
GC> 
GC> Am I missing some clean way to do all of this?

 Again, while this can be (easily) solved without modifying wx I guess the
cleanest way to do it would be to add another virtual wxApp::Cleanup()
which would be called unconditionally, i.e. whether OnInit() returned true
or false.

GC> I know that a "real" OS is supposed to clean up any memory leaks
GC> when a program exits, but I'm not sure msw really does that

 It does, of course, but the program still shouldn't have even such
harmless memory leaks as it makes detecting the real ones difficult.

 Regards,
VZ