{{tag>category:"OpenInsight" author:"Oystein Reigem" author:"Donald Bakke" author:"Mike Ruane"}}
[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]
==== Doubleclick in dialog box detected by underlying window (OpenInsight) ====
=== At 11 JUL 2000 09:52:33AM Oystein Reigem wrote: ===
I have a window X where I've qualified for a left button click. From window X I bring up a dialog box Y with a list box. When I doubleclick in the list box an item is selected and the dialog closed. So far so good. But when the point where I doubleclick is directly above X's background, or a bitmap control in X, X's button click handler starts running.
My mistake? Known problem? Any suggestions for a workaround?
- Oystein -
----
=== At 12 JUL 2000 12:21AM Donald Bakke wrote: ===
Oystein,
I can't seem to duplicate your problem. I've tried various combinations of Dialog_Box/Start_Window and End_Dialog/End_Window and I never get the double-click to also launch a button from the parent window. I am making sure the position of the mouse is directly over the button of course.
I have seen a similar problem where pressing ESC to cancel a Popup gets passed back to the Parent window and if that Parent window uses ESC to close itself (i.e. as a default Cancel button) then this window gets closed (or attempts to) as well.
The crude kludge I used was to set a UDP or global variable with a value when the Popup is launched (this assumes code is being used to launch the popup). The CLOSE event then checks this flag first before executing itself. If the flag is set all the CLOSE event will do is reset the flag so it can successfully close when its supposed to. The code that launches the Popup will also reset the flag after it has completed execution.
I believe you could do a similar process with your CLICK events. Not pretty, but it should work.
dbakke@srpcs.com
[url=http://www.srpcs.com]SRP Computer Solutions[/url]
[img]http://www.srpcs.com/srpicon1.gif[/img]
----
=== At 12 JUL 2000 04:23AM Oystein Reigem wrote: ===
Don,
[i]I can't seem to duplicate your problem. I've tried various combinations of Dialog_Box/Start_Window and End_Dialog/End_Window and I never get the double-click to also launch a button from the parent window. I am making sure the position of the mouse is directly over the button of course.[/i]
But it [i]doesn't[/i] happen with buttons and edit controls. Just with [i]window client area and bitmaps[/i], when I've [i]enabled left button click[/i] with QUALIFY_EVENT. Perhaps I should have said so explicitly.
Could it be something with the way doubleclicks are handled in OI?????? I get the feeling it's a hack. E.g one cannot have both a CLICK and a DBLCLK handler for a control; DBLCLK never gets a chance to run.
[i]...kludge... ...flag...[/i]
I'm willing to use a workaround. But the dialog is a general one I plan to use everywhere in the app. So it's not ideal with a workaround that means extra code in every calling window.
(Thinking...) But perhaps it's not as bad as I first thought. I mean if I had [i]your[/i] case everywhere it would be bad. I would have to make/change a lot of handlers [i]other[/i] places (CLOSE handlers). But in my case the necessary changes might be more [i]local[/i]. The change I have to do to avoid launching the dialog must be in the dialog launching code itself. So I might be able to write a function that [i]wraps[/i] the ugly stuff.
Still I'd like to pursue the matter a bit further.
More details about my dialog: It's sort of a popup. It has a DBLCLK handler of course. But the DBLCLK handler does nothing except a Send_Event, leaving the work to an OMNIEVENT handler. (The reason for the OMNIEVENT handler is that there are other ways for selecting an item than a doubleclick in the list box.) The OMNIEVENT handler doesn't really do much. It [i]can[/i] do a lot, when the dialog is run with other parameters. The dialog can have a combo box visible instead of the list box, allowing the user to enter a new value, and then the OMNIEVENT handler does some stuff with checking new values. But with a list box it just gets the TEXT or SELPOS value and returns that with a call to End_Dialog.
- Oystein -
----
=== At 12 JUL 2000 05:08PM Mike Ruane wrote: ===
You can't have both a click and dbl-click defined for a control.
When the control receives a click- is this a whole click, or just half a dbl-click?
If just half a dbl-click, how long should it wait?
----
=== At 12 JUL 2000 05:23PM Oystein Reigem wrote: ===
Mike,
[i]You can't have both a click and dbl-click defined for a control.[/i]
In OI app you can't. In apps written with other tools you can. (Can't you???)
Anyway that's not my current problem. I just mentioned it because I thought there might be some connection. Something with doubleclicks in general not handled properly in OI apps.
(Btw - the subject (title) of my posting is slightly misleading. It's not the whole doubleclick that's detected by the underlying window. It must be the second of the doubleclick's two clicks.)
- Oystein -
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=31A4989B90DAC70C85256919004C3930|View this thread on the Works forum...]]