Unexplained WM_COMMAND messages in modeless dialog
in [MFC]
|
From: Joseph M. Newcomer on 18 Jan 2009 14:29 See below... On Sat, 17 Jan 2009 15:24:54 -0800 (PST), Woody <ols6000(a)sbcglobal.net> wrote: >On Jan 17, 12:15�pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote: >> I'd be reduced to single-stepping here. �I'd set a breakpoint at the hook function that >> recognizes the creation. �Then I'd probably set a breakpoint at AfxWndProc and do more >> single-stepping (step-into, F11). �Tedious as all-get-out, but I'm not sure how else I >> could begin to track down what is causing this. > >Even more tedious�when the debugger doesn't recognize the source, and >you're single-stepping through assembler. I tried that until I could >no longer keep track of where I was, but no further info. ***** For reasons that are unintelligible, even if you isntalled the MFC source, the debugger goes to the networked drive on the Microsoft server, in the directories that were used to create the product release, instead of going to your installed source. If it pops up the file box, you have to locate your MFC source on your machine. This is called "improving the product" (why is it that we get "improvements" that break things?) Debugging assembly code is really tedious. **** > >> Are these buttons regular CButtons or are they a subclass of CButton? > >They are regular CButtons, created by the dialog editor. And, as far >as I can tell, all 6 are identical (except that 2 have the "group" >attribute), but only 1 misbehaves. **** Weird. But see my comments in an earlier reply on this thread about a couple more breakpoints you might set. **** > >�In my opinion, a tool like ATL/MFC Tracer would be very helpful, but >I couldn't understand how it works. I thought of trying to build the >project under VS6, which has an understandable trace tool, but that is >a *big* undertaking. > >Another possibility is that somehow a mouse-click with the right >position is already enqueued at the time the dialog is created. This >doesn't make much sense either, but it should be easy enough to check. ***** Seems unlikely. Unless the DDX is triggering something really bogus, I'm at a loss here to suggest anything other than single-stepping. If the MFC source is installed, and you get the file-location box come up, point it at your installation (you'd think they could get something this easy right all the time...) joe **** Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 18 Jan 2009 14:31
Interesting. I've never had a radio button as the first selected element. But selecting a button is not the same as clicking it. So it isn't clear why it is getting a BN_CLICKED notification. Unless the DDX mechanism is doing something weird. joe On Sat, 17 Jan 2009 20:41:07 -0800, Henryk Birecki <soaringpilot(a)sbcglobal.net> wrote: >OK, I had exactly the same problem. I had a dialog and no matter what >the radio button was getting selected on dialog initialization. I >think I know the reason, but bear with me because I'm doing this >totally form memory and may be using wrong terms. > >The radio button in question was the first in the z-order. MFC somehow >selects a "default" button, control... and it is the first one in the >z-order. I do not remember if it can be set by properties. When MFC is >initializing the dialog it sends out all sorts of messages to assure >that the "default" is selected. My solution was to change the z-order >so that a standard button (but not OK, or Cancel) was the first one in >the z-order. That solved the problem. > >Cheers, >Henryk > >Joseph M. Newcomer <newcomer(a)flounder.com> wrote: > >>See below... >> >>On Sat, 17 Jan 2009 00:06:28 -0800 (PST), Woody <ols6000(a)sbcglobal.net> wrote: >> >>>I am using a modeless MFC dialog. The dialog, designed using the >>>dialog editor, contains 2 group boxes, and each group box "contains" a >>>group of 3 radio buttons. Each radio button has a handler invoked when >>>the button is clicked. >>> >>>When the dialog is created, one of the radio buttons (the one with the >>>lowest ID) receives several unexpected WM_COMMAND messages. No button >>>has been clicked at the time this occurs. I need to get rid of these, >>>as they interfere with the proper operation of the dialog. >>> >>>After the initial flurry of unexplained WM_COMMAND messages for >>>IDC_TicksX, clicking on any radio button, including IDC_TicksX, >>>produces the expected single WM_COMMAND, dispatched to the >>>corresponding On-function. >>> >>>Here is the code: >>> >>>[in a class derived from CWnd] >>>if(pFitGrid==NULL) >>>{ >>> pFitGrid=new CFitGridWindow(this); >>> pFitGrid->Create(IDD_FitGridWindow,this); >>>} >>> >>>[in FitGridWindow.cpp] >>>BEGIN_MESSAGE_MAP(CFitGridWindow, CDialog) >>> ON_BN_CLICKED(IDC_TicksX, OnTicksX) >>> ON_BN_CLICKED(IDC_TicksY, OnTicksY) >>> ON_BN_CLICKED(IDC_GridX, OnGridX) >>> ON_BN_CLICKED(IDC_GridY, OnGridY) >>> ON_BN_CLICKED(IDC_NoneX, OnNoneX) >>> ON_BN_CLICKED(IDC_NoneY, OnNoneY) >>>END_MESSAGE_MAP() >>**** >>What are the control IDs of those IDC_ values? Could you have a conflict with some other >>ID? >> >>I've not seen behavior like this, so if you are getting WM_COMMAND messages, there's >>something going on that is not evident from this code. >>**** >>> >>>void CFitGridWindow::OnTicksX() >>>{ >>>} <-breakpoint here catches the bogus messages >>***** >>If they are sent via SendMessage, your stack backtrace should reveal who sent them. Study >>it. >> joe >>***** >>>etc >>Joseph M. Newcomer [MVP] >>email: newcomer(a)flounder.com >>Web: http://www.flounder.com >>MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |