Thanks - threads merged.Ed_Ray wrote:@Fourthworld (yes, if you think setting this issue back to the other post is better then go ahead)
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.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.
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 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.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.
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.
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.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?
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.
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.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.
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.
Desirable, but expensive.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.
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.