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

I can't distinguish between a CLICK and a DBLCLK event in an edit table

alvaroafernandezalvaroafernandez
in OpenInsight
The title says it all...

My desired behavior for the form is:
* When I click on a row, I will put some explanatory text in a TEXT box, but remain in the form context, i.e. I don't leave.
* When I double-click on that same row, I want it to act like clicking and , i.e. I want to take the row information, do some processing, and leave the form.

First I check for the edit table control being activated, then I check for the event being fired, CLICK vs DBLCLK.

My problem is: I can't capture a double-click event, no matter how fast or slow I double-click or what I do.

Whenever and however I double-click the row, the event in the debugger shows CLICK, not DBLCLK.

Is there a trick to capturing a double-click?

Comments

  • DonBakkeDonBakke
    Are you seeing this problem even if you do not have debugs in your CLICK event handler?
  • alvaroafernandezalvaroafernandez
    edited December 2022
    Yes, I am. The way the event is handled in the commuter module is shown below, and the behavior persists even without 'debug' statements. This is copied straight out of the source code.

    The EVENT variable is never equal to 'DBLCLK', regardless of how fast or slow I double-click the edit table row. The EVENT variable always has 'CLICK'.
    Case Control = "TABLE_VALUES" Begin Case Case EVENT = 'CLICK' debug * IF USER ONLY CLICKS, DISPLAY FIELD INFO IN THE INFO WINDOW. TMP = Get_Property(EDITTABLE,"SELPOS") TH = TMP<2> ; * TMP<1> IS THE COLUMN; WE DONT CARE WHICH COLUMN WAS CLICKED. VDESC = GET_PROPERTY(@WINDOW,"@VDESC") TH_VDESC = TRIM( VDESC<TH> ) ; * GET THE TH VALUE OF THE DESCRIPTIONS. VPRCE = GET_PROPERTY(@WINDOW,"@VPRCE") TH_VPRCE = VPRCE<TH> TH_VDESC_TAG = '' IF TH_VPRCE = 'P' Then TH_VDESC_TAG = "**PROTECTED** " TH_VDESC = TH_VDESC_TAG : TH_VDESC CALL Set_Property(MESSAGES,"TEXT",TH_VDESC) Case EVENT = 'DBLCLK' debug
  • DonBakkeDonBakke
    ...the behavior persists even without 'debug' statements.

    That was going to be my next question. I've seen situations like this before, but they are almost always related to some type of interference occurring in the CLICK event. Once the CLICK event executes it practically interrupts the DBLCLK event. Does this problem occur if you keep the CLICK event in the commuter but rem out all of the other lines related to the CLICK event? My expectation is that both events can work as long as the CLICK event doesn't do much.
  • alvaroafernandezalvaroafernandez
    edited December 2022
    It's more extreme. The only way I can get 'DBLCLK' to appear as an EVENT, is if I comment out everything from the CLICK event.

    So only an empty CLICK event allows a DBLCLK event to happen. Even the presence of a single debug statement for the "CLICK" event makes it fire, ignoring any possible DBLCLK event generation.

    I can work with this, but for the UI it would feel more intuitive if double-clicking would be just like clicking and pressing OK - that's what I'm trying to implement as the form's behavior.
  • BarryStevensBarryStevens
    Do the dblclk check first?
  • alvaroafernandezalvaroafernandez
    I'll try that, but the debugger always shows the event coming in to be click.

    Basically, OI doesn't give me the dblclk event ever. The moment I click or double click a row, OI is off to the races, and the commuter module shows the event as click.

    So I'm not sure how changing the order in which I check what a variable is in the subroutine would affect the value OI presents me.

    Only by commenting out the click handler in the commuter module do I ever see a dblclk event generated.
  • DonBakkeDonBakke
    Even the presence of a single debug statement for the "CLICK" event makes it fire, ignoring any possible DBLCLK event generation.

    This is is the point I was trying to make. Having a debug statement is itself a (if not the) problem. It is interrupting the engine long enough to lose track of the DBLCLK event. You confirmed that if you rem out everything (including the debug) then the DBLCLK fires. What happens if you allow just one command to run in the CLICK event, such as one of the Get_Property calls? Will that stop the DBLCLK event?
  • alvaroafernandezalvaroafernandez
    I get it, and I got it. :-) Taking out the debugs allowed me to detect the dblclk successfully. Thank you! I would not have gotten this. The debugs were in there because I wasn't picking up the dblclk to begin with (!) but I guess that earlier issue was for another reason.
  • KevinFournierKevinFournier
    Some Windows API trivia. Windows sends one of these messages to every control on a left mouse button press. WM_LBUTTONDOWN, WM_LBUTTONUP, and WM_LBUTTONDBLCLK. The last message is automatically handled by the operating system (it's not something Revelation programmed) and occurs when the left mouse button is pressed within 500ms from the first (though users can change this). Thus, WM_LBUTTONDBLCLK will always have a WM_LBUTTONDOWN preceding it. If your code takes longer than 500ms to do anything during the WM_LBUTTONDOWN message, then the next click will be a WM_LBUTTONDOWN instead of a WM_LBUTTONDBLCLK. After all, Windows doesn't know that you're debugging.

    Interestingly, I've had to deal with the opposite issue. Some of my controls don't use WM_LBUTTONDBLCLK, but Windows doesn't care. It fires it anyway. If I were only to handle WM_LBUTTONDOWN, then my control would feel unresponsive because every other click (if done fast enough) would be a WM_LBUTTONDBLCLK instead. So, I have to make sure WM_LBUTTONDBLCLK calls the same code as WM_LBUTTONDOWN to make sure every click behaves the same.

    Some events are just a pain to debug because the debugging process triggers the events differently. Put a debug in GOTFOCUS, LOSTFOCUS, or ACTIVATED and enjoy the rest of your hair getting pulled out. :)
Sign In or Register to comment.