LiveCode Forums.

@Jacque:
With respect to the LiveResizing property, it did not seem to make a difference but I appreciate your suggestion.

@FourthWorld
“[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"]”

My Resp:
Yes. I did consider this since I qualified my statements by stating:
[1]Do you really want be pinging your logic every single frame, even if it’s not needed?
[2]This is woefully inefficient if the user just wants to run their logic at the end of the move.
[3] I also mentioned that there already existed other functions that could be used to monitor real time points. With the change in message meaning, it just makes it simpler to do so. Remember before this change folks were still able to execute the real time point functionality as you specified.


“[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.]”

My Resp:
Yes agreed but if you knew when the move started or separately told when to monitor interim move steps without messing with the original intent of the movestack as I had previously suggested, your monitoring would have been greatly minimized with no repercussions on any logic dependent on the old meaning of the message. Remember there is plenty of code is out there still using ver 6-7 with the old meaning which is about the timeframe the message was changed.

That is what I meant when I had stated before that:
Had this been well or completely thought out before this decision was made at the point the change was proposed for purposes of consistency or whatever other reason?

I would tend to say no because:

Even if one did not know what exact functionality could happen after a move, the fact that the changed meaning essentially renders any functionality depending on the old meaning completely useless because think about the can of worms this opens. The code now would never get the message when it needs it and would always get it when it does not need it…wow! Talk about a DRASTIC change ripple effect.

Therefore this should have immediately raised red flags and set sirens going at the time of this decision REGARDLESS of not knowing exactly what functionality could be useful after a move.

In every technical change meeting involving the three distinct software groups I lead in various consulting endeavors, before anybody propose a change he or she needs to meet a minimum set of criteria before their change proposal is EVEN remotely considered. These are:

[1] Written and approved documentation needs to verify that the proposed change has full or “near” full backward compatibility unless the contract allows for written and documented deviations from this.

[2] Proposed change considered ONLY if there are no cheaper and timelier alternatives. This cannot be based on opinion or the direction of the wind that day but on written and approved facts with experienced subject matter experts INTIMATELY involved in those alternative plan proposals.

[3]More than one attempts (at least two needs to be documented) has been made to key personnel responsible for prior supported versions to capture typical examples of prior “in the field” usage so as to give the change proposal team the confidence and knowledge necessary to make such a change proposal or to retract from such proposals in a timely manner.

[4]Compare the proposed changes to at least one historical “prior change metrics” to see if it falls within the acceptable percentage of prior similarly executed changes to ensure the bank was not broken when the change was introduced.

With policies like this in place instead of here-say, very few things like this would fall through the cracks and continue to bite one in the future.


“[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?]”

My Resp:
Perhaps laptops are not the most desirable test beds particularly when dealing with graphic related properties because they don’t have a real full-fledged graphics card. They mostly only have an integrated chip with nowhere near the capacity of a full-fledged graphics card. I have already seen other bugs that don’t surface on laptops but do so on a desktop which is the reason why I mostly test on complete desktops.

I have tested this on FOUR full-fledged DISTINCT desktops. Distinct in terms of different CPUs, different motherboards, different graphic cards, different monitors, different hard drives and different variations of Win 7 and every possible combination in between (yes, I am that thorough).

It does not matter what version of LC was used (tested with LC 8.0 – 9dp4), as long as it was used with Win 7 (orig, SP1, “SP2 equivalence”- meaning additional updates added on to SP1), the functionality of the moveStack message is that it is ONLY gets sent to the stack AFTER the movement has stopped and the user releases the mouse button from the title bar.

Any other time except for the movement end, it does not receive the message. For the checks, I used the LC file/script I had created and sent you (“checkMouseValueOnMove.livecode”) in my last post which clearly shows when you are receiving messages all the time versus only at the end. It can’t be missed or misunderstood because it is so visually demonstrated on the field as an on-going narrative remember?


“[it may be helpful if you could succinctly describe what your app needs to do when stack moving has completed.]”

My Resp:
What my app needs to do is the most requested thing after the ability to bring colored highlighted results outside of LC.

When using multiple monitors that may have different screen resolutions, every time the user moves the stack and places it on a different monitor or changes the screen resolution on the fly within the same monitor, the resolution change cause the ideal physical display size to change making the window and related controls look smaller, less appealing and out of scale or it can look bigger, wider less appealing and out of scale the other way.

The users wanted to have the ideal base resolution PHYSICAL size retained at all times regardless of any resolution change that occurred when the user moved the stack to a different monitor with a different resolution or within the same monitor if the screen resolution was changed on the fly. When changed on the fly, the user did not want to go to another screen then come back to finally see the res change - not when the change was instant.

So any non-trivial scaling like this needs to know when the move has completed to another monitor and since any instant screen resolution changes the position of the stacks left and top edges (which in essence is what defines a move), the app needs to know when this “instant real time” move has completed so the non-trivial scaling can commence.

There isn’t anything special or side cased about this as some would want others to believe since any non-trivial scaling on any “graphic burdened” system is not going to attempt to continuously scale unnecessarily (ie. Small movements with the same monitor or ending on a monitor with the same resolution – why scale again?). So this is actually quite common.

So based on this it only makes sense to check for an opportunity to scale a stack and its controls ONLY at the right time – right after a move has completed.

“[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.]”
My Resp:

Agreed but keep in mind that occasionally a mouse release is detected when the message should only be sent due to the mouse being pressed against the title bar while in movement. This actually happens 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, all done in a swift single contiguous move.

Like you said 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.

Based on the fact that this actually DOES happen and is reproducible I would say this has to be registered as a bug because LC should do whatever it takes to preclude this from happening and it isn’t.

LC can’t make an excuse and say it can’t preclude this from happening due to user interaction because it should be able to do exactly what my code manually did to preclude this from happening. If I could manually fix this in my code then LC should then also be able to do the same thing or similar internally and automatically.




[“in lieu of knowing what the problem is, this generalized solution below may help]”
My Resp:

This is in essence what the “checkMouseValueOnMove.livecode” script I sent you in my last post does except it actually has code included to actually execute the necessary fine details stated in your code comments and also makes it work regardless if the message was sent as it moved or if it were sent only at the end. This last thing ensures the code would work even if in is used in a win 7 system that still uses the old meaning of the message.


“[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.]”

My Resp:

Agreed. The best solution similar to one of the ones I had previously suggested is to simply have two distinct messages
[1] endMoveStack – Behaving like the original one which only sends the message when the move completes but coinciding with the release of the mouse from the title bar
[2] onGoingMoveStack – Message sent anytime the stack is being moved coinciding with the mouse being pressed against the title bar.

The only lingering problem is the original users of the original intent (msg sent when move ends) are using the same message name as the newer users that are using the same message name for the newer intent (msg sent during the move) so which of the two users have to change their message name and who gets to keep the original message name?

See how a decision not completely thought out continues to affect functionality years later? It’s like a negative domino effect that seems to never want to end.

Thanks Fourthworld, even when we don't agree on everything, your comments and thoughts are always very much appreciated.

dunbarx wrote: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

Did you put your code in the stack? Every time I stop moving the window, the message is activated. I used your code for this: https://youtu.be/ScGDvHiEpKg

Hi Craig,

dunbarx wrote:Did you put your code in the stack? Every time I stop moving the window, the message is activated. I used your code for this: https://youtu.be/ScGDvHiEpKg

tried with the code in the stack script, does not work on my Mac!
Tried with the code in the card script, does not work on my Mac!

I am using LC 9 dp6 on a Mac and looking at the cursor in your YT video you are obviously using a very ancient version of Livecode,
but many, many things have changed since these days.


Best

Klaus

@dunbarx

The video is showing exactly what we would want (upon release of mouse after a move on the SAME moved stack you make a function happen) but I agree with you that is not what the code is doing. You actually have to click (press and release) somewhere ELSE to make the functionality happen and this is not what we need..

Perhaps I was not clear that it needs to be released from the SAME stack you had been moving like its being shown on the video. Unfortunately the code is not doing what the video seems to be showing.

By the way did you see the sample stack I sent that does this correctly? If you missed it I send it here again on this post.
One has all the descriptive comments and the other is the clean copy with just the code. You can run the clean one and observe what happens in the field.

Note: For now I recommend you ONLY run it in any ver of windows because Mac OS X and Linux seems to have some cross platform issues with this script which I addressed in the following post to Fourthworld.

Note: In case win 7 still uses the old meaning (msg sent at the END of the move) and win 8 and 10 use the new meaning (msg sent as the mouse is being moved), the script covers both msg meanings in case a takes a long time to make a win 7 fix making win 7 work the same way win 8 and 10 does with the moveStack message).

Let me know if you feel the solution presented does what was intended (be able to execute some functionality at the end of a move regardless of what meaning is being used for the moveStack message).

Thanks.

@Fourthworld
I have tested Script "checkMouseValueOnMove.livecode" which was included in the zip of a prior post (included again in this post in case you don't want to look for it again), in win 7 and win 10 and it seems to work perfectly. The mouse release is picked up correctly and I can key off that to execute some functionality AFTER the move completes.

Just a reminder, line 10 is there in case win 7 is still using the old meaning of the moveStack message (msg sent at the end of a move) and in case a release attempts to creep in when it should not as when executing the current meaning of the moveStack message (msg sent during the move).

The UNEXPECTED cross platform issue:

Once it worked perfectly in windows I never expected any cross platform issues since the script is fairly short and straight forward but UNFORTUNATELY it does not work correctly when tested in Mac OS X El Capitan ver 10.11 pretty recent version of Mac and it does not work correctly in Linux Mint ver 18.1 (latest version).

The issue seems to be that in MAC and Linux it is not picking up the mouse release even though the code is exactly the same code that is working perfectly in windows. The ver 9 dictionary talks about mouse button differences across the platforms but to my understanding this should not be affecting mouse button ONE which they all should be using the same way unless you feel I overlooked something from the dictionary description.

I put a hard break point on line 22 so you can see how it breaks correctly all the time in windows when the mouse is released from the title bar but does not seem to break here at all when using Linux and Mac systems.

Any suggestions why it is not working across all the platforms the same way?

I tested with LC 8.1 because ver 9 seems to have problems with breakpoints inside moveStack and resize stack handlers. It seems like it goes right by them as if they don't even exist even the hard breakpoints. I am getting ready to put that potential bug issue into its own separate post. I just wanted to mention here so you could tell why I did not use ver 9 in the testing and to give you some heads up on the matter.

Thanks.

Appreciate your comments on this.

Thanks

@Fourthworld (had been involved with this issue but anybody with an answer would also be most appreciated)

I have tested Script "checkMouseValueOnMove.livecode" which was included in the zip of a prior post (included again in this post in case you don't want to look for it again), in win 7 and win 10 and it seems to work perfectly. The mouse release is picked up correctly and I can key off that to execute some functionality AFTER the move completes.

Just a reminder, line 10 is there in case win 7 is still using the old meaning of the moveStack message (msg sent at the end of a move) and in case a release attempts to creep in when it should not as when executing the current meaning of the moveStack message (msg sent during the move).

The UNEXPECTED cross platform issue:

Once it worked perfectly in windows I never expected any cross platform issues since the script is fairly short and straight forward but UNFORTUNATELY it does not work correctly when tested in Mac OS X El Capitan ver 10.11 pretty recent version of Mac and it does not work correctly in Linux Mint ver 18.1 (latest version).

The issue seems to be that in MAC and Linux it is not picking up the mouse release even though the code is exactly the same code that is working perfectly in windows. The ver 9 dictionary talks about mouse button differences across the platforms but to my understanding this should not be affecting mouse button ONE which they all should be using the same way unless you feel I overlooked something from the dictionary description.

I put a hard break point on line 22 so you can see how it breaks correctly all the time in windows when the mouse is released from the title bar but does not seem to break here at all when using Linux and Mac systems.

Any suggestions why it is not working across all the platforms the same way?

I tested with LC 8.1 because ver 9 seems to have problems with breakpoints inside moveStack and resize stack handlers. It seems like it goes right by them as if they don't even exist even the hard breakpoints. I am getting ready to put that potential bug issue into its own separate post. I just wanted to mention here so you could tell why I did not use ver 9 in the testing and to give you some heads up on the matter.

Thanks.

Appreciate your comments on this.

Thanks

The code I delivered for that in the other thread was tested on all three platforms. IIRC the difference was when the mouseUp is being checked.

@Fourthworld;

Not clear on your answer. Are you trying to say that at the breakpoint I had specified below where the mouse is checked for a release which works fine in ALL versions of windows with all LC versions, you are recommending to change the breakpoint to somewhere else?

If so, can you give me an example.

I really would have thought that cross platform compatibility meant I did not have to change the code that is working perfectly in one platform in order to make it work on the other platforms?

Ed had written:
I put a hard break point on line 22 so you can see how it breaks correctly all the time in windows when the mouse is released from the title bar but does not seem to break here at all when using Linux and Mac systems.


Thanks

Your code continues to check the mouse state within the moveStack message, something I addressed some time ago in the original thread you'd created for this issue:

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.

http://forums.livecode.com/viewtopic.ph ... 02#p152519

That post includes a fully-working example that appears to deliver what you need as far as I've been able to understand it.

If you've managed to turn up specific cases where the mouse state can be determined to be up within a message defined by the mouse being down, perhaps the reason you don't see this happening in other versions is because that would be bug that was fixed.

It may be possible to explore other ways to do things which may work on some OS versions and not others, but since you have a working solution available in my post I'm not clear why this new thread was created on the same topic, or why the exploration of edge cases in older OS versions is of continuing interest.

You stated:
“Your code continues to check the mouse state within the moveStack message, something I addressed some time ago”.

Yes, you must have missed it but back in that same post there was and still a valid reason for that mouse state check there which I previously specified as:

“[Agreed but keep in mind that occasionally a mouse release is detected when the message should only be sent due to the mouse being pressed against the title bar while in movement. This actually happens 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, all done in a swift single contiguous move.

Like you said 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.

Based on the fact that this actually DOES happen and is reproducible I would say this has to be registered as a bug because LC should do whatever it takes to preclude this from happening and it isn’t]”.


So that is the reason that check is there it precludes this release from getting through since LC apparently is not doing its job to keep that release out. The check precludes getting back to back releases. If this was not actually happening I would not be checking for that there. So that is why the check is being done there.

That check is also there to take care of the cases that are still out where the message is sent at the end of the move (some win 7 cases still work that way). I have a theory explaining why which I will be putting out in a different post shortly to see what you think of the theory. Regardless of this check, the most important thing are the three paragraphs specified below since this check has no affect on the mouse release being missed at the breakpoint specified below since it is OUTSIDE of the moveStack handler.

****So the code AS WRITTEN, is working PERFECTLY for all versions of windows and all versions of LC covering the cases where the message is sent DURING the move AND when it is being sent at the END of the move. The code covers BOTH cases successfully throughout ALL versions of windows.****

**** So I think what you keep missing and where I really need your help is at the specified breakpoint in the code line 22 which is happening correctly with the mouse being detected as a release when the mouse is released there in ALL versions of window and using ANY ver of LC. The assistance needed is to find out why the mouse release at that point is not being picked up in linux mint 18 and in Mac osx 10.11 (El Capitan) when I am using EXACTLY the same code that is working perfectly in ALL versions of windows.****

**** So I would really appreciate it if you can you do me a big favor and please run that exact code in windows then run it in linux and Mac osx and tell me what you observe? That way I would know if we are both seeing the same thing and why. I would really appreciate that test being done. I think it would really help a lot. Else I am completely stuck with this cross platform incompatibility issue and will then only be able to put out the win ver of my app until somebody can determine why this incompatibility is happening****


Thanks
As always appreciate your information and responses.

Why don't you just use the alternative already provided?

I already did. Both yield the same working and non working results that I had specified in prior posts.

The alternative you provided is basically the same as mine with the exception that yours does not handle the case where the message could be sent at the end of the move. Mine handles getting the message during the move and at the end of the move both in the same program.

Yours does not take into consideration that currently LC allows mouse releases to get through toward the end of the move depending how the user stops the move and abruptly releases the button, when the message had been sent during the move. My program takes that into account. The part with the timer outside of the movestack handler which is the critical part that needs investigating, we both have this set up exactly the same way and that is the only part that really matters..

The part with the issue as already stated is not those listed above. The issue has to do with the end of the timer which occurs outside of the movestack handler which we both identically have set up the same way and is supposed to catch mouse releases when the timer expires and the stack is no longer moving.

In all versions of window with any ver of LC it works perfectly. The mouse release is detected outside of the movestack handler when the stack stops moving as it should.

In linux and Mac the mouse release at the end of the move and outside of the movestack handler is never picked up which makes absolutely no sense since its EXACTLY the same logic working perfectly in all the versions of windows.

There is nothing in the mouse released logic outside of the movestack handler that should cause any cross platform compatibility issue. its just a check of the state of the mouse at the end of the move nothing more and nothing less!

Can you please run the program in linux or mac and compare to the windows results which has the mouse release being detected at the end of the move. That way we may be able to see something that can help solve this situation.

I have already run all the tests I can possibly run from my side. I just need someone to run the same from your side so we can compare notes. Then at that point we could figure out a resolution.

Thanks

Ed_Ray wrote:The alternative you provided is basically the same as mine with the exception that yours does not handle the case where the message could be sent at the end of the move. Mine handles getting the message during the move and at the end of the move both in the same program.

I havn't been able to see any adverse effects from the sample code I provided. Testing here on macOS, Linux, and two versions of Windowds (7 and 10) it delivers the during-drag feedback as expected, and the notification of end-of-drag once when the dragging is done.

Have you found cases where the end-of-drag notification is absent, or presented more than once?

Yours does not take into consideration that currently LC allows mouse releases to get through toward the end of the move depending how the user stops the move and abruptly releases the button, when the message had been sent during the move. My program takes that into account. The part with the timer outside of the movestack handler which is the critical part that needs investigating, we both have this set up exactly the same way and that is the only part that really matters.

Yes, that part is critical.

Drag actions are defined by the mouse being down. When the mouse is up, no dragging is taking place.

While it may be possible under some circumstances to determine that the mouse is up during an action triggered by the mouse being down, that would be an anomaly caused by delays either in the script, the OS, or both.

If we assume good performance, the logic of an action dependent on the mouse being down cannot rely on the mouse also being up.

For this reason, my code moved the mouse check into its own loop, driven by a timer with no dependency on the moveStack message. As such, it can monitor the mouse state without relying on the unpredictable happenstance of delays that may or may not occur during a drag operation.

Indeed, those unpredictable delays seem to be the root of the inconsistency you've observed in attempting to check if the mouse is up within an action defined by the mouse being down.

The issue has to do with the end of the timer which occurs outside of the movestack handler which we both identically have set up the same way and is supposed to catch mouse releases when the timer expires and the stack is no longer moving.

But they are not identical: Mine checks the mouse within a timer completely independent of the moveStack message.

In all versions of window with any ver of LC it works perfectly. The mouse release is detected outside of the movestack handler when the stack stops moving as it should.

In linux and Mac the mouse release at the end of the move and outside of the movestack handler is never picked up which makes absolutely no sense since its EXACTLY the same logic working perfectly in all the versions of windows.

Indeed, one of the challenges of delivering a multi-platform tool like LiveCode is providing a consistent scripting interface to OS routines that are often very different under the hood, as seems to be the case here. It would be ideal if underlying OS messaging architectures were more consistent, but given the broad variance the LC team has to contend with they do a reasonably good job.

An ideal solution would the addition of a new message, perhaps something like "stackMoved", to be sent after the mouse is released and the dragging has ended. If we had such a message all these discussions of working around the absence of that message would not be needed. I still encourage you to submit that request:
http://quality.livecode.com/

In the meantime, unless there is a behavioral issue with the example I delivered which differs from the reliably consistent results I've seen on all platforms I've tested on, it would seem you have a solution for your immediate need.

If there is a behavioral issue with the sample code I provided, that may be a bug which could be reported at the URL above.


PS: Would you mind if I merged this thread with its original here?:
http://forums.livecode.com/viewtopic.php?f=7&t=29002

Putting both of these discussions of the same issue together in a single thread may help others looking for such things.

Checking the state of the mouse inside a repeat loop isn't always reliable. The engine only checks at the exact moment the line of script is executed, and any timing difference between the engine check and the user action can give inconsistent results. That's why moving the check outside of the repeat loop is more reliable.

Using the timer method rather than a repeat loop is almost always preferable in most cases, regardless of what the script does.

@Jacque
Could you provide a tangible example of what you are recommending?
It would be most appreciated since if you look into my post to fourthworld below, his solution barring some differences we are still working out, seems pretty reliable so far since its not really in a "formal repeat loop".

@Fourthworld (yes, if you think setting this issue back to the other post is better then go ahead)

Although I agree that in general, you script works across the platforms, Please see the attached file for some issue the script needs to rectify for a complete working solution. Your script was used for reference within the file.

In reference to the on-going conversation, I may have unintentionally misspoken when referring to your script having been used in all possible cases after looking carefully at my testing scenarios notes after I sent you my last post.

I initially used it along with mine to test it out in win 7/10 where they both worked perfectly exactly the same way. Later when I found that my script it did not work correctly in Linux or Mac OSX It seems I made an assumption that your script would have the same issue and may have never used it in those circumstances. This is based on finding that a check mark I usually assign to the script source used was not recorded against your script in those situations.

I think this happened because if different SIMPLE scripts work on a platform, one would expect both to work for other platforms or both not to work for other platforms particularly when the script is simple and has a few lines of code taking away any potential platform complexity nuances. After seeing both work EXACTLY the same way and to perfection in all manner of releases in a particular platform I find it highly unusual that the scripts would behave completely different on different platforms.

The bottom line here is when comparing scripts after this finding, I located an error of omission in my script which yours handled correctly pertaining to what needs to happen if the user stops the stack from moving but leaves the mouse held down against the title bar for a prolonged time period. I did not provide for this.

With this omission the release would not be seen after a mouse release is executed.
With this change being considered my script is more closely aligned with yours and the only difference I am considering is whether to use a “generic elapsed time” calculation in the CheckMoveStackDone instead of using the LC pendingMessages() function as shown below.

Sample below:

on CheckMoveStackDone
if the mouse is "up" then
put "Mouse was released" & CR after field "CheckMove"
else
put milliseconds() into X1
if X2=empty or X1-X2 >= 500 then
send "CheckMoveStackDone" to me in 500 millisecs
put milliseconds() into X2
end if
end if
end CheckMoveStackDone

I tested it across the three platforms and it works correctly just like yours does.

It is a more generic solution because it does not depend on a LC function that can change in meaning tomorrow and burn me once again like the change in the moveStack message did.
I addition in cases where there would be many pending messages (in some real time applications there could be literally thousands in a pending list to have to parse and search through), the elapsed calculation would be typically more efficient.

The only “issue” I saw particularly in win 10 was that there seemed to be occasional sporadic multiple releases on a long move and release execution than was found with the elapsed time method but did not seem to happen using the pendingMessages() function.

Do you know why this small difference exits in win 10 (it does not seem to surface in win 7, Linux or OSX)? Would you not agree that the two ways should work identically without any difference at all?

The real “big” area of concern that persists is now that it is acknowledged that I had in fact an error of omission in my script and yours did not, why did it work correctly across all versions of windows?

I don’t think it would be wise to ignore this issue since something like this should never happen in LC where a script that should have not worked actually did to perfection. This could be something that can come back to haunt LC in other unforeseen development areas.

This is the type of software error my team and I would never ignore in our projects. I strongly urge LC to look into this issue. It is to their benefit.

Lastly regarding your agreement to just create a new message to avoid all this turmoil, would it not be a good idea to just create new mouse up/mouse down messages that work off the title bar just like the ones that work for a button or the body of the card. That way the message can generically be used for other thing besides a move situation and does not cause any issue with who gets to keep and use the older movestack messages names etc.

Your thought on this would be most appreciated.

Thanks
As always appreciate your information and responses