Re: [lmi] a slight access violation

[Greg Chicares]

On 2014-10-27 20:53Z, Vadim Zeitlin wrote:
> 

[...the application receives menu events, not the MDI frame; and
then, when the application becomes SkeletonTest, and the GUI test
receives lmi's menu events, surprising things may happen...]

>  But then, personally, I wouldn't be doing this at wxApp level at all
> anyhow, but rather in wxFrame containing the menus to be updated or the
> commands to be processed, because I think that it is best to handle the
> events as locally as possible.

That makes sense. When I ported old code from OWL to wx, I saw
macros in wx samples that looked very much like OWL, so I used
them with wx too, e.g.:

  BEGIN_EVENT_TABLE(Skeleton, wxApp)
    EVT_MENU(wxID_ABOUT, Skeleton::UponAbout)

(I always had a sense that Julian must have known OWL very well.)
However, I looked back at my old OWL code, and found:

  DEFINE_RESPONSE_TABLE1(PMMDIClient, TMDIClient)
    EV_COMMAND(CM_FILEPRINT, CmFilePrint),
    EV_COMMAND_ENABLE(CM_FILEPRINT, CmPrintEnable),
  END_RESPONSE_TABLE;

Thus, I was certainly handling menu events at a lower level then,
which is your point above; and I agree that it's a better idea
now. How, specifically, would you recommend changing lmi?

Derive a new MDI frame (or MDI client) class from a wx base?

I believe you prefer Connect() over event-table macros; would
you recommend that sort of change, too?