Page 1 of 1

controlMove message

Posted: Fri Oct 03, 2014 4:09 pm
by dunbarx
When moving a control with the "move" command, no messages are sent while that process is underway. Like the "mouseMove" message, which can be used in a myriad of ways, it would be useful to have a similar message sent during moves:

controlMove newControlH, newControlV

This came up in another thread, where the OP wanted to determine when a moving control intersected another control. Once the move command had been executed, the only way to determine that condition was to run a concurrent recursive handler that checked the value of the intersect function continuously. All well and good, but it would have been simpler and more direct to be able to trap a "controlMove" message instead.

Craig Newman

Re: controlMove message

Posted: Sun Oct 05, 2014 8:22 pm
by [-hh]
I second this and suggest to use
controlMove currentLoc, nextLoc
because startLoc and endLoc are/were/will be also locs of the object.
And nextLoc could make sense if one is moving along a path of points.

Re: controlMove message

Posted: Sun Oct 05, 2014 8:43 pm
by sefrojones
I would like to see this feature as well. :D

Re: controlMove message

Posted: Mon Oct 06, 2014 2:06 am
by dunbarx
Hermann.

Interesting.

Can you give an example of how knowing the pending loc of a moving control as it traverses from point to point can be used to advantage? Perhaps to stop or divert that motion at a certain point? Maybe if, along that path, a condition would soon be attained that mattered (say, for example, the moving object went too far in one direction)?

If so, maybe the second param you propose might be a list of all the pending points? This list would be trimmed as each "milestone" was reached.

Craig

Re: controlMove message

Posted: Tue Oct 07, 2014 12:21 am
by [-hh]
Hi Craig.

As an illustrative example let's have the project "Kitchen clock" (@Sefro: Would count this as a "game"?):
Three objects move from quite different locations to one end point, say "high noon", the time you wish to eat, indicating the remaining time. They all shall reach this point at the 'same' time, exact as possible on user's machine and moving as smooth as possible to there.

No problem for three timers (potatoes, meat and leek) to count down to high noon, the time you wish to eat. Now compute the remaining way of three "hands" on your kitchen clock for their move along the points (!) of a circle to high noon.

As always, your machine is doing a lot of things while you pretend to be busy with cooking. So some of the timers may be waiting in a queue after other things to do: Again no problem because new moves cancel old ones. One could use this somehow, but you'll loose smoothness of movement then.

To avoid this you have to compute the time your hands need to keep smoothly the clock pulse. For this you need the *actual* current location of your hand on its way to high noon, not the location where it should be in theory.

This math would become simpler with the info from your message. One could continuously update the time needed for the remaining movement. Nothing separately needed any more for getting these locs.

Good Appetite!
Hermann