Mouse Click Issue

[JTaylor]

I have a weird problem. 

I have an open Dialog which opens a Sub-Dialog using the Dialog(SubDialog) function.   Functionally it works fine.   When it opens I can tab down through the controls, press enter and activate the default button, etc.   What I cannot do though is click on any thing.  If I press Alt+Tab changing windows and then Alt+Tab back or manually change focus in some fashion back to this SubDialog then I can click as expected. 

Just had a thought and tried calling the Sub-Dialog from a PushButton and it works as it should.   Currently I am calling it by right-clicking on a control in the Timer Event.   I have tried disabling the Timer if it meets the necessary criteria as well as disabling the main dialog but that doesn't seem to make a difference.   Here is the code in the Timer Event.

Code (winbatch) Select Expand


    wga = WinGetActive()
    cf  = DialogControlState(MME_Handle, "rv_MMe_report", @dcsGetFocus, 0)
    mi  = MouseInfo(4)
    If wga == "Menu Example" && mi == 1 && cf == "rv_MMe_report" Then
  ;   DialogProcOptions(MMe_Handle, @deTimer,0)                             ; TimerEvent (0- Off).
  ;    DialogProcOptions(MMe_Handle, @dpoDisable,2)                         ; Dialog Disable (1-Disable, 2-Wait cursor, 0-Enable).
       Dialog("SMenu")
  ;    DialogProcOptions(MMe_Handle, @dpoDisable,0)                         ; Dialog Disable (1-Disable, 2-Wait cursor, 0-Enable).
  ;   DialogProcOptions(MMe_Handle, @deTimer,100)                           ; TimerEvent (0- Off).
     EndIf



Suggestions?    Thanks.


Jim

[JTaylor]

A bit more info.  It seems that something with the "If" statement causes the problem.   If I comment out the "If" statement it works.   If I change the code and set a flag and call Dialog outside the Timer Event after shutting off the Timer the same problem happens, if I call the Dialog within an "If" statement.

Jim

[kdmoyers]

quickie snap-look makes me wonder what would happen if you left the THEN off the IF statement.  I don't think it's required.  You probably already considered this.
-Kirby

[JTaylor]

Thanks but no difference.   I tried a While statement as well.   Same behavior.

Jim

[td]

The description of the problem matches some but not all of the symptoms of a mouse capture issue but WinBatch doesn't ever attempt to capture the mouse. So it doesn't make a lot of sense as an explanation.

Also, note that the Dialog function will automatically disable a WIL dialog when the Dialog function is called from the WIL dialog's UDC.

[JTaylor]

Good to know on the last point.   I have been trying everything I can think of but still at a loss.   The behavior is consistent.  Here is a stripped down version.  Just right-click on the ReportView Control.

Thanks.

Jim

[JTaylor]

Still banging away at this and have concluded that the issue is the clicking on the ReportView to call a sub-dialog.  Even setting the focus prior to calling the Sub-Dialog doesn't help.   I have worked around the issue, I think, by creating an invisible button and using MouseClickBtn() prior to opening the Sub-Dialog.  This seems to solve the problem.

Is this something that can be and should be fixed or is it expected?

Jim

[td]

Basically, your timer is preventing the dialog from processing the mouse right click messages (note the plural) and the OS does something similar to a mouse capture until the messages get processed.  It is not something that should be "fixed".     

[JTaylor]

Okay.   Wasn't sure since it happens even if I turn off the timer before calling the subdialog.  In any event, need to move ahead and if it was something that needed to be fixed I assume it would be a while before that occurred anyway.   As mentioned, the MouseClickBtn() seems to have fixed things as this is only an issue with the ReportView and not other controls, as far as I can tell.  Perhaps if I did more testing I would change my mind on that issue though.

Thanks.

Jim

[td]

The reason you see the behavior with the ReportView control is because of the way MSFT implemented the control with respect to mouse input.

[JTaylor]

Okay.  Good to know.  Sounds like it is more than simply a Mouse and Timer issue but rather something primarily in the context of ReportView.  In any event, thanks again.  I have a way to move ahead.

Jim

[td]

Other Common Controls use the same strategy for mouse input.  It is, however, the OS handling of mouse input that is ultimately responsible. 

[kdmoyers]

This is really interesting to me, and something I'm likely to hit someday because I do both reportviews, and sub-dialogs.  I just have not yet combined them.  Thanks for sharing!

[td]

Unless you are using a rapidly firing timer event to launch a WIL dialog inside a user-defined-callback of another dialog and a user clicks a reportview control of the dialog with the event, it will have no impact.

[kdmoyers]

Hmmm... yes I see, I think.  As it happens, rapidly (.1 sec) firing dialogs are my specialty, so I'll keep this in the back of my mind, in case I see trouble.
As I've often opined, this forum and it's participants is one of the best things about winbatch.

[td]

A simple workaround might be to add an invisible context menu to the REPORTVIEW control and add DialogProcOptions @deMiInit to the @deInit section of the main dialog's UDF/S.  This should allow the control to finish processing the context mouse button messages before the dialog processed the timer event.

[JTaylor]

I think I mentioned this above somewhere but did a similar thing but used an invisible PUSHBUTTON and MouseClickBtn() which solved the problem as well.

Jim

[td]

It may not matter but I would stick to the DialogProcOptions @deMiInit and menu method unless it proves not to work for some reason.   It allows the dialog and control window procedures to perform their standard message handling.  Whereas, relying on some random mouse messages sent to those procedures is relying on undocumented Windows behavior.  Not saying that the latter will ever fail but it does happen that undocumented Windows behavior consistent for a long time suddenly isn't.  This seems to be particularly true of the semiannual Windows 10 updates.