Solved

Mouse Click on List Control, passed through to the underlying Grid

Posted on 2007-03-23
19
554 Views
Last Modified: 2013-11-25
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.
0
Comment
Question by:rickatseasoft
  • 7
  • 6
  • 4
  • +1
19 Comments
 
LVL 49

Expert Comment

by:DanRollins
ID: 18786866
Depending on the type of ListControl, A double-click action will typically close it ("dismiss" it) and thus set the focus back to whatever control was in focus before it popped up.

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
0
 
LVL 9

Expert Comment

by:Priyesh
ID: 18789783
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::OnNMDblclkList1(NMHDR *pNMHDR, LRESULT *pResult)
{
      PostMessage(WM_USER+1001) ;
      *pResult = 0;
}
//
LRESULT CDlgPopupDblClkTest::OnCloseMessageHandler(WPARAM wpar, LPARAM lpar)
{
      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
0
 

Author Comment

by:rickatseasoft
ID: 18791860
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
0
 
LVL 9

Expert Comment

by:Priyesh
ID: 18793443
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
0
 
LVL 49

Expert Comment

by:DanRollins
ID: 18795980
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
0
 

Author Comment

by:rickatseasoft
ID: 18796336
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



0
 

Author Comment

by:rickatseasoft
ID: 18797559
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

*******************Messages are below**********************


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
0
 
LVL 9

Expert Comment

by:Priyesh
ID: 18797900
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
0
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 18798538
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.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:rickatseasoft
ID: 18798897
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,0,0)>0){
   if(Msg.message==WM_LBUTTONUP)break; //Find and eat the LBUTTONUP Message      
}
//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  
0
 
LVL 9

Expert Comment

by:Priyesh
ID: 18799727
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).
0
 

Author Comment

by:rickatseasoft
ID: 18800763
Priyesh:

I substituted this->PostMessage(WM_CLOSE,0,0) for the OnOK() in the DoubleClick handler.  The old behavior returned.

Is this what you meant for me to try?

Rick
0
 
LVL 9

Expert Comment

by:Priyesh
ID: 18802360
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
0
 
LVL 49

Expert Comment

by:DanRollins
ID: 18804821
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
0
 

Author Comment

by:rickatseasoft
ID: 18806981
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
0
 
LVL 9

Accepted Solution

by:
Priyesh earned 250 total points
ID: 18808073
Rick,
I have no problem with your message loop approach. Just wanted to make sure a PostMessage would solve the issue. The documentation Dan quoted above has the words "at some point" in it about the last lbutton up so that settles the PostMessage approach.
I notice that you have GetMessage in your message loop code pasted above. GetMessage waits for  a message so that's probably why you see some hangs (especially because you look for lbutton up). I see you might need GetMessage here because the message queue might be empty as LBUTTONUP is not immediately available. In that case, you will have to try the timer method Dan suggested.
Try changing GetMessage to PeekMessage and see if that will continue to solve the issue.

HTH
Priyesh
0
 
LVL 49

Assisted Solution

by:DanRollins
DanRollins earned 250 total points
ID: 18811136
Indeed,  My suggestion -- and the best solution to this situation -- is to keep the dialog open until the LBUTTONUP has been handled normally.

Both of the options I mentioned do that... and they do it in a way that avoids a local message pump (which tends to have unexpected/unwanted side-effects).

The root of the problem is that you are closing the dialog INSIDE of the double-click handler.  You need that handler to exit cleanly, then close the dialog at some later point.  PostMessage is normally good enough for that, but in this case, the LBUTTONUP event can come *even later* than the posted message.  Thus, you need to use a different mechanism.  Starting a timer or setting a flag for use by a new LBUTTONUP handler will do the trick.  If you need more specific information on how to accomplish either of these sequences, let me know.

-- Dan
0
 

Author Comment

by:rickatseasoft
ID: 18812021
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
0
 
LVL 39

Expert Comment

by:itsmeandnobodyelse
ID: 18815265
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
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Suggested Solutions

What my article will show is if you ever had to do processing to a listbox without being able to just select all the items in it. My software Visual Studio 2008 crystal report v11 My issue was I wanted to add crystal report to a form and show…
Whether you've completed a degree in computer sciences or you're a self-taught programmer, writing your first lines of code in the real world is always a challenge. Here are some of the most common pitfalls for new programmers.
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now