›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Double click fires

jimvaughanjimvaughan
in SRP EditTable Control
Not sure what I am doing wrong, I have used this control elsewhere without this issue.

The form opens but if I move focus away from the control instead of a single click firing, I get a double click. Same issue if I click back on the form I get a double click as the form gets focus.

Create event code calls this code.

Subroutine Qualify_All_Ole(Ctrl)
*********************************************************************
* visim jrv 4-13-09 *
* qualify all ole events *
* new code from Don Bakke *
*********************************************************************
DECLARE FUNCTION Send_Message, Get_Property

Qualify = ""
Qualify<1> = 1
Qualify<3> = ""

If Get_Property(@Window, "@DIALOG_BOX") EQ 1 then
// Modal Dialog Boxes cannot process synchronous events so the asynchronous flag must be used.
// There is no way to programmatically detect if the current window is running as a dialog box.
// Therefore the CREATE event in the current window's commuter module should set this UDP in
// order for this to be set correctly here.
Qualify<4> = 0 ; // Asynchronous event processing
end else
Qualify<4> = 2 ; // Synchronous event processing
end

* not sure what this is for (from Don Bakke SRP)
* If EventExists then
* Qualify<2> = 13:"*":EventKey
* end

Ret_Val = Send_Message(Ctrl, "QUALIFY_EVENT", "ALL_OLES", Qualify)
// Qualify EditTable LostFocus and GotFocus events as asynchronous. This worksaround a known bug where
// clicking away from a window with an EditTable and then back causes a double-click to fire.
Qualify<4> = 0

Ret_Val = Send_Message(Ctrl, "QUALIFY_EVENT", "OLE.LostFocus", Qualify)
Ret_Val = Send_Message(Ctrl, "QUALIFY_EVENT", "OLE.GotFocus", Qualify)

Return

Comments

  • KevinFournierKevinFournier
    This issue is a thorn in my side. I've seen it on occasion and have never been able to fix it. I've put literal days into debugging it, and all I can tell you is that Windows sends me WM_LBUTTONDBLCLK instead of WM_LBUTTONCLK. It has something to do with focus. Qualifying focus events asynchronously seemed to be best remedy, but clearly you're already doing that.
  • jimvaughanjimvaughan
    I had not seen it before. It's now happening on all my forms that use this control. I can't believe I have never noticed this before, so the question is what changed. Let me look at a different install of my software and see if it happens elsewhere.
  • KevinFournierKevinFournier
    edited April 2020
    I will say, we haven't seen much of this bug in a long time. I'm curious to know if it's happening elsewhere.
  • jimvaughanjimvaughan
    It's happening on at least one of my co-workers installs. On my system, it's completely reproducible. By way of example. I have two MDI child windows open that do not use your edittable. If I then open a new MDI child window that does use your control and it gets focus. If I then click on the title bar of one of the other windows, it maximizes (a double click event fires).
  • jimvaughanjimvaughan
    Make that three installs.
  • DonBakkeDonBakke
    As Kevin noted, it's been a thorn for a LONG time. As I recall, it seems isolated to MDI Children. I remember encountering this years ago when switching between MDI Children by clicking on the caption bar and noticing that the window would always maximize (as you discovered). That eventually led to us discovering that a double-click was being sent. Perhaps you never noticed it before because you normally clicked on areas that didn't care if it was a single or double-click.
Sign In or Register to comment.