On 2017-06-12 20:23, Richard Gaskin via use-livecode wrote:
Thanks for that background, Mark. If this message originates in the engine, is there any chance it may one day become available as an official message?
Yes - every chance - although I have to confess it is quite a bit lower than quite a large number of other things!
It would be enormously useful for apps like a web authoring system I built recently, in which I had to keep track of all formatting changes in each location they happened from in order to know when to update my data store. With a single message for that my code would be much simpler, just as the IDE now has that opportunity with its private use of this message.
I'm not sure how long it might be before it becomes a fully supported, end-user feature (there's a great publish/subscribe model lurking there somewhere - at least tuned to an IDE-like applications needs - see further down) but we could evaluate moving the existing mechanism from IDE engine to all engines. The way it is implemented means that it has minimal performance impact if not used I believe (although I'd want to verify that).
Basically, whenever a property changes on an object a single bit is set on the object. Then at controlled intervals (via a 'throttle') the list of currently subscribed objects is iterated through and for each one which has been asked to dispatch a message, the message is sent. The messages always happen at a 'with messages' wait dispatch (either nested, or at the root event loop).
This approach was designed for IDE palettes - where immediate update (whilst script is running tight loops is never needed and would horrendously impact performance if it tried!), but is needed as soon after there is a small amount of 'idle' time so that what you see on screen is what is actually set internally.
So this may or may not work with your application - if you require knowing when things change at each step you'd be better off wrapping the calls which make the formatting changes with a handler which also dispatches a message (basically what the IDE front script does with some engine messages to make sure they are delivered in a uniform fashion).
I should point out that the goal of the IDE abstractions we've put in place since 8 is to eventually enable it to be something which introspects on a running LiveCode 'process' - whether that be in the same process or in a separate process. This changes design criteria a fair bit (and is also why the 8+ IDE is centered around using IDE APIs to wrap engine functionality, rather than trying to use the built-in engine functionality directly - the latter is not 'remoteable' in the way we might want it to be in the future - the former means you just change what the IDE APIs do, and then everything which uses them will work regardless however the underlying IDE decides to do things).
Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
