How to prevent a scroll bar in a list box responding to the double-click event

[Alastair]

How do you prevent the scroll bar in a list box control responding to the double click event. We use the double click event to bring up another dialog, so the user can change the information shown in the list. If the scroll bar is clicked too fast though the dialog is generated for the first item (index=0) in the list. Is there a way around this?

Alastair

[SachaE]

Hi Alastair,
the trick is knowing how wide the control is , and how wide the scroll bars are. You let the callback function as normal, but you then get the relative mouse position, and check the x co-ordinate against this.
Attached is the .c file I checked this out with.

Hope that helps
S.

[Alastair]

Thanks

I was just about convinced that this was the only way to do it, I was hoping that there might be a slightly more elegant way though.

I can't think of a case where a double-click on a scroll bar would be needed, so is this a design problem with the control?

[SachaE]

Hi Alastair,
good question - the only reason I might want to look at a double click on a scrollbar would be maybe to scroll to the bottom, or top (depending on where I was on the scrollbar) without having to scroll all the way by hand. There's probably a million and one other uses, but I guess that's why it's left in - there's always a way to add a little extra funcionality to your programs if the designer of the tools didn't think too constrained.

Hope that helps.

S.

[LuisG]

Hello, Alastair

The reason that this is not a design problem with the control has to do with the nature of double-click events (and single-click and keypress events). Unlike other high level events such as val change and commit events, the mouse and keyboard events are very low level events. They are sent to the callback function before the control ever processes those events. This is how the callback is able to "swallow" those events, and prevent the control from receiving them. Effectively, at the time that the callback receives those events, there is no notion of what kind of control will even receive the event, let alone what part of the control the mouse is over. These events are intended to allow programmers to have low-level control of t
he UI, in most cases to supersede the default behavior of the control.

Having said this, we recognize that oftentimes programmers would like a more elegant solution to find out over what part of the control a mouse click took place. With this in mind, the next version of CVI will have a function that will convert coordinates to hot spots on some of the new controls, and on listboxes as well.

In the meanwhile, keep in mind that if all you need to do is perform some action when your user double-clicks on a listbox item, then it should be sufficient to catch the EVENT_COMMIT, which is sent to the callback at that time.

Luis Gomes
NI

this in mind

[Ken-This-is-my-stinking-a]

WOW!!!

I have looked through the forums to try and find a way of fixing this (rather than tell users thats just the way it is), but could not find an answer.

I guess I was thinking about a different search term. But, I found it today, looked a the code and got it working!

I wasn't thinking of checking the size of the panel and scroll bar with the position of the mouse, but that is great.

I just kept looking for something related with the creation of the box. Someone else even told me all I had to do was to create the text box and scroll bar separately!

So, kudos to SachaE for this solution!