Board index » Visual Studio » Receiving windows message after mainframe is destroyed

Visual Studio259
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?


-

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



-

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



-

Are you using any ON_MESSAGE handlers?



Make sure the functions have exact prorotype:



LRESULT memberFxn( WPARAM, LPARAM );



Parameters are critical. If you pass a handler without parameters, you will

observe very mysterios crashes, because of stack corruption.



Visual C 7 takes care of it (it will flag those functions), but not VC 6.



"rajas" <rajas@cox.net>wrote in message news:wx0xd.118$iD.111@fed1read05...



-

Yes,



I do use On_MESSAGE handlers & all the prototypes are of the form "LRESULT

memberFxn( WPARAM, LPARAM );" Of course for the Registered Window Messages

I use ON_REGISTERED_MESSAGE & in one instance I use ON_MESSAGE_VOID which

does not have parameters. None of these message handlers are for the Window

in question which is the Main Window of my application.







"Alexander Grigoriev" <alegr@earthlink.net>wrote in message



-

How your ON_REGISTERED_MESSAGE handler looks?



If you have an opportunity, feed your program to VC 2002 or 2003. It will

flag any wrong handler functions.



"rajas" <rajas@cox.net>wrote in message news:pQ7xd.575$iD.222@fed1read05...



-

I went through all of them - they all have the signature of the form

afx_msg LRESULT memberFxn( WPARAM, LPARAM );

A couple of them cast the WPARAM to UINT while functioning, but the

signature is the same. It should be noted that the message that is giving

me problems is not one that I egister for my applicataion.



Unfortunately, I do not have VC2002 0r VC2003. I will be getting an MSDN

Universl subscription but it does not start till next Feb.



Is it possible to trace the message through SPY+ ? I do not know how to set

it up to trace Registered messages.





"Alexander Grigoriev" <alegr@earthlink.net>wrote in message



-

In Spy Messages options, there is Registered checkbox.



Check if your other message handlers have correct number of arguments. Any

mismatch can cause a crash.



"rajas" <rajas@cox.net>wrote in message



-