SetValue() firing Notify() on init and state restore?

[Waverley Instruments]

Interesting. It looks like toggle button change events are delivered on mouse down when the button is part of a radio group but on mouse up when not.

I guess it makes more sense that you'd want immediate visual feedback for radio buttons? Not having it for toggles or standard buttons is maybe just about being consistent with buttons on other platforms, rather than making sense

[ColinP]

It appears that toggle buttons with group ID of 0 (in other words standalone toggle buttons) are the only GUI components in VM that don't change their value or send an event notification on mouse down.

They do at least change visual state on mouse down but the value returned by GetValue() doesn't update until button up nor does a button change event get posted to the notify queue (assuming there is actually a queue).

To me this looks like something that's accidentally slipped through the implementation net rather than anything intentionally designed - given that regular buttons, toggle buttons in radio groups, knobs, sliders and switches all do update immediately on button down.

[ColinP]

Actually switches and editable text fields have slightly more complicated behaviour.

Mouse down on a switch followed by in-axis mouse move changes the switch value before the mouse up. Mouse down followed by a rapid mouse up kicks the switch in the direction of travel but only after the mouse up (this direction of travel memory is only really apparent with switches that have more than two states). This behaviour makes sense as it conforms with intuition.

But a mouse down followed by a delayed mouse up has no effect.

Editable text has a similarly different behaviour depending on how quickly the mouse up follows mouse down and on whether the field already has focus or not.

I hadn't really paid enough attention to the exact details of these subtle behaviours in the past so this thread has been educational.

[UrbanCyborg]

That would make sense for implementing double-click behavior, no?

Reid

[ColinP]

That would make sense for implementing double-click behavior, no?

Reid

The timing thing?

With editable text fields yes. And I expect things to be a little vague with text fields anyway as historically there's always been some subtle differences between different systems.

But a double click on a switch appears to behave as if it was two single clicks so I'm not sure what the purpose of ignoring a slow click is. Although on reflection I suppose a slow click can be viewed as an aborted drag so does makes sense after all.

Double clicks work well on knobs - either resetting to default or opening edit value as chosen in the settings. While at the same time knobs still respond immediately to a mouse down + mouse move without waiting for a mouse up. And the timing of the mouse up has no effect - you can hold the mouse button down as long as you like. All exactly as one would expect.

So my only real head scratching is to why toggle buttons that aren't in a radio group don't change value and send an event on mouse down. They appear to be an outlier given how the rest of the interface works.

This is just subtle detail. I'm not saying it's a major problem.

[Waverley Instruments]

Just wanted to say thanks for the contributions to this thread and time taken for forensics!

Also... here's a bit of an interesting "gotcha" when relying on stuff like mouse-up events on certain controls. Ain't gonna fly if the user is assigning those controls to a MIDI controller.



I for one, have at least one workaround to come up with for that scenario!

[UrbanCyborg]

Ah. I hadn't thought of MIDI controllers. I'll have to revisit my code and see if it can be made to work on mouse up. I'm not sanguine about the likelihood, though.

Reid