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

Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10043
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Unexpected cross platform issue

Post by FourthWorld » Sat Apr 01, 2017 4:57 pm

Ed_Ray wrote:@Fourthworld (yes, if you think setting this issue back to the other post is better then go ahead)
Thanks - threads merged.
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 think you'll find that the number of LC language elements that change over time is low, often much lower than the rate of change we see in other languages (consider the challenges during the shift from Python 2 to Python 3, or many dev tools/libraries/headers from Apple). The LC team generally does a far-better-than-average job of maintaining backward compatibility for its developers.

In the case of the moveStack message, as I noted above the only change introduced by the team was for a platform you're not using often, making macOS more consistent with the behavior already in place on Windows and Linux: earlier versions of the LC engine for macOS sent moveStack only when moving was finished, but in more recent versions the message is sent during the drag as it is on other platforms.

The remaining difference we see is one of consistency, not a design change, in which it's sometimes possible to see a mouse "up" state during a message defined by the mouse being down. As I wrote earlier:

"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."

This appears to be more easily seen on Windows than macOS or Linux, but I can't rule out the possibility that if a script introduced a sufficiently long delay and checked the mouse state toward the end of that delay, one might conceivably see a mouse "up" state there too.

This is anticipatable if we consider the sequence of actions in play: the OS notifies LC that the stack is being moved, LC notifies our scripts, and our scripts take control at that point. Depending on what our script is doing, the user may have moved on to other things, such as releasing the mouse, and if enough time elapses between our script receiving the message and our checking the mouse state, that state may indeed have changed in the interim.

All that said, AFAIK that's not so much a change introduced by the LC team as just a difference between how the OS APIs require the team to handle some things differently on different platforms. As I wrote above:

"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."

Of course it's desirable that everything LC offers work as similarly as possible across platforms, and for that reason I continue to suggest that you consider filing a bug report to see if the team may be able to refine that behavior for greater consistency.

So occasional platform differences aside, it's fairly rare you'll find changes in the LC engine that require revising our scripts. On the rare occasion when they do happen you'll usually see a note about the change called out in bold red type in the Release Notes that accompany a new version, such as we saw with the Unicode changes that required the charToNum and numToChar functions to behave slightly differently in order to more fully reflect the scope of modern text encodings LC now supports.

As for the pendingMessages function, that one is derived from information internal to LC, its format not dependent on specific OS features, and AFAIK it hasn't changed in more than 20 years; I can't foresee a circumstance that would require changing it in the future.

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.
I imagine it might, mostly for the substring search and also for the length of the longer strcopy in addition to converting the internal structs to the returned string value.

But in practice it's rare that a developer will overload the event loop with thousands of pending messages.

In any language there's a certain amount of overhead needed to support timers, both in RAM and CPU time. In single-threaded systems like LC, Python, Node.js, and others, if extensive background processing is needed it may be better to consider concurrent multiprocessing rather than thousands of timers firing within a single process. There may be other solutions as well, depending on the specifics of the task at hand. If you run into such a circumstance and find it imposes issues with responsiveness let's explore it to see what alternatives may be available.

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?
I got into the habit of checking the pendingMessages to prevent adding duplicates of a given message because it seems to offer a fairly complete way to do that.

Relying on interval alone raises the possibility that other processes may introduce delays that affect timing. It's rare, as you noted, but even the beefiest multicore CPUs have fewer cores than the number of process they're running, so interleaving execution will be necessary. And that interleaving can allow one process to delay another.

Checking the pendingMessages is more brute-force and less elegant than an elapsed-time evaluation, but like most brute-force solutions it's very complete. And since the value is derived entirely in precompiled machine code within the engine, for all the steps involved internally it's a one-liner in our script and executes pretty quickly.

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.
See above about the differences in OS APIs and the inherent challenge in attempting to provide a single uniform scripting interface for the very different messaging mechanisms OSes provide.

Also as above and earlier, rather than writing here in this user-to-user forum the way to bring this to the attention of the team would be to submit a report on it in the bug DB. Here, other users can suggest alternatives with the engine we have; in the bug DB, discussing it with the engine team can produce a new engine.

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.
Desirable, but expensive.

With controls within the content region of a window, LC has complete control over how it does hit-testing and other aspects needed to support the full suite of mouse messages we enjoy with those.

What happens outside the content region is controlled by the OS, and LC must depend on the APIs provided to deliver scripting interfaces for those messages. And as we've seen in this thread, doing that consistently across OS families with widely-varying messaging architectures is very challenging.

If a strong business case could be presented for the value of that uncommonly complex scope of work, I'm sure the team would consider it. Again, the mechanism for sharing that with the team would be a feature request submitted to the bug DB.

My hunch is that the ROI for delivering the one specific message that would have obviated this thread would be much higher; far smaller scope, far easier to implement, and would satisfy the only real-world use-case identified in this thead thus far.

That said, if there are other use cases common enough to benefit from the work needed to apply LC's full suite of mouse messages to things outside the content region they control, I'm sure they'd consider it. But in all fairness, it may be difficult to find a compelling cost-benefit case given that even the single stackMoved message I proposed is not a request I've seen often over my 20 years with this language, and to be honest I don't recall a project discussed in our community which was dependent on other mouse messages in the drag bar beyond that.

So the key will be estimating the benefit to the current user base + the added value for attracting potential new users, relative to the cost of the effort.

And once arrived at, that ratio would, as a practical business matter, need to be weighed against the ROI ratios for other feature requests in queue. So even if the team finds a positive ROI there, as I think about many of the other items in queue I feel it may not be the higher priority for pragmatic reasons of relative cost/benefit.

Another option would be to find sufficient numbers of other developers with the same need and either make the changes needed or hire a C++ programmer to make them. If this is as widely-needed as would justify engine team work, it may be possible to find sufficient resources within the community to accomplish this without waiting for the engine team to work their way through their queue.

LiveCode's code base is on Github, and submissions for new features are welcome.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

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

Post by jacque » Sat Apr 01, 2017 9:33 pm

These long posts are informative but it is easy to get lost in them, so I'll be concise:

LC can't respond to events that it knows nothing about. Window structures are created by the OS, which does not notify LC of mouse events on every operating system. I'm not positive, but since the moveStack behavior changed after LC switched to modern APIs, I'd guess that repeated messages aren't being sent any more either. The team goes to great lengths not to change long-standing behaviors without good reason.

The LC team doesn't track suggestions or bugs discussed in the forums. To address a problem, it has to be in the bug database: http://quality.livecode.com If you post a report there, they will often explain why the behavior changed or why it may not be possible to adjust it.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Ed_Ray
Posts: 83
Joined: Sun Jun 19, 2016 12:18 am

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

Post by Ed_Ray » Mon Apr 03, 2017 11:49 am

@jacque
You recommended a more efficient way to do this than just a "repeat". I was hoping to see your recommendation in a tangible example but perhaps you forgot to include this in the post.Can you do this when you get chance. Different approaches are most appreciated.

@Fourthworld.
I just got in real late but I also need to get up in two hours so I will definitely go through your post tomorrow. Just scanning through it seems quite informative.

Meanwhile the attached file is something I had generated earlier on Saturday but forgot to post it. It provides a script that I think satisfies all the requirements needed for successful post move execution since I feel that all the prior proposed scripts missed one requirement or another.

I tested the script in Linux, Mac OSX and all different versions of windows. Regardless of unusual user move and release manipulations it works perfectly, no release echos of any kind etc. So far it seems ironclad even though all I used were two simple flags to do everything. Your thought on it are appreciated.

Thanks.
Attachments
Script satisfies all needed move stack requirements.zip
(1.38 KiB) Downloaded 253 times

Ed_Ray
Posts: 83
Joined: Sun Jun 19, 2016 12:18 am

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

Post by Ed_Ray » Tue Apr 04, 2017 10:36 am

@Fourthworld
[1]
Regarding your:
“As for the pendingMessages function, that one is derived from information internal to LC, its format not dependent on specific OS features, and AFAIK it hasn't changed in more than 20 years; I can't foresee a circumstance that would require changing it in the future”

[1.1]
So it seems you feel pretty confident that the use of the “pendingMessage()” function probably won’t burn me again. I will definitely consider that when I decide which scripting logic is the one I will end up using to complete my on-going RegEx app.

[1.2]
Just to have a complete view on different ways to handle this, what did you think of my last posted script describing a “simple flag only” alternative to prior proposed scripts found in the recently submitted “Script satisfies all needed move stack requirements.zip” attachment?

Don’t think one would ever find perfection in a script but at least I feel this one seems to satisfy the most needed requirements as specified in the file with a minimal of fuss and it seems ironclad on the elimination of back to back release "echoes".

[2]
With regards to your description regarding the difficulty implementing the title bar mouseup/mousedown new message, do you have an alternative recommendation that would minimize the usage of the same moveStack message name or do you feel we should just come up with a completely new message name?

[3]Bug DB reporting:
I will go ahead and file that win 10 bug where the script works perfectly while still containing errors that should impede it from working correctly.


As always thanks for your information and feedback

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10043
Joined: Sat Apr 08, 2006 7:05 am
Contact:

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

Post by FourthWorld » Tue Apr 04, 2017 2:19 pm

Ed_Ray wrote:So it seems you feel pretty confident that the use of the “pendingMessage()” function probably won’t burn me again.
When did it burn you before?
Just to have a complete view on different ways to handle this, what did you think of my last posted script describing a “simple flag only” alternative to prior proposed scripts found in the recently submitted “Script satisfies all needed move stack requirements.zip” attachment?
If it works, it works.
With regards to your description regarding the difficulty implementing the title bar mouseup/mousedown new message, do you have an alternative recommendation that would minimize the usage of the same moveStack message name or do you feel we should just come up with a completely new message name?
My recommendation for easily distinguishing between moveStack and stackMoved events was to add a new message for the latter. I had no recommendation for any other mouse messages, merely noted why they would be expensive to implement and difficult to make a cost justification.
Bug DB reporting:
I will go ahead and file that win 10 bug where the script works perfectly while still containing errors that should impede it from working correctly.
Please post the URL to the report here so those interested can follow the progress.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

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

Post by jacque » Wed Apr 05, 2017 6:16 am

@jacque
You recommended a more efficient way to do this than just a "repeat". I was hoping to see your recommendation in a tangible example but perhaps you forgot to include this in the post.Can you do this when you get chance.
I rarely have time to download and examine scripts from the forums, I was commenting on what I've read here (which may not have been wise.) I was referring to general best practices, which I assumed from Richard's posts is what he was using. The "send" command is usually more reliable and is preferable to a repeat loop for lots of reasons. If that isn't what his script does then I was off base.

While this doesn't directly address your problem, the general argument against polling the mouse is here:
http://www.hyperactivesw.com/polling.html

It discusses using built-in mousemove messages, but that could be replaced with a "send in time" structure that would behave similarly.

I probably shouldn't stick my nose in without having looked at the scripts first, but I'm always either in a hurry or away from the computer when I read the forums.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Ed_Ray
Posts: 83
Joined: Sun Jun 19, 2016 12:18 am

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

Post by Ed_Ray » Tue Apr 11, 2017 10:13 am

@Fourthworld

Regarding:[1]
“So it seems you feel pretty confident that the use of the “pendingMessage()” function probably won’t burn me again.

When did it burn you before?

I meant the function “pendingMessage()” potentially changing burning me similar to the way movestack message change burned me.

Regarding: [2]
“simple flag only” alternative to prior proposed scripts found in the recently submitted “Script satisfies all needed move stack requirements.zip” attachment?

If it works, it works.”

I was trying to get a bit more feedback than that “it just works”.
Meaning:
[a] if a flag (FirstTime) only implementation that does not even invoke the “pendingMessage()” or used any elapsed time calculations added some level of efficiency, and your thoughts on that.

A Flag only implementation precludes any “future”change to the “pendingMessage()” function since the script completely omits its invocation. Just wanted to verify that in general this would be a good thing as long as you felt its omission does not cause any unforeseen issue.

[c] If you were satisfied that this covered all the needed requirements as specified in the file since prior scripts were close but were lacking in one or two of the specified requirements.

[d] Your thoughts on the use of the flag “ConsecutiveReleases” which up till now seems to have eliminated ALL traces of the multiple release echoes problems or if you ran into any special case where the echo would still emerge.

Regarding [3]
“Please post the URL to the report here so those interested can follow the progress.

Yes. I will post it this week.

@Jacque
Thanks for the info. Yes I think I had already read that link before and a few similar ones that may have not completely agreed with each other but were fairly close in procedure.

Thanks

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10043
Joined: Sat Apr 08, 2006 7:05 am
Contact:

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

Post by FourthWorld » Tue Apr 11, 2017 4:03 pm

Ed_Ray wrote:I meant the function “pendingMessage()” potentially changing burning me similar to the way movestack message change burned me.
AFAIK the moveStack message hasn't changed in more than a decade, and the change was driven by changes to macOS and affected the macOS engine only.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

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

Post by jacque » Tue Apr 11, 2017 4:59 pm

I meant the function “pendingMessage()” potentially changing burning me similar to the way movestack message change burned me
I'll add my assurances, pendingMessages isn't going to change. Window behavior is dependent on the information the OS sends to LC and if Apple changes that there's nothing LC can do. PendingMessages is an internal LC process used by not only our stacks but extensively by the IDE itself. It's the preferred and recommended way to handle repeating processes and it isn't going anywhere.

LC goes to great lengths to maintain backward compatibility and it's very rare that behaviors change without a good reason. In fact, recently an anomaly was discovered in the numberformat function and it was decided not to change it because too many people relied on the current behavior.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Ed_Ray
Posts: 83
Joined: Sun Jun 19, 2016 12:18 am

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

Post by Ed_Ray » Tue Apr 18, 2017 9:34 am

Thanks for the response on item [1] assurance of its meaning not changing.

This will help me decide which proposed script to use although having some answers on item [2]a through [2]d of prior post would have given me more needed information to decide which of the prior discussed scripts to use and how to modify them to satisfy all the necessary requirements repeated below:


**** Requirements that were not completely satisfied by prior proposed scripts and/or proposed alternatives: *****

[1] "Send msg to me" is initiated with one simple "FirstTime" flag. No "pendingMessage()" function or elasped time calculations were necessary. Just one simple flag was used. [Proposed ALTERNATIVE]

[2] Once initiated by the "FirstTime" flag, the handlers run independent of each other with no further dependencies until a release is detected.
[Done a bit different then in prior scripts]

[3] Ensure a release process is the LAST process you see when the mouse is released when messages are sent DURING stack movement.
[Neccesary requirement not met by prior scripts]

[4] Message sent at end of movement for some remaining win 7 cases is handled and ensures NO "in movement" process is ever detected BEFORE or AFTER the release.
[Before and after part requirement part not met by previous scripts]

[5] Automatic re-enabling of the "send to me" sequence initiated at step "1" until a release is detected.
[Done a little differently]

[5] Previous problematic win 10 multiple back to back release "echoes" initiated by a user's erratic stack end of move sequences observed in all prior script usage now is impervious to such manipulations by the use of a single "ConsecutiveReleases" flag.
[requirement not met by previous scripts]

Thanks.

Post Reply