David Giovannini
April 21st, 1999, 12:12 PM
Hello,
This is a strange problem I encountered. I have a solution- may not be the best one.
When a user double clicks in a list box the list box always, and correctly, receives 1 single and 1 double click message.
If the result of the double click message is to create a new frame-window (such as an item editor) and a control on the new frame occupies the same screen coordinates as the double click--it will receive a single click message.
My hypothesis is that the "eat secong click logic" is occuring after the double click message is sent (and new frame is openned). The logic would naturally compare the 1st and 2nd click windows to see if they are the same. If not then the second click is not eaten and sent to the top most control.
The solution I came up with is to initially disable the frame and on a one-shot 3 tenths of a second timer enable the window. The disabled state eats the second click while being to fast to interfere with the user experience.
I hope this helps anybody with the same problem. If anybody can shed more light or have a better solution I would like to hear.
Dave
P.S.
I just wrote a simple Win32 app. It does not have the same glitch.
This is a strange problem I encountered. I have a solution- may not be the best one.
When a user double clicks in a list box the list box always, and correctly, receives 1 single and 1 double click message.
If the result of the double click message is to create a new frame-window (such as an item editor) and a control on the new frame occupies the same screen coordinates as the double click--it will receive a single click message.
My hypothesis is that the "eat secong click logic" is occuring after the double click message is sent (and new frame is openned). The logic would naturally compare the 1st and 2nd click windows to see if they are the same. If not then the second click is not eaten and sent to the top most control.
The solution I came up with is to initially disable the frame and on a one-shot 3 tenths of a second timer enable the window. The disabled state eats the second click while being to fast to interfere with the user experience.
I hope this helps anybody with the same problem. If anybody can shed more light or have a better solution I would like to hear.
Dave
P.S.
I just wrote a simple Win32 app. It does not have the same glitch.