SRP Edittable onDblClick not working

kingkennethd

Hello,
For some reason, I am having an issue getting the onDblClick event to fire on the SRP Edittable.
1 - I have an OpenInsight Window with an OLEControl named OLE_ADDRESS_GRID

2 - In order to test what "click" event is firing, I put the following script on the OLE Control Properties QuickEvent of the "OLE" Event on the OLE_ADDRESS_GRID control:
if not(indexc(EventName,'Chang',1)) and not(indexc(EventName,'Edit',1)) and not(indexc(EventName,'Focus',1)) and not(indexc(EventName,'Mouse',1)) then debug; *** This should exclude all non-click events from entering the debugger

3 - When the OI Window is created via an OpenInsight stored procedure the following statements are executed:
oleControl = (@Window:'.OLE_ADDRESS_GRID'
set_Property(oleControl,"OLE.Dimension",6:@fm:20)
set_Property(oleControl,"OLE.AutoNumbers,"I":@vm:1)
set_Property(oleControl,"OLE.CellEditMode[All;All]","E":@fm:"0")
set_Property(oleControl,"OLE.DataRow[All]",19)
set_Property(oleControl,"OLE.DblClickToEdit",0)
eventQualifier = 1
eventQualifier<4> = 1
eventQualifier<7> = 1
rtnVal = send_Message(@Window:'.OLE_ADDRESS_GRID','QUALIFY_EVENT','ALL_OLES',eventQualifier)

4 - When the Window is launched and I double click the left mouse button nothing happens. If I click, then the script on the OLE_ADDRESS_GRID executes and enters the debugger as programmed, but that is the ONLY event that causes the script to enter the debugger.

I cannot get the Double-click event to work on any SRP EditTable and I have been battling this for days before posting here.
Can you please offer some advice on what I may try next or what I may be doing wrong?
Thanks,
>>> Ken

Kenneth D. King
GAAP Software, Inc.
3035 NE 5th Terrace,
Fort Lauderdale, FL 33334-2050
(954) 533-6769 Office
mailto:kking@gaap.com

KevinFournier

Double clicks are a pain, mostly because of Microsoft standards. If the cell is in the edit mode, then double click means, "highlight a word". In order to for the double click event to fire, the cell cannot be in edit mode. Pressing ESC gets you out of edit mode. You can also set the default edit mode of a cell using the CellEditMode.

I'm willing to entertain the idea of adding a property that overrides the default behavior of double clicks while in edit mode, but many people are used to being able to double click to highlight data, so I wouldn't want to override it by default. In my experience, tables that respond to double clicks generally aren't data-entry heavy, so defaulting to non-edit mode tends not to be a problem.

Note also that, even if a cell is not in edit mode, the user can immediately get back into edit mode by typing any characters. So, not being in edit mode shouldn't add too much inconvenience.

DonBakke

Ken,

This isn't necessarily relevant to your specific problem, but I would like to suggest that you replace your ALL_OLES special keyword with individual OLE events that you want to qualify. Since OI 9.x, qualifying with ALL_OLES has been known to cause problems. Usually this results in performance loss, but there are other odd behaviors as well. The control that has been most affected by this is the SRP EditTable control.

kingkennethd

OK, problem solved. It seems that the ONLY way that I can get the onDblClick event to work is to:
1 - qualify just the events I want to handle, including onDblClick (as per Don's suggestion). Do not qualify the onClick event.
2 - You must set the CellEditMode to "N" as per Kevin's suggestion, otherwise the first click causes the cell to enter edit mode and the second mouse click, i.e. double-click does nothing.
I also agree with Kevin's observation that typically the double-click is used to highlight data, but double-clicking is also heavily used to provide "drill-down" functionality, which is what I wanted. In my experience, the two are usually mutually exclusive, so I now know how to properly handle the combination of CellEditMode and onDblClick.
Thanks guys.
>>> Ken

kingkennethd

One further observation...
Kevin, shouldn't the
set_Property(oleControl,"OLE.DblClickToEdit",0)
have "turned off" the conflict of having the double-click enter edit mode instead of forwarding the event to the application?
>>> Ken

KevinFournier

Sort of. No matter what you set CellEditMode to, double-clicking still puts a cell into edit mode. The DblClickToEdit property was added to disable that feature. You're problem was that single clicks were putting the cell into edit mode, which is due to the CellEditMode settings. So, to gear the table towards drill-down, the solution is to set both CellEditMode to "N" and DblClickToEdit to 0.