[SOLVED] - MFC Issue - No mouse response

[eulmer]

I'm in the midst of removing a 3rd party piece of software from our code and have been working iteratively. Removing the last bit of it, some initialization code in the CWinApp derived class, has left me with the inability to interact with *any* component of the window.

It's menubar, children, etc.. aren't seeing the WM_LBUTTONDOWN (and similar) messages going through their loops (verified with debugging.) I've been reviewing the initial MFC Project I built while I built the replacement controls since all the boilerplate code is there for getting things up and running and haven't run across much that was missing.

I've attempted adding a call to CWinApp::InitInstance and I'm not failing to create the classes or windows (verified via Asserts, but also that the window is running and updating.) I've attempted things like playing with window focus as well.

I can tell that WM_TIMER style events are running fine because of the way things are updating; I simply cannot interact.




So.. how can you help?
* I've heard PreTranslateMessage can do nasty things; but everything was working before removing the other code and my breakpoints in these calls aren't being hit. Info in here may be useful however.

* I'm trying, to no avail, to find/google up a couple tools I've heard about that will tell you about controls under your mouse cursor; or possible a tool that sniffs Messages and tells you who consumes them. It seems the particular keywords of Events, Messages, Sniff, Windows, and similar are all so overloaded that I can only find completely irrelevant information or programs.


I suspect that the problem is a simple initialization command I'm missing.

[eulmer]

Someone had left a nice line of code in a file I hadn't touched that was similar to:

// This disables the main window which in turn disables all of the children
m_parentWnd->EnableWindow(FALSE);
this->EnableWindow(TRUE);

seemingly as a way to create a modal dialog in years passed? Can't say for sure but that was a pain to find. I have no idea why the 3rd Party's initialization code worked around that, but there you have it.

To those that follow; I ended up using the outdated tool UI Spy from Microsoft (there's also Inspect.exe, but I found UI Spy first on the recommendation of someone) and noticed that all of the controls had "IsEnabled = False" on them. Seemed mighty suspicious so I searched around for EnableWindow and found the above, comment and all.


Lesson to others: Please don't use nuclear weapons to deal with an ant problem; especially when ant-spray exists.