Delaying a slider change and the mouseUp event - help!

rl · 28 Aug 2005

Mouse Enter/Mouse Leave modules would be helpful.

As a workaround I would suggest you track your mouse movements using a Mouse Drag module so that when the mouse reaches the border of the area, the "update value" trigger is fired

oddson · 28 Aug 2005

rl wrote: ... suggest you track your mouse movements using a Mouse Drag module so that when the mouse reaches the border of the area, the "update value" trigger is fired

Yikes! - I was hoping for an easier answer.

I thought the hold=True thing in the showCursor primative would fix it and when it didn't I was hoping there would be something like it that I was just missing.

So there's no mouseLeave event to grab somehow?...

Wait, what's that... I've just searched on 'mouse' in the toolbox and found Mouse Over. I'm going to see if this might help.

Thanx rl

oddson · 29 Aug 2005

D'oh! 😠

after drag trigger does exactly what I was looking for.

The terminology on the accumulate components seems a little 'odd' to me

"after drag" fires after you release 'onMouseUp'

"after change" fires as you drag

I assume "before change" is 'onMouseDown'

malc · 29 Aug 2005

Hi oddson,

We probably need to look at some of this mouse stuff again. Mouse messages are sent to the item that the mouse is over at the time the event occurs so as you say, when the mouse is outside of the slider and you release, you don't get the mouse up.

What we probably need is a way to say "send all mouse messages to this front panel". This is called capturing the mouse (forgive me if you already knopw this). When you get the mouse up you can then release the capture and mouse messages will be sent in the normal way again.

As rl suggests you can use the drag accumulate components as a workaround. This is because they wrap mouse capture and drag monitoring into one handy component. The output connectors are:

Before Change - this trigger is sent just before the current value is changed (whilst dragging) After Change - this trigger is sent just after the current value is changed (whilst dragging) After Drag - this trigger is sent when the mouse has been released and the drag operation has finished.

So you can use a drag accumulate component to capture a mouse up event by handling the After Drag trigger.

Maybe the output labels could be made more clear, do you have any suggestions?

oddson · 29 Aug 2005

malc wrote: Maybe the output labels could be made more clear, do you have any suggestions?

I suspect you may have reservations about these but

on mouse down on drag on mouse up

With or without the 'on'; with or without the spaces.

It was good enough for HyperCard and HTML 😉

malc · 30 Aug 2005

They sound good. However, the before change fires every time you drag not just when you mouse down. So maybe:

before drag after drag mouse up

would be better?

Just to be absolutely clear, as you drag you'll get a sequence of before drag/after drag triggers then a mouse up at the end.

oddson · 30 Aug 2005

Yah! - I thought there was a reason you didn't just go for descriptions based on the mouse state.

(BTW-Your proposed names have 'after drag' changing meaning to what I thought it was. That's how I missed grasping the 'mouse up' implication of it and why it took me so long to realize it was not the right one to update the display value.)

Before you go changing the names, let me sleep on it and see if anyone else has any thoughts.

Going back to the current names for the what follows:

What's the point of having "before change" fire so much? 😕

Does this mean as I drag the mouse I get a before change/after change trigger with each pixel of motion?

malc · 30 Aug 2005

I hear what you're saying. How about "before mouse move" and "after mouse move" ? I'm open to more suggestions. It's a tricky one to describe so succinctly.

oddson wrote: What's the point of having "before change" fire so much? Confused

Does this mean as I drag the mouse I get a before change/after change trigger with each pixel of motion?

You get a before change/after change every time there is a change in the value that the drag operation maps onto (not necessarily every pixel though, but very frequently). The reason for this is to give you all the information you might need to process the change. If a value change results in an update to GUI elements then you often need to store the value before the change in order to compute the smallest area of the panel that needs to be redrawn (often the 'old area' as defined by the previous value and the 'new area' as defined by the new value). That's the main reason that those two triggers are there.

Tom7777 · 30 Aug 2005

As long as the changes will have no effect on schematics and just the names and not order ect change then i think its fine. IMHO i think the current names are ok as they are though. 🙂

Tom7777 · 30 Aug 2005

I think it's just a case that theres not much documentation that names can confuse people, now that theres 3 devs it might be better just to add more detailed tooltip descriptions to modules which you think could confuse users in some way.

oddson · 31 Aug 2005

Tom7777 wrote: ....IMHO i think the current names are ok as they are though. 🙂

I guess I would agree but I see they've already changed to

Value changed* After change After drag

I say move on to other things it's good to go!

* looks like they changed back to 'Before change'

infuzion · 31 Aug 2005

that's a neat idea oddson! BTW, the update display trigger output is ritorical; you can do the samething by connecting the Ratio Float out to the display's trigger in.