Re: Receiving windows message after mainframe is destroyed

From: rajas (rajas_at_cox.net)
Date: 12/18/04 

Date: Sat, 18 Dec 2004 13:36:49 -0700

Thanks Johan for responding. Sometimes all it takes is for another person
to chime in in order to find the problem.

My problem is that this is a fairly large and complex application that
compiles and runs without problems in my old computer (Win XP home SP1 ,
MSVC6 with all the updates). In my new computer (Win XP Professional SP2,
MSVC6 with all updates), I get an error during debug becuase a message is
sent to a window that is closed).

I read somewhere that SP2 has made changes that can expose bugs - especially
those associated with improper cleanup (may be just a rumour started to get
people to spend hours with their code).

I have walked through the closing step by step & my Window is closed -
properly. What I guess is that some system service (could it be COM?) is
remembering the HWND of the main window and this message is sent. If I can
find the message, I can guess what is happening. But the message is in the
range of those in the RegisteredWindowsMessage - but before any of my
messages (all of mine are in sequence). Perhaps there is a list of such
messages somewhere. For instance, I use the Registered Windows Message
WM_TASKBARCREATED which turns out to be C090 according to my TRACE. The
offending message is C12E and the crash is in the MFC function
WalkPreTranslateTree. My messages start with C170

-rajas

"Johan Rosengren" <johan.rosengren@telia.com> wrote in message
news:%23n$%23x%23N5EHA.3840@tk2msftngp13.phx.gbl...
> rajas,
>
> Little do I know of your problem, but as you're not getting much help,
I'll
> have to do.
>
> First of all, you don't want to try to purge the message queue, and you
are
> *not* interested in where the message came from :-) As long as you have
made
> sure that it is not sent from your own code, you can do very little about
> it.
>
> You'll rather have to find a way to close the application without getting
> this error - and that would of course be to delay the destruction still a
> little while, or make sure that it is destroyed in a proper way.
>
> The way I would approach this would be to create an application with the
> same structure (that is, the same type of frame/view etc), and then
> thoroughly trace the close down operations of this app, making sure that
> your application follows the same method. You might also want to
experiment
> with not hiding the main window, to see if this has any impact.
>
> It might not be a realistic option for you, but in case it is, I would
> consider rewriting the application using a simpler superstructure if you
are
> hiding it anyway (such as using a simple dialog for the main window).
>
> To summarize, you have the wrong approach if you try to wrestle
Windows/MFC
> to work your way, rather than adapt. Adapt or die :-)
>
> Johan Rosengren
> Abstrakt Mekanik AB
>
> "rajas" <rajas@cox.net> a écrit dans le message de
> news:kKEwd.2$iD.0@fed1read05...
> > Hi I am posting this again - not having heard anything in several days.
> > Please let me know if there is another group I shoudl post this to.
> >
> > ------
> > I am stuck and could use any suggestion.
> >
> > My application (MSVC 6 & MFC) uses a mainframe that is hidden soon after
> it
> > is created & uses a tray icon for user interactions. I have had no
problem
> > for quite some time - till I upgraded from WinXP home - SP1 to WinXP rpo
> > XP2. The application crashes on exit in the debug mode. The error is
an
> > ASSERT in CWnd::WalkPretranslateTree. This function is checking if any
> > windows wants to translate the message and the last window being checked
> is
> > my mainframe which has been destroyed by now (the problem occurs after
> > OnNcDestroy in my CMainFrame which calls CFrameWnd::OnNcDestroy.
> >
> > The message itself is a registered window message. My application
> registers
> > many Windows messages and this message is NOT in the range of the
messages
> > that
> > my application registers - and it is not one that my application
> > registers (are there messages that is registered on behalf of my
> application
> > that I do no know about?).
> >
> > Is there anything I can do to check/clear all the messages in the queue
> > before I call CFrameWnd::OnNcDestroy?
> >
> > This problem does not occur in my other XP machine which is yet to be
> > upgraded to SP2.
> >
> > How can I track this problem? How can I find out where this registered
> > message is coming from? I am not familiar with SPY++ - perhaps someone
> can
> > tell me how I can use it or some other tool to track the source of this
> > message & see where my problem is?
> >
> >
> >
>
>

Relevant Pages

  • Re: Item 2, window handle changing.
    ... It appears that setting the ShowInTaskbar property during runtime causes the ... window handle of the form to change. ... > - The app runs in the background is initially hidden from the user, ... > - The app needs to receive a registered Windows message ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Some progress
    ... I have a sneaking suspicion that setting the ShowInTaskbar ... > window handle of the form to change. ... >> - The app runs in the background is initially hidden from the user, ... >> - The app needs to receive a registered Windows message ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: getting bho reference from iwebbrowser2
    ... You can send registered windows message to the window returned by IOleWindow ... You can subclass the window in your BHO to handle registered messages. ... to get a pointer/reference to my BHO's class from the IWebBrowser2 ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)
  • Re: Prevent focus loss on shdocvw.internetexplorer creation
    ... Hiding the window and then ... showing it didn't work because the hide required the browser object ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Forms ?
    ... It is possible but I *don't* recommend it since there are problems ... associated with hiding the Access Application window, ... > I want to run a MsAccess-form as a single Application, ...
    (microsoft.public.access.forms)