propertyChanged?

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps