Detect the END of a stack move not that it’s moving

[Ed_Ray]

By looking through older dictionaries which stated the movestack message was sent at the END of a stack move and some current forum entries which imply the movestack message somewhere in time was changed to send the message DURING the move, is there a means to determine that the mouse has been released from the title bar thus signifying the END of a move?

Using on mouseup handler within the card won’t work since it only detects the mouse release if one releases a prior click from the body of the card NOT the title bar of the card.

[Possible bug]
I attempted to use the mouse() function which determines the mouse state (up/down) which is detected correctly ALL of the time after a move in win 7 but almost never gets detected right after a move in win 10 even if I put in a delay before the mouse state is checked.

This was so easy before the change since it was not even necessary to look at the state of the mouse because automatically upon mouse release from the title bar, the movestack message was sent.

So can someone provide the means to determine the move has COMPLETED since my workaround of using the mouse() function to determine this only seems to work in windows 7?

[Possible bug]
By the way I did not see what follows in the past posts regarding the movestack message, but were you folks aware that in win 7 the movestack message is sent only at the END of a move as had been stipulated in the older dictionaries?

Please use the attached stack to check out the two possible bugs mentioned above (win 7 sending the movestack message only at the end of a move and the mouse() up state being detected correctly at the end of a move only in win 7 but not in win 10)

By the way in terms of satisfying my curiosity regarding the change to when the moveStack message is sent, was there an overwhelming reason why it was not left as it was in the past with the message sent only at the end of a move due to the following reasons:

[1]Existing “screenMouseLoc” property which specifies the position of the mouse pointer relative to the screen at any given time and the “mouseLoc” function which specifies the position of the mouse relative to the current stack at any given time are available in case it is ever necessary to have any scripting logic adhere to the movement of the mouse in real time meaning it would not be necessary to use the movestack message to be keyed to every single frame DURING the movement of a stack since there exists plenty of alternatives for executing this type of functionality.

[2] In addition it typically would not be efficient to execute and run scripting logic for every single frame of stack movement when tying the logic to the end of the movement would more than suffice.

For all these reasons what had been stipulated in the older dictionaries with regards to sending the message only at the end of a move actually MADE A LOT OF SENSE considering there are plenty alternatives to have logic key off every movement frames.

Thanks

[MaxV]

Just use ResumeStack

[dunbarx]

@Max. I don't see "resumeStack" sent when the mouse is released.

@Ed. This is a kluge and a half, and in v. 6.7. The reason many trusty old messages are not accessible is because in order to drag the card window, the cursor is in the titlebar. Even "mouseMove" is not sent in such an exotic place. But a "mouseEnter" message is sent when you move the cursor back into the working area, and this might be exploited. It does not give instantaneous feedback, of course, but does give you a way to figure out that you have indeed dropped the stack somewhere, and where that stack is now located.

Craig Newman

[Ed_Ray]

@max:
Based on the dict, the resumeStack message is “Sent to the current card when a stack window is brought to the front”.

So I am not sure how this will help me determine the stack move has completed since it is my understanding that the moved stack was already active and at the front while it was being moved and remains at that state when the move completes.

@max and @Dunbarx:
What I need is a fairly easy way to determine the mouse was released from the title bar which in essence signifies the end of a stack move, or any other simple way to determine the stack has stopped moving.

Before they changed the meaning of the movestack message which used to be sent at the END of a stack move not DURING the stack move, it wasn’t even necessary to determine if the mouse had been released from the title bar since the message was automatically sent at the end of the movement which coincided with the release of the mouse from the title bar.

Now the message is sent EVERY single frame the stack is being moved and not at the completion of the movement. This is woefully inefficient if the user just wants to run their logic at the end of the move.
In this case, a bunch of new code that was not necessary before now has to be written just to determine the stack STOPPED moving and to preclude any logic from being executed DURING the movement.

From my perspective there are basically two types of “spaghetti code”. One is the self-induced kind typically the result of lack of programming expertize, lack of basic training or lack of experience. The second is what I call system induced “spaghetti code” which is caused by system changes (like changes to the meaning of messages, batch file parameter meaning changes etc) that perhaps were not well or completely thought out at the time the decision was made to change the system.

This is especially grievous if code that was working fine out in the real world now becomes broken because of the system changes when it is used in a different version of software.

Typically this system induced “spaghetti code” causes the need to unnecessarily insert, implement and test code that was not necessary before the change especially in cases where there was little to no code needed before the system change to achieve required functionality.

Case in point: One way this change could have been done greatly minimizing any mods needed to compensate for the system changes was to simply send the message at the beginning of the movement and at the end of the movement.

This way any code that had depended on the end of the move remained the SAME and any code that needed to be activated DURING the move could simply use a self-created re-settable flag to keep track of the beginning and end of the move thus knowing at all times if they were in the beginning of a move, the middle of a move and at the end of a move. All this done using two or less lines of code (one for a set, the other for a reset).

This is why I originally asked if there had been an overwhelming compelling reason for the change in the meaning of the moveStack message. I had wanted to give some benefit of the doubt but after looking around the forum and other related forums I have yet to see the “compelling” reason for the change. Perhaps some of the more experienced LC folks can provide this information if only for historical reasons.

While waiting for a response to this post, I had come up with some solutions that actually work which others could benefit from (which I will put out in the next post), but in my opinion, compared to how easy this had been to determine, the means are convoluted at best hence your inadvertent system induced “spaghetti code”.

Lastly:
This whole problem is further exasperated by the fact that the moveStack message behaves differently in win 7 than it does for win 10 as detailed on my prior post.

Thanks.

[MaxV]

Try:

Code: Select all

on resumeStack
   answer the time
end resumeStack

It works for me.

[dunbarx]

Max,

If I place a resumeStack handler in the stack script, it only fires when I leave that stack, do something somewhere and return. It does not fire if I grab the titlebar, move the stack around, and then click somewhere in that stack.

Ed. . The only messages I can see at all, as I said, are ones that come forward as you either re-enter the working space of the card window or go somewhere else, either with, say, mouseMove, suspendStack or mouseEnter. Or, and this is a stretch, any of the key/rawKey messages, which seem to fire from the titlebar. Any of those might be kluged to your purpose if you will give up the idea that the mouseRelease HAS to be the event-celebre. This may or may not fit in with your intent, if you need to do something right at that instant, and not just when you simply do almost anything else.

I see what you are saying about changing the way a message is invoked. I would complain to the team with a bug report and see what they say about it.

Craig

[jacque]

LC always tries to be backward compatible and goes to some lengths to ensure that older stacks don't break. If you're seeing an issue with that I'd consider it a bug and would report it.

http://quality.livecode.com

[FourthWorld]

By looking through older dictionaries which stated the movestack message was sent at the END of a stack move and some current forum entries which imply the movestack message somewhere in time was changed to send the message DURING the move, is there a means to determine that the mouse has been released from the title bar thus signifying the END of a move?

I believe the change may have occurred with the transition from Carbon APIs to Cocoa, somewhere in the v6.x time frame. This not only delivered more consistent scripting for us across platforms (the messaging has AFAIK always been that way on Windows and Linux), but IIRC is also a better fit for how Cocoa doles out those messages.

One solution might be to check when the mouse is up from a time sent by the moveStack message. Not particularly elegant, but for such a rare need easy enough.

[dunbarx]

Richard.

Of course, so easy once someone tells you. After all, we do have messages; all we have to do is use them. One might call this a very elegant kluge.

Code: Select all

on movestack
   if the mouse is up then answer the loc of this stack
end movestack

Craig

[Ed_Ray]

@maxv:
I observed the same thing dunbarx did:
“f I place a resumeStack handler in the stack script, it only fires when I leave that stack, do something somewhere and return. It does not fire if I grab the titlebar, move the stack around, and then click somewhere in that stack.

So it does not yield the desired solution of letting me know the stack movement has completed. Nevertheless I appreicate your attempt to help.

@dunbarx:
Thanks for the example you gave but it does not work because as the movestack message currently works which is to send the message every single wasteful frame the stack is moved, the message typically does NOT get sent related to a mouse release when the movement STOPS with a coinciding release because the mouse would still be pressed against the title bar since the user typically releases the mouse from the title bar AFTER the stack has stopped moving. So the last message sent is almost always the one related to a final press against the title bar.

So it seems the intent of LC is to NOT detect mouse releases during the movement including
at the very END of the movement (thus the message is not sent) because the user would typically release the mouse from the title bar AFTER the stack has stopped moving.

Nevertheless a quirk has been observed where mouse releases are occasionally inadvertently picked up right at the end of the movement. This seems to occur if the user is rapidly dragging and then quickly releases the mouse at the SAME time the movement is stopped, all this being done in one contiguous sweeping motion. Therefore If it was never the intention of LC to pick up releases at the end of a move, then these quirks should be considered actual bugs.

@Jacque:

Yes, I am getting ready to report some bugs related to this post, these being:
[1] Windows 7 behaving the opposite of what the movestack message does now namely it sends the message when the move completes NOT during the move.

[2] Occasionally a mouse release is detected if the user rapidly drags the stack and releases the mouse from the title bar at the SAME time the move comes to a complete stop.

I don’t think it was the intention of LC to pick up mouse releases when it continuously sends messages as the stack is moving. In this case the intent would be to pick up mouse presses against the title bar during the move including the last movement where the stack is stopped since the user typically would stop moving the stack BEFORE releasing the mouse from the title bar so it is intentionally difficult to pick up a mouse release in these circumstances.

@Fourthworld:
Appreciate the explanation for the change but I still don’t get the overwhelming reason to change something that worked so simply (sent only when the move ends) and efficiently meaning what could one be possibly be doing that requires a message to be sent every single frame during the move. Do you really want be pinging your logic every single frame, even if it’s not needed?

There are plenty of other functions that can give you the real time changing location of the mouse or use real time points for animation sequences etc if that were the reason every single wasteful frame was needed in real time. So why mess with this particular message that worked so well as it was?

It’s analogous to a construction worker that is executing some work at point A then needs to move from A to B location to do some different function. Will he/she attempt to do any real work as they are moving to location B or are they going to complete the work at location A then wait to get to location B before they start working on the function? See what I mean?

Anyway I came up with a solution somewhere along the line that Fourthworld was expressing.
It is not that straight forward and easy as some would have expected because there are strict requirements that have to be met to get this done correctly.

These requirements are:
[1] It needs to work with the message being sent both at the END of the move and DURING the move because it may take a while before the win 7 bug is fixed and I don’t want to have a large segment of the software world population that still uses win 7 continue to wait before I release the program I have been trying to release the last three-four months now because of all these LC inconsistencies, bugs and quirks that continue to exist between different OS’s.

[2] Have the script compensate for the potential inadvertent mouse release quirks being picked up when the message is continuously sent during the move.

[3] Ensure that only the first detected movement press on the title bar when the message is sent DURING the move initiates a future check of a mouse release from the title bar. This ensures that any logic depending on the end of the stack movement happens only once until the next move occurs.

[4] Ensure that in the case where the message is sent at the end of the move, mouse release from the title bar are ONLY implicitly determined based on the message being sent at the end of the move since this EXACTLY coincides with the release of the mouse button from the title bar.

[5[Ensure for the message sent “during the move” case that the determination of the mouse release be programmatically executed to the extent that any other inadvertent release is ignored.

There are two scripts in the zip file. One is heavily commented to show all the specified requirements were met within the pertinent logic spots and the other one is a completely clean copy for those only interested in the actual code. Considering all the requirements that had to be met, I think it came out fairly clean.

If there are easier ways that all these requirements can be met and still come up with determining when the stack stopped moving I would be more than happy to see it and use it.

As always, thanks for all the helpful comments.

[jacque]

Before you submit any reports, try setting the liveResizing property of the stack to false. That used to be the default but it was changed recently. While it doesn't relate to moving stacks directly, it may influence it.

Edit: if the change in behavior is due to the transition from Carbon APIs to Cocoa, there isn't much LC can do about it. The OS notifies LC about system events, and if Cocoa doesn't tell LC the stack isn't moving, then LC can't tell you.

[FourthWorld]

@Fourthworld:
Appreciate the explanation for the change but I still don’t get the overwhelming reason to change something that worked so simply (sent only when the move ends) and efficiently meaning what could one be possibly be doing that requires a message to be sent every single frame during the move. Do you really want be pinging your logic every single frame, even if it’s not needed?

Have you considered the possibility that other apps may have needs different from the one you're working on? One man's "wasteful" is another man's "thorough".

In my 20 years with this language I've only wanted to use the moveStack message once in an end-user application, and was prevented from doing so because in those days the LC engine for Mac Classic only sent moveStack after the movement was completed: I wanted to have a second window follow the first, but without a means of accurately knowing the complete set of OS window metrics (title bar height, window margins, etc.) it wasn't possible to emulate that from a mouseMove message.

That the old Mac system worked like that is understandable, since windows were both moved and resized by proxy only, delivering to the user only a dashed outline of where the window would eventually wind up; only when the user interaction was completed did the window redraw in the new rectangle. Horsepower on a Mac 512k just wasn't what we have today, and modern Macs offer smooth real-time feedback.

Besides, trying to get the current LC behavior with moveStack when we only get post-move events would be supremely "wasteful", since we'd have to monitor all mouseMove events and users move windows far less frequently than they move the mouse for any other reason.

Ideally there would be two distinct messages, one for live moving and another for completion of a move, and I would favor the introduction of a "stackMoved" message for that purpose. Please post the URL here if you submit that request.

All that background aside...

The key point here is that IIRC nothing has changed for most LC engines; any change that has occurred in specific OS build merely brings them all of them into consistency, valuable for those of us making multi-platform apps. All LC versions I've use for Win95, XP, Win7, Vista, and Win10 deliver the moveStack message as the stack is being moved, as do the LC engines for macOS and Linux.

I can't tell you why the behavior on your Win7 behavior is different, but I just tested again here in LC v8.1.3 on a Win7 laptop and see the same behavior I see elsewhere, in which the moveStack message is sent while the stack is moving. Which version of LC are you using?

For the main question of supporting your app's need to distinguish between stacks-being-moved and stacks-having-been-moved, it may be helpful if you could succinctly describe what your app needs to do when stack moving has completed. Live updates are increasingly common in UIs, and the smooth real-time visual feedback is often appreciated by users. But if what your app is doing results in a stuttering experience there may be other ways we could smooth that out if we knew what they were.

In lieu of knowing what the problem is, this generalized solution below may help.

One thing to keep in mind is that checking whether "the mouse" is up or down within a moveStack handler should not work, since of course the mouse will always be down during a stack move.

So this solution uses the moveStack message to trigger a timer loop to monitor mouse state, with an extra condition that I usually include with all timers to prevent multiple instances of the same timer message from filling up the queue:

Code: Select all

on moveStack
   CheckMoveStackDone
   -- Live-moving stuff goes here, e.g.:
   put the loc of this stack
end moveStack

on CheckMoveStackDone
   if the mouse is "up" then
      -- Post-move stuff goes here, e.g.:
      answer "done!"
      --
   else
      -- Keep the timer running at a reasonable interval,
      -- avoiding duplicate messages in queue:
      if "CheckMoveStackDone" is not in the pendingMessages then
         send "CheckMoveStackDone" to me in 50 millisecs
      end if
   end if
end CheckMoveStackDone

[FourthWorld]

Before you submit any reports, try setting the liveResizing property of the stack to false. That used to be the default but it was changed recently. While it doesn't relate to moving stacks directly, it may influence it.

I just double-checked: makes no difference. That's okay, since IIRC that property only ever affected Mac apps, because at some point (either OS 9 or OS X) macOS changed its behavior. In older versions of macOS windows were never truly resized until after the resize action ended; during the resize the bounds of the window were shown as a dotted outline. In more recent version of macOS windows now take advantage of the horsepower available on modern CPUs to provide a smoother real-time update for window contents. Initially this posed a problem for some Mac apps made with LC (back then, "MetaCard"), because they had come to rely on the older post-resize-only messaging. So the liveResizing was introduced as a way of providing compatibility with the older Mac way of doing window updates.

Since modern OS X/macOS doesn't provide a means of deferring updates to the content region of a window during resize the liveResizing property no longer serves any purpose, and was officially deprecated in LC around v8 or so.

More relevant here is that the old liveResizing property was limited to resizing events, an AFAIK never affected moveStack messages. My test this morning confirms that at least in recent versions it has no effect.

Edit: if the change in behavior is due to the transition from Carbon APIs to Cocoa, there isn't much LC can do about it. The OS notifies LC about system events, and if Cocoa doesn't tell LC the stack isn't moving, then LC can't tell you.

My mention of the change with moveStack possibly happening concurrent with the Cocoa changes was just a hunch, based on discussions with this team and others about the many differences in Cocoa event management vs Carbon. I don't know for sure, but I do know that the behavior of that message on Mac had previously been anomalous (see my note above about Win and Linux).

At this point, all desktop platforms now have the same behavior with regard to the moveStack message, receiving it in real-time as the stack is moved.

Whether any earlier builds of LC for Windows ever did anything different is a mystery to me. I recall enjoying the real-time moveStack messages in MetaCard on Windows XP, possibly as far back as Win95, and wishing I could get the same real-time notification on my Mac so I could keep windows aligned with one another without making the user see a jarring snap effect when they let go of the mouse button.

In all my time on Linux I've seen the same behavior with moveStack, being a real-time message.

So AFAIK macOS was the only exception to how LC sends that message, apparently made consistent with everything else sometime among relatively recent builds.

If a build of LC for Windows ever limited moveStack to be sent only when the moving action ended, given my experience as far back as the '90s I'd feel safe calling that a bug. And since the current LC engines for Windows work like they used to, it seems the bug has been fixed.

I do agree with Ed that it would be desirable to see a new message added so we can have a simple means of getting notification of when a moveStack ends. Each has a role, and while it's easier to get the post-move message from a timer than it is to monitor all mouse movement to track real-time stack movement, simpler still would be to have a message for stackMoved right in the box.

[MaxV]

Max,

If I place a resumeStack handler in the stack script, it only fires when I leave that stack, do something somewhere and return. It does not fire if I grab the titlebar, move the stack around, and then click somewhere in that stack.

Look this video: https://youtu.be/Jifvn_CxinU
It works as it was requested.

[dunbarx]

Max.

Hi. I know that you know what you are doing. So what is it that you are doing?

I am in v.6.7. if that matters. But if not, I cannot get a resumeStack message to fire within the framework I described earlier.

To be clear, I have field on a card and this resumeStack handler in the stack script:

Code: Select all

on resumeStack
   put random(999) into fld 1
end resumeStack

Nothing I do within the bounds of the card, dragging the card window around, clicking in the card window, dragging some more, whatever, will get me a new number in that field. This is as it should be, no? Of course if I click outside LC entirely, or, say, in another IDE stack like the msg box or the script editor, I get a new value, as advertised,

So what exactly does the video show? Again, it is hard for me to see exactly what you are doing.

Craig