rickatseasoft
asked on
Mouse Click on List Control, passed through to the underlying Grid
I have a modal dialog that uses a ListControl to allow a user to select an option. This dialog will sometimes overlay a MSFlexGrid Control. That flex grid doesn't have focus nor is it supposed to have focus. If the item selected in the ListControl (only by double click) happens be within the boundary of the FlexGrid, then after the selection is made, and all processing pursuant to that selection is completed, then the FlexGrid acts as if it has been clicked.
In other words, if the item is selected by double click, then it seems as though the second click is passed through to the underlying Grid. If selected via single click and then OK, all is normal.
Thanks in advance.
In other words, if the item is selected by double click, then it seems as though the second click is passed through to the underlying Grid. If selected via single click and then OK, all is normal.
Thanks in advance.
Rick,
I tried this and couldnt duplicate the scenario - maybe because i used a list control instead of a flex grid. I think you are saying that a stray click that was part of the double click which caused the modal dialog to close fell through to the underlying window. I have seen this happen before in similar scenarios. Not sure if there is a standard solution for this.
One of the things you could try to do in the modal dialog is to delay the close action by using a postmessage to make sure clicks are not transferred down. For this, you would not immediately close the modal dialog on double click.
Instead,
void CDlgPopupDblClkTest::OnNMD
{
PostMessage(WM_USER+1001) ;
*pResult = 0;
}
//
LRESULT CDlgPopupDblClkTest::OnClo
{
CDialog::OnOK() ;
return 0 ;
}
You could also try running a message loop (equivalent to DoEvents in VB) on your double click handler and make sure the message queue is empty before you close the modal dialog.
As you see, these are all shots in the dark as i cannot duplicate this.
HTH
Priyesh
I tried this and couldnt duplicate the scenario - maybe because i used a list control instead of a flex grid. I think you are saying that a stray click that was part of the double click which caused the modal dialog to close fell through to the underlying window. I have seen this happen before in similar scenarios. Not sure if there is a standard solution for this.
One of the things you could try to do in the modal dialog is to delay the close action by using a postmessage to make sure clicks are not transferred down. For this, you would not immediately close the modal dialog on double click.
Instead,
void CDlgPopupDblClkTest::OnNMD
{
PostMessage(WM_USER+1001) ;
*pResult = 0;
}
//
LRESULT CDlgPopupDblClkTest::OnClo
{
CDialog::OnOK() ;
return 0 ;
}
You could also try running a message loop (equivalent to DoEvents in VB) on your double click handler and make sure the message queue is empty before you close the modal dialog.
As you see, these are all shots in the dark as i cannot duplicate this.
HTH
Priyesh
ASKER
Dan and Priyesh:
Dan I posted a response to your first comment, and I don't know where it went.
Anyway, the grid that is getting the focus after the closing of the Dialog containing the ListControl didn't have the focus before. There are two grids on the same dialog. As a matter of fact, I explicitly set the specific grid row and column and place a CEdit box on the grid there. This works perfectly until I double click the selection rather than clicking the selection, and then clicking OK.
Also, I've tried moving the ListDialog over other controls (CEdits), and the mouse clicks don't fall through to them.
I don't think that I am doing anything weird with the Grids, but will be checking today. However, if the listdialog is in a modal state, why would the mouse clicks ever pass through to the underlying windows?
One last thing. We are placing the dialog containing the list control in a modal state. I forget why we did this, but there was some problem with domodal in this dialog and the way that we wanted to set it up. At the end of the instantiation, it has a runmodalloop and at the end of the OnOK, it has an EndModalLoop.
Rick
Rick
Dan I posted a response to your first comment, and I don't know where it went.
Anyway, the grid that is getting the focus after the closing of the Dialog containing the ListControl didn't have the focus before. There are two grids on the same dialog. As a matter of fact, I explicitly set the specific grid row and column and place a CEdit box on the grid there. This works perfectly until I double click the selection rather than clicking the selection, and then clicking OK.
Also, I've tried moving the ListDialog over other controls (CEdits), and the mouse clicks don't fall through to them.
I don't think that I am doing anything weird with the Grids, but will be checking today. However, if the listdialog is in a modal state, why would the mouse clicks ever pass through to the underlying windows?
One last thing. We are placing the dialog containing the list control in a modal state. I forget why we did this, but there was some problem with domodal in this dialog and the way that we wanted to set it up. At the end of the instantiation, it has a runmodalloop and at the end of the OnOK, it has an EndModalLoop.
Rick
Rick
Rick,
The grid getting focus is possibly because of a WM_LBUTTONUP was sent to it (this could be the last mouse up of the double click and this again will point back to you making a modeless dialog modal by begin/end modalloop calls). I say WM_LBUTTONUP because you have already tried this with CEdits or other common controls they might not be responding to the button ups. Flexgrid being a special control might be setting focus to itself to do some special processing on button ups. You could test this by either using Spy++ on your underlying dialog (filter for WM_LBUTTONUP) or by making the double click fall through to the dialog itself (not on any controls) and watching for a WM_LBUTTONUP on the dialog's WindowProc.
Your making this dialog modal might have something to do with lookup windows launched from this dialog which are mdi children or such. Modal dialogs normally create problems there and developers tend to do exactly the same thing you described here.
Since making the dialog modal artificially is the one thing that stands out here, I would like to try doing an actual DoModal (on this or another dialog with similar setup) and trying the double click experiment there. That way we can isolate this to the Begin/End ModalLoop calls or rule that out and look for other reasons.
HTH
Priyesh
The grid getting focus is possibly because of a WM_LBUTTONUP was sent to it (this could be the last mouse up of the double click and this again will point back to you making a modeless dialog modal by begin/end modalloop calls). I say WM_LBUTTONUP because you have already tried this with CEdits or other common controls they might not be responding to the button ups. Flexgrid being a special control might be setting focus to itself to do some special processing on button ups. You could test this by either using Spy++ on your underlying dialog (filter for WM_LBUTTONUP) or by making the double click fall through to the dialog itself (not on any controls) and watching for a WM_LBUTTONUP on the dialog's WindowProc.
Your making this dialog modal might have something to do with lookup windows launched from this dialog which are mdi children or such. Modal dialogs normally create problems there and developers tend to do exactly the same thing you described here.
Since making the dialog modal artificially is the one thing that stands out here, I would like to try doing an actual DoModal (on this or another dialog with similar setup) and trying the double click experiment there. That way we can isolate this to the Begin/End ModalLoop calls or rule that out and look for other reasons.
HTH
Priyesh
I tend the the opinion that it is not a "stray message" but rather a defined/standard behavior of the combination of controls interacting in an unexpected way. As I recall from some similar experiences, a double-click event in list controls turns out to be a complex sequence in which messages (sometimes unexpected, non-intuitive messages) fly all over the place, including messages that the list's message handlers post to itself. For instance, it needs to first "unselect" (then paint) then "select" (then paint) in order for the underlying operation to succeed normally. If a "special sequence" like that get interrupted, there's no telling what will happen.
=-=-=-=-=-=-=-=-=-=-=
What I recommend is slapping Spy++ on all of the items in question (parent windows and child controls) and start recording events. Then take the minumum action that will force the undesired sequence. Then stop all recording and go through the sequence of logged events line by line.
Also part of that research is viewing the log of a "normal" behavior of the individual components when operating in a less complex environment. It can then be clear why that "normal" sequence can go awry.
-- Dan
=-=-=-=-=-=-=-=-=-=-=
What I recommend is slapping Spy++ on all of the items in question (parent windows and child controls) and start recording events. Then take the minumum action that will force the undesired sequence. Then stop all recording and go through the sequence of logged events line by line.
Also part of that research is viewing the log of a "normal" behavior of the individual components when operating in a less complex environment. It can then be clear why that "normal" sequence can go awry.
-- Dan
ASKER
I haven't tried the DoModal suggestion yet, but I did try something that I think debunked the WM_LBUTTONUP theory. What I did was LeftCkick in various places on the underlying dialog, without the Modal Dialog up at all, and then hover over the FlexGrid in question to see if it reacted to the release of the mouse button, and it didn't react at all.
I also tried moving the ListControl all over the screen to see if I could make any other control seemingly receive the second LClick, and nothing other than the FlexGrid reacted. I wonder if they both share some handler, or they have a handler with the same name so that they are effectively sharing the same handler.
I will try, this evening, the DoModal to see if the results are the same.
Thanks again for trying, Rick
I also tried moving the ListControl all over the screen to see if I could make any other control seemingly receive the second LClick, and nothing other than the FlexGrid reacted. I wonder if they both share some handler, or they have a handler with the same name so that they are effectively sharing the same handler.
I will try, this evening, the DoModal to see if the results are the same.
Thanks again for trying, Rick
ASKER
I set up Spy++, and logged the messages. The actual messages follow, but, I wonder if what I need to do is clean out the messages to the underlying Grid control? Is that reasonable, and, if so, how do I do that.
BTW, I don't know if it matters, but the CDialog and its ListControl are contained in a separate DLL from the Dialog with the FlexGrids.
Also, I subclassed the MSFlexGrid so that I could look at PreTranslateMessage, and ignore any messages during the time that the Dialog was in existance. and whatever is causing the problem occurs after the Dialog has returned. I turned off message processing by setting a bool to return from PreTranslateMessage on ALL messages, and then turned the bool off after the Dialog returned.
Any ideas, at all, will be greatly appreciated.
Thanks in advance, Rick
*******************Message
When a line is selected, and then OK pressed, it posts 10 messages to the underlying FlexGrid. They are
<00001> 001004E6 P WM_PAINT hdc:00000000
<00002> 001004E6 S WM_NCPAINT hrgn:3C0411CF
<00003> 001004E6 R WM_NCPAINT
<00004> 001004E6 S WM_ERASEBKGND hdc:A3011105
<00005> 001004E6 R WM_ERASEBKGND fErased:True
<00006> 001004E6 P WM_PAINT hdc:00000000
<00007> 001004E6 S WM_NCPAINT hrgn:27041114
<00008> 001004E6 R WM_NCPAINT
<00009> 001004E6 S WM_ERASEBKGND hdc:44011179
<00010> 001004E6 R WM_ERASEBKGND fErased:True
When a double click is pressed, it sends 175 messages
<00001> 00110410 P WM_PAINT hdc:00000000
<00002> 00110410 S WM_NCPAINT hrgn:8804121E
<00003> 00110410 R WM_NCPAINT
<00004> 00110410 S WM_ERASEBKGND hdc:8D0105D8
<00005> 00110410 R WM_ERASEBKGND fErased:True
<00006> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00007> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00008> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00009> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00010> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00011> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00012> 00110410 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:264 yPos:27
<00013> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00014> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00015> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_LBUTTONUP
<00016> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00017> 00110410 P WM_LBUTTONUP fwKeys:0000 xPos:264 yPos:27
<00018> 00110410 S WM_PAINT hdc:00000000
<00019> 00110410 S .WM_NCPAINT hrgn:BC041143
<00020> 00110410 R .WM_NCPAINT
<00021> 00110410 S .WM_ERASEBKGND hdc:01010054
<00022> 00110410 R .WM_ERASEBKGND fErased:True
<00023> 00110410 R WM_PAINT
<00024> 00110410 S WM_PAINT hdc:00000000
<00025> 00110410 S .WM_ERASEBKGND hdc:01010054
<00026> 00110410 R .WM_ERASEBKGND fErased:True
<00027> 00110410 R WM_PAINT
<00028> 00110410 S WM_PAINT hdc:00000000
<00029> 00110410 S .WM_ERASEBKGND hdc:01010054
<00030> 00110410 R .WM_ERASEBKGND fErased:True
<00031> 00110410 R WM_PAINT
<00032> 00110410 S WM_PAINT hdc:00000000
<00033> 00110410 S .WM_ERASEBKGND hdc:01010054
<00034> 00110410 R .WM_ERASEBKGND fErased:True
<00035> 00110410 R WM_PAINT
<00036> 00110410 S WM_PAINT hdc:00000000
<00037> 00110410 S .WM_ERASEBKGND hdc:01010054
<00038> 00110410 R .WM_ERASEBKGND fErased:True
<00039> 00110410 R WM_PAINT
<00040> 00110410 S WM_PAINT hdc:00000000
<00041> 00110410 S .WM_ERASEBKGND hdc:01010054
<00042> 00110410 R .WM_ERASEBKGND fErased:True
<00043> 00110410 R WM_PAINT
<00044> 00110410 S WM_PAINT hdc:00000000
<00045> 00110410 S .WM_ERASEBKGND hdc:01010054
<00046> 00110410 R .WM_ERASEBKGND fErased:True
<00047> 00110410 R WM_PAINT
<00048> 00110410 S WM_PAINT hdc:00000000
<00049> 00110410 S .WM_ERASEBKGND hdc:01010054
<00050> 00110410 R .WM_ERASEBKGND fErased:True
<00051> 00110410 R WM_PAINT
<00052> 00110410 S WM_PAINT hdc:00000000
<00053> 00110410 S .WM_ERASEBKGND hdc:01010054
<00054> 00110410 R .WM_ERASEBKGND fErased:True
<00055> 00110410 R WM_PAINT
<00056> 00110410 S WM_PAINT hdc:00000000
<00057> 00110410 S .WM_ERASEBKGND hdc:01010054
<00058> 00110410 R .WM_ERASEBKGND fErased:True
<00059> 00110410 R WM_PAINT
<00060> 00110410 S WM_PAINT hdc:00000000
<00061> 00110410 S .WM_ERASEBKGND hdc:01010054
<00062> 00110410 R .WM_ERASEBKGND fErased:True
<00063> 00110410 R WM_PAINT
<00064> 00110410 S WM_PAINT hdc:00000000
<00065> 00110410 S .WM_ERASEBKGND hdc:01010054
<00066> 00110410 R .WM_ERASEBKGND fErased:True
<00067> 00110410 R WM_PAINT
<00068> 00110410 S WM_PAINT hdc:00000000
<00069> 00110410 S .WM_ERASEBKGND hdc:01010054
<00070> 00110410 R .WM_ERASEBKGND fErased:True
<00071> 00110410 R WM_PAINT
<00072> 00110410 S WM_PAINT hdc:00000000
<00073> 00110410 S .WM_ERASEBKGND hdc:01010054
<00074> 00110410 R .WM_ERASEBKGND fErased:True
<00075> 00110410 R WM_PAINT
<00076> 00110410 S WM_PAINT hdc:00000000
<00077> 00110410 S .WM_ERASEBKGND hdc:01010054
<00078> 00110410 R .WM_ERASEBKGND fErased:True
<00079> 00110410 R WM_PAINT
<00080> 00110410 S WM_PAINT hdc:00000000
<00081> 00110410 S .WM_ERASEBKGND hdc:01010054
<00082> 00110410 R .WM_ERASEBKGND fErased:True
<00083> 00110410 R WM_PAINT
<00084> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00085> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00086> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00087> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00088> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00089> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00090> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:264 yPos:27
<00091> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00092> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00093> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00094> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00095> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:264 yPos:27
<00096> 00110410 S WM_NCHITTEST xPos:363 yPos:454
<00097> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00098> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00099> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00100> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:266 yPos:28
<00101> 00110410 S WM_NCHITTEST xPos:367 yPos:456
<00102> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00103> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00104> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00105> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:270 yPos:30
<00106> 00110410 S WM_NCHITTEST xPos:373 yPos:461
<00107> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00108> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00109> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00110> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:276 yPos:35
<00111> 00110410 S WM_NCHITTEST xPos:379 yPos:465
<00112> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00113> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00114> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00115> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:282 yPos:39
<00116> 00110410 S WM_NCHITTEST xPos:383 yPos:470
<00117> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00118> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00119> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00120> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:286 yPos:44
<00121> 00110410 S WM_NCHITTEST xPos:390 yPos:476
<00122> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00123> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00124> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00125> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:293 yPos:50
<00126> 00110410 S WM_NCHITTEST xPos:396 yPos:483
<00127> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00128> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00129> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00130> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:299 yPos:57
<00131> 00110410 S WM_NCHITTEST xPos:403 yPos:489
<00132> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00133> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00134> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00135> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:306 yPos:63
<00136> 00110410 S WM_NCHITTEST xPos:409 yPos:496
<00137> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00138> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00139> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00140> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:312 yPos:70
<00141> 00110410 S WM_NCHITTEST xPos:416 yPos:504
<00142> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00143> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00144> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00145> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:319 yPos:78
<00146> 00110410 S WM_NCHITTEST xPos:423 yPos:513
<00147> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00148> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00149> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00150> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:326 yPos:87
<00151> 00110410 S WM_NCHITTEST xPos:430 yPos:519
<00152> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00153> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00154> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00155> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:333 yPos:93
<00156> 00110410 S WM_NCHITTEST xPos:433 yPos:528
<00157> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00158> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00159> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00160> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:336 yPos:102
<00161> 00110410 S WM_NCHITTEST xPos:440 yPos:536
<00162> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00163> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00164> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00165> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:343 yPos:110
<00166> 00110410 S WM_NCHITTEST xPos:449 yPos:549
<00167> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00168> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00169> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00170> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:352 yPos:123
<00171> 00110410 S WM_NCHITTEST xPos:458 yPos:560
<00172> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00173> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00174> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00175> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:361 yPos:134
BTW, I don't know if it matters, but the CDialog and its ListControl are contained in a separate DLL from the Dialog with the FlexGrids.
Also, I subclassed the MSFlexGrid so that I could look at PreTranslateMessage, and ignore any messages during the time that the Dialog was in existance. and whatever is causing the problem occurs after the Dialog has returned. I turned off message processing by setting a bool to return from PreTranslateMessage on ALL messages, and then turned the bool off after the Dialog returned.
Any ideas, at all, will be greatly appreciated.
Thanks in advance, Rick
*******************Message
When a line is selected, and then OK pressed, it posts 10 messages to the underlying FlexGrid. They are
<00001> 001004E6 P WM_PAINT hdc:00000000
<00002> 001004E6 S WM_NCPAINT hrgn:3C0411CF
<00003> 001004E6 R WM_NCPAINT
<00004> 001004E6 S WM_ERASEBKGND hdc:A3011105
<00005> 001004E6 R WM_ERASEBKGND fErased:True
<00006> 001004E6 P WM_PAINT hdc:00000000
<00007> 001004E6 S WM_NCPAINT hrgn:27041114
<00008> 001004E6 R WM_NCPAINT
<00009> 001004E6 S WM_ERASEBKGND hdc:44011179
<00010> 001004E6 R WM_ERASEBKGND fErased:True
When a double click is pressed, it sends 175 messages
<00001> 00110410 P WM_PAINT hdc:00000000
<00002> 00110410 S WM_NCPAINT hrgn:8804121E
<00003> 00110410 R WM_NCPAINT
<00004> 00110410 S WM_ERASEBKGND hdc:8D0105D8
<00005> 00110410 R WM_ERASEBKGND fErased:True
<00006> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00007> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00008> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00009> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00010> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00011> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00012> 00110410 P WM_MOUSEMOVE fwKeys:MK_LBUTTON xPos:264 yPos:27
<00013> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00014> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00015> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_LBUTTONUP
<00016> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00017> 00110410 P WM_LBUTTONUP fwKeys:0000 xPos:264 yPos:27
<00018> 00110410 S WM_PAINT hdc:00000000
<00019> 00110410 S .WM_NCPAINT hrgn:BC041143
<00020> 00110410 R .WM_NCPAINT
<00021> 00110410 S .WM_ERASEBKGND hdc:01010054
<00022> 00110410 R .WM_ERASEBKGND fErased:True
<00023> 00110410 R WM_PAINT
<00024> 00110410 S WM_PAINT hdc:00000000
<00025> 00110410 S .WM_ERASEBKGND hdc:01010054
<00026> 00110410 R .WM_ERASEBKGND fErased:True
<00027> 00110410 R WM_PAINT
<00028> 00110410 S WM_PAINT hdc:00000000
<00029> 00110410 S .WM_ERASEBKGND hdc:01010054
<00030> 00110410 R .WM_ERASEBKGND fErased:True
<00031> 00110410 R WM_PAINT
<00032> 00110410 S WM_PAINT hdc:00000000
<00033> 00110410 S .WM_ERASEBKGND hdc:01010054
<00034> 00110410 R .WM_ERASEBKGND fErased:True
<00035> 00110410 R WM_PAINT
<00036> 00110410 S WM_PAINT hdc:00000000
<00037> 00110410 S .WM_ERASEBKGND hdc:01010054
<00038> 00110410 R .WM_ERASEBKGND fErased:True
<00039> 00110410 R WM_PAINT
<00040> 00110410 S WM_PAINT hdc:00000000
<00041> 00110410 S .WM_ERASEBKGND hdc:01010054
<00042> 00110410 R .WM_ERASEBKGND fErased:True
<00043> 00110410 R WM_PAINT
<00044> 00110410 S WM_PAINT hdc:00000000
<00045> 00110410 S .WM_ERASEBKGND hdc:01010054
<00046> 00110410 R .WM_ERASEBKGND fErased:True
<00047> 00110410 R WM_PAINT
<00048> 00110410 S WM_PAINT hdc:00000000
<00049> 00110410 S .WM_ERASEBKGND hdc:01010054
<00050> 00110410 R .WM_ERASEBKGND fErased:True
<00051> 00110410 R WM_PAINT
<00052> 00110410 S WM_PAINT hdc:00000000
<00053> 00110410 S .WM_ERASEBKGND hdc:01010054
<00054> 00110410 R .WM_ERASEBKGND fErased:True
<00055> 00110410 R WM_PAINT
<00056> 00110410 S WM_PAINT hdc:00000000
<00057> 00110410 S .WM_ERASEBKGND hdc:01010054
<00058> 00110410 R .WM_ERASEBKGND fErased:True
<00059> 00110410 R WM_PAINT
<00060> 00110410 S WM_PAINT hdc:00000000
<00061> 00110410 S .WM_ERASEBKGND hdc:01010054
<00062> 00110410 R .WM_ERASEBKGND fErased:True
<00063> 00110410 R WM_PAINT
<00064> 00110410 S WM_PAINT hdc:00000000
<00065> 00110410 S .WM_ERASEBKGND hdc:01010054
<00066> 00110410 R .WM_ERASEBKGND fErased:True
<00067> 00110410 R WM_PAINT
<00068> 00110410 S WM_PAINT hdc:00000000
<00069> 00110410 S .WM_ERASEBKGND hdc:01010054
<00070> 00110410 R .WM_ERASEBKGND fErased:True
<00071> 00110410 R WM_PAINT
<00072> 00110410 S WM_PAINT hdc:00000000
<00073> 00110410 S .WM_ERASEBKGND hdc:01010054
<00074> 00110410 R .WM_ERASEBKGND fErased:True
<00075> 00110410 R WM_PAINT
<00076> 00110410 S WM_PAINT hdc:00000000
<00077> 00110410 S .WM_ERASEBKGND hdc:01010054
<00078> 00110410 R .WM_ERASEBKGND fErased:True
<00079> 00110410 R WM_PAINT
<00080> 00110410 S WM_PAINT hdc:00000000
<00081> 00110410 S .WM_ERASEBKGND hdc:01010054
<00082> 00110410 R .WM_ERASEBKGND fErased:True
<00083> 00110410 R WM_PAINT
<00084> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00085> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00086> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00087> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00088> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00089> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00090> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:264 yPos:27
<00091> 00110410 S WM_NCHITTEST xPos:361 yPos:453
<00092> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00093> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00094> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00095> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:264 yPos:27
<00096> 00110410 S WM_NCHITTEST xPos:363 yPos:454
<00097> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00098> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00099> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00100> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:266 yPos:28
<00101> 00110410 S WM_NCHITTEST xPos:367 yPos:456
<00102> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00103> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00104> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00105> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:270 yPos:30
<00106> 00110410 S WM_NCHITTEST xPos:373 yPos:461
<00107> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00108> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00109> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00110> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:276 yPos:35
<00111> 00110410 S WM_NCHITTEST xPos:379 yPos:465
<00112> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00113> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00114> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00115> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:282 yPos:39
<00116> 00110410 S WM_NCHITTEST xPos:383 yPos:470
<00117> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00118> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00119> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00120> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:286 yPos:44
<00121> 00110410 S WM_NCHITTEST xPos:390 yPos:476
<00122> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00123> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00124> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00125> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:293 yPos:50
<00126> 00110410 S WM_NCHITTEST xPos:396 yPos:483
<00127> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00128> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00129> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00130> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:299 yPos:57
<00131> 00110410 S WM_NCHITTEST xPos:403 yPos:489
<00132> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00133> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00134> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00135> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:306 yPos:63
<00136> 00110410 S WM_NCHITTEST xPos:409 yPos:496
<00137> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00138> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00139> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00140> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:312 yPos:70
<00141> 00110410 S WM_NCHITTEST xPos:416 yPos:504
<00142> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00143> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00144> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00145> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:319 yPos:78
<00146> 00110410 S WM_NCHITTEST xPos:423 yPos:513
<00147> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00148> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00149> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00150> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:326 yPos:87
<00151> 00110410 S WM_NCHITTEST xPos:430 yPos:519
<00152> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00153> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00154> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00155> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:333 yPos:93
<00156> 00110410 S WM_NCHITTEST xPos:433 yPos:528
<00157> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00158> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00159> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00160> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:336 yPos:102
<00161> 00110410 S WM_NCHITTEST xPos:440 yPos:536
<00162> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00163> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00164> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00165> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:343 yPos:110
<00166> 00110410 S WM_NCHITTEST xPos:449 yPos:549
<00167> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00168> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00169> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00170> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:352 yPos:123
<00171> 00110410 S WM_NCHITTEST xPos:458 yPos:560
<00172> 00110410 R WM_NCHITTEST nHittest:HTCLIENT
<00173> 00110410 S WM_SETCURSOR hwnd:00110410 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
<00174> 00110410 R WM_SETCURSOR fHaltProcessing:False
<00175> 00110410 P WM_MOUSEMOVE fwKeys:0000 xPos:361 yPos:134
Rick,
There is a WM_LBUTTONUP sent to flexgrid when the modal dialog is dismissed by double click. This must be the issue. (I understand that the experiments you did by clicking elsewhere and releasing mouse button on flexgrid did not cause this issue, but windows could capture mouse on button down so button up will go to the window holding the capture. That will be one scenario where that experiment could show false positives).
I hate to patch for the additional WM_LBUTTONUP and would rather find out what the actual cause is. Let me know what kind of a solution you are looking for at this point. If you would try to patch this, we could try one of the solutions I posted earlier. If you would like to figure out the reason for this additional message going to the underlying window, it will be educational for all of us.
Dan might have some other ideas as well.
Priyesh
There is a WM_LBUTTONUP sent to flexgrid when the modal dialog is dismissed by double click. This must be the issue. (I understand that the experiments you did by clicking elsewhere and releasing mouse button on flexgrid did not cause this issue, but windows could capture mouse on button down so button up will go to the window holding the capture. That will be one scenario where that experiment could show false positives).
I hate to patch for the additional WM_LBUTTONUP and would rather find out what the actual cause is. Let me know what kind of a solution you are looking for at this point. If you would try to patch this, we could try one of the solutions I posted earlier. If you would like to figure out the reason for this additional message going to the underlying window, it will be educational for all of us.
Dan might have some other ideas as well.
Priyesh
I would like to support Dan. We had the same issue with tabbed views where the double click closes the current view and the next click activates an flex grid which happens to be located at the same screen position where we had double-clicked to. We solved the problem in the handler of the double-click by peeking for WM_LBUTTONDOWN and WM_LBUTTONDBLCLK messages and "eating" them if exist.
ASKER
You guys are exactly right in terms of the problem. I created the DLL, so intercepting the LBUTTONUP was not a problem, but I do wonder if my approach is doing surgery with a broadsword. I went into the function OnDblclickPicklist(), the code is something like
if(ViewOnly)return //sometimes we use the list as a viewing device, and picking is not OK
GetClickPosition
ResolveTheLinePicked
if(PickedLine in BLANK AREA) return;
*pResult=0;
//--------> Code to eat LBUTTONUP starts here
MSG Msg;
while(GetMessage(&Msg,NULL
if(Msg.message==WM_LBUTTON
}
//End code to eat the LBUTTONUP Ends
OnOK();
*pResult=0;
}
Whille in limited testing, the code above works perfectly, I am suspicious that this code has some potential to hang the system. Is there a better way?
Testing tells me this:
1. If I double click, and don't release LBUTTON after the second click, the system waits.
2. If I move the mouse off of the dialog while holding the button down, it doesn't see the BUTTONUP, and stays HUNG.
3. If I return to the Dialog, and click again anywhere, even on the OK or Cancel button, or another item in the list, it UNHANGS on the LBUTTONUP, but sees the original DoubleClick.
I thnik that I can live with this behavior if this is as bad as it gets.
Thanks again, Rick
if(ViewOnly)return //sometimes we use the list as a viewing device, and picking is not OK
GetClickPosition
ResolveTheLinePicked
if(PickedLine in BLANK AREA) return;
*pResult=0;
//--------> Code to eat LBUTTONUP starts here
MSG Msg;
while(GetMessage(&Msg,NULL
if(Msg.message==WM_LBUTTON
}
//End code to eat the LBUTTONUP Ends
OnOK();
*pResult=0;
}
Whille in limited testing, the code above works perfectly, I am suspicious that this code has some potential to hang the system. Is there a better way?
Testing tells me this:
1. If I double click, and don't release LBUTTON after the second click, the system waits.
2. If I move the mouse off of the dialog while holding the button down, it doesn't see the BUTTONUP, and stays HUNG.
3. If I return to the Dialog, and click again anywhere, even on the OK or Cancel button, or another item in the list, it UNHANGS on the LBUTTONUP, but sees the original DoubleClick.
I thnik that I can live with this behavior if this is as bad as it gets.
Thanks again, Rick
Have any of you tried Posting a message from the double click handler and handling the dialog close in the message handler? I am wondering if this will give enough time for all the messages to be processed (Post goes to the end of the queue).
ASKER
Priyesh:
I substituted this->PostMessage(WM_CLOSE
Is this what you meant for me to try?
Rick
I substituted this->PostMessage(WM_CLOSE
Is this what you meant for me to try?
Rick
Rick,
Yes. I was hoping the click messages had enough time to get processed before the close. I dont know if WM_CLOSE has the same effect as CDialog::OnOK. I was thinking more like the code example in my first comment.
Thanks for the info.
Priyesh
Yes. I was hoping the click messages had enough time to get processed before the close. I dont know if WM_CLOSE has the same effect as CDialog::OnOK. I was thinking more like the code example in my first comment.
Thanks for the info.
Priyesh
That LBUTTONUP without a preceeding down is definately strange, but it is actually explained by the dox:
CWnd::OnLButtonDblClk (MFC)
http://msdn2.microsoft.com/de-de/library/3efhe03w(VS.80).aspx
The WM_LBUTTONUP is sent at some point after the WM_LBUTTONDBLCLK call. So even a PostMessage might not be enough of a delay to have it handled normally.
You could set a local flag in OnLButtonDblClk and then in the WM_LBUTTONUP handler, see if that flag is set, then close the window if so.
What I'd probably actually do (after testing this approach :-) is start a timer in OnLButtonDblClk() and after, say 100 ms (a blink of an eye to a person, but a loooong time to a computer), I'd force the dialog window closed.
-- Dan
CWnd::OnLButtonDblClk (MFC)
http://msdn2.microsoft.com/de-de/library/3efhe03w(VS.80).aspx
The WM_LBUTTONUP is sent at some point after the WM_LBUTTONDBLCLK call. So even a PostMessage might not be enough of a delay to have it handled normally.
You could set a local flag in OnLButtonDblClk and then in the WM_LBUTTONUP handler, see if that flag is set, then close the window if so.
What I'd probably actually do (after testing this approach :-) is start a timer in OnLButtonDblClk() and after, say 100 ms (a blink of an eye to a person, but a loooong time to a computer), I'd force the dialog window closed.
-- Dan
ASKER
Dan and Priyesh:
I've tried every both SendMessage and PostMessage with WM_USER+x, and the old undesired behavior returns.
In both of you, I sense a reluctance for me to use the approach that is currently working, which is, to simply hold the dialog open awaiting the LBUTTONUP Message. I really appreciate your help to this point, but can you explain why the approach that I am using is problematic. BTW, I haven't tried extensively to break it, but with minimal testing, I can't break it. I'm not being argumentative, I just want to understand your reasoning.
Also, isn't there a way to keep the mouse messages pointed to my dialog even though it has moved outside of its screen area.
Thanks again, Rick
I've tried every both SendMessage and PostMessage with WM_USER+x, and the old undesired behavior returns.
In both of you, I sense a reluctance for me to use the approach that is currently working, which is, to simply hold the dialog open awaiting the LBUTTONUP Message. I really appreciate your help to this point, but can you explain why the approach that I am using is problematic. BTW, I haven't tried extensively to break it, but with minimal testing, I can't break it. I'm not being argumentative, I just want to understand your reasoning.
Also, isn't there a way to keep the mouse messages pointed to my dialog even though it has moved outside of its screen area.
Thanks again, Rick
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Dan and Priyesh:
OK, I went to the ClassWizard, and added the LBUTTONUP handler from there. Then in the OnDoubleClick handler, I set a boolean WaitingForLButtonUp. If the boolean is not set, then it just passes through, it it is set, then it calls OnOK().
All seems to work properly.
Thanks again for your expertise, Rick
OK, I went to the ClassWizard, and added the LBUTTONUP handler from there. Then in the OnDoubleClick handler, I set a boolean WaitingForLButtonUp. If the boolean is not set, then it just passes through, it it is set, then it calls OnOK().
All seems to work properly.
Thanks again for your expertise, Rick
You may check an easier solution: find out why the flexgrid handles the LM_BUTTONUP message. I mean to remember in the case told above that the flexgrid handled both LM_BUTTONDOWN and LM_BUTTONUP doing the same action what simply was a bug (and leads to a flicker in the grid). Generally WM_KEYUP and LM_BUTTONUP shouldn't be handled by controls if they can't make sure that the corresponding WM_KEYDOWN or LM_BUTTONDOWN was made at the same window.
Regards, Alex
Regards, Alex
You may need to a logic to obtain the current focus before popping up the list, then restore that focus after it is dismissed.
-- Dan