Single-Clicks being returned for button type 10 when double clicking or dragging
Graeme (8815) 106 posts |
I am using Wimp button type 10 on some icons. This allows click, double-click and dragging. When I double-click or drag I get the single click sent first and then the double/drag. How do filter out the single click until we know it is a single click? Does the Wimp have a facility to this or do I have to sit on the null event until the double-click delay time has ended and then I know it is a single-click if I didn’t get the other event? |
Steve Pampling (1551) 8172 posts |
It’s always a single click, unless the interval between physical clicks is shorter than the system set delay time set in the Mouse Settings “Double-Click delay” and you haven’t moved the mouse pointer more than the configured number of OS units between clicks. |
Steve Fryatt (216) 2105 posts |
As the other Steve says, that’s kind of how the RISC OS UI works, look-and-feel-wise.
My first question would be: why do you want to do this? My gut feeling would be that in most cases, you’re asking the question because you’re doing it wrong. If you look closely at places where double-clicks are used in RISC OS, the click-then-double-click (or -then-drag) approach is what you need because the first click selects the item under the mouse (if it isn’t already) and the the second click or drag then acts on that in a special way because it happens quickly. That said, there are some occasions where it’s useful. After about 30 years of writing RISC OS software, I finally found a need to do it earlier this year, because I was faced with implementing an unchangeable API which specifically did not want the click up front. Fortunately the other side of the API worked out the double-clicks, so I was able to use You can opt for button type 8 if you want clicks and double clicks, but if you need all three events then you’re probably stuck.
If you do go down this route then a better approach, I’d suggest, would be to use Wimp_PollIdle to request a single Null event after the double-click or drag timeout. Remember that these times can be configured by the user, separately for double-clicks and drags, so you’ll need to check regularly to see if these have been changed and what they are. Again, I’d suggest considering why you need to do this before going for a hack like this. The use-case above provides a non-RISC OS-y experience to the user, but since there was no way that the API could be changed (as the other side of it is already in use by a lot of applications ported from other platforms), breaking the Style Guide was a fair compromise. More generally, users’ muscle-memory expects things to work in a certain way. |
Graeme (8815) 106 posts |
I was thinking more along the lines of toolbar icons, rather than filer/object icons in a window. Imagine a word processor with a font icon in the toolbar. Select opens a basic window to choose a font. Adjust will set selected text in the document to the last chosen font and menu opens the document main menu, so all single clicks are assigned. Double-clicking the icon could open an advanced window to choose the font with more options like paragraph formatting, saving to styles and more. This is where Risc OS suffers. A double-click now sends a single-click to the application which opens the basic font window. The second click is possibly never received because the basic font window could open over the icon you are double-clicking. If it was possible to not send the single-click event until the time was up or the mouse was moved or a double-click/drag was received then the single-click would open the basic font window only when we are sure it is not a double-click or drag. Guess it will have to be a null event for the few icons that could require it. I may test it but it may also seem odd to click an icon, nothing happen for a little while if you don’t move the mouse so you click again – thinking you have clicked once but actually now you have double-clicked! |
David J. Ruck (33) 1636 posts |
Single/double click/drag icon is there for a filer type interface where a single click selects an item, a double click opens the file and a drag copies/moves. You should not overload a toolbar button with different actions for single/double click/drag, it will be very confusing. For buttons stick to two actions using single clicks with select or adjust. Double clicks or drags of toolbar buttons will not be actions the user will expected to perform. |
Steve Pampling (1551) 8172 posts |
Menu? |
Stuart Painting (5389) 714 posts |
There are a few other mechanisms you could use instead of repurposing double-click. How about Alt-click? Or Ctrl-click? Alternatively, you could put an “Advanced options” button/item on the window/menu opened by the first click. Still only 2 clicks in total. |
Steve Fryatt (216) 2105 posts |
More obvious approaches would seem to be: 1. Make the advanced dialogue accessible from (or a superset of) the simple dialogue. Use an action button, or the window’s toggle size icon, to switch between them. 2. Use one of Select or Adjust to open a context menu. 3. Use click and hold (which you’ll need to implement yourself, but it should be easy to do with the existing click event and a timed Null poll) to get the extra features.
Exactly. Double-click has a very specific purpose on RISC OS (and other OSs): it acts on a selectable item, selecting it on the first click and acting on the second. Toolbar button’s aren’t selectable, so double-click isn’t applicable. Users expect this, whether they realise it or not. Messing with the behaviour, including adding a delay to detect whether a click is single or double, will confuse them.
Yes, because this is exactly what is required for implementing the defined purpose of a double-click. The application needs the first click, so that it can select the item being double-clicked on. Watch the Filer, and see how it acts on both clicks.
Hm. Did you actually read my post? You don’t mention dragging here, so as far as I can tell the solution that I gave you would do exactly what you’re trying to do. With a button type 8, single clicks are returned when the mouse is released and/or after the double click has timed out1. In the example application that I pointed you to, I do exactly this with drags using button type 7 – you can download a copy and try it if you don’t believe me. But my wider point still stands: I don’t think you actually want to do it for this use-case… 1 I assume. That’s how button type 7 works for drags, at least – I’ve not needed to do it with double-clicks, but the PRM describes the two actions in the same way IIRC. As you note, double-clicks are tricky because the Wimp has to assume that a second click could follow at any time until the end of the delay period. That’s why click-and-hold wins, because it’s a conscious action by the user to hold the mouse button down: if they don’t, then the system responds immediately to the single click in the usual way. |
Simon Willcocks (1499) 519 posts |
Why not have a button in the font window for advanced mode, or have a toggle between basic and advanced? Or have menu over the font icon open a font menu of some kind? Just how basic is the basic window, couldn’t it be a one or two level deep menu? Edit: Sorry, late to the party. |