propertyChanged?

[Richard Gaskin]

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?

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.

-- 
  Richard Gaskin
  Fourth World Systems


Mark Waddingham wrote:
> On 2017-06-12 19:50, Richard Gaskin via use-livecode wrote:
>> Interesting pull request referenced in v8.0.5rc1's Release Notes:
>> https://github.com/livecode/livecode/pull/5570
>> 
>> When will the propertyChanged message be documented?  I didn't see it
>> in this latest build's Dictionary.
> 
> That probably shouldn't have had a release note as its an internal IDE 
> engine only feature, for use by the IDE.
> 
> Due to this it is subject to change, so like most other things 
> documenting it is not a high priority (people tend to complain about us 
> changing even that kind of stuff regardless how much we say 'it might 
> change in a future version'!). Also the engine functionality is provided 
> by the _internal command namespace - which we do not document as a 
> matter of rule.
> 
> Basically, these features are for the use by the IDE and only the IDE - 
> if other things use them in the IDE then they might very well break the 
> IDE which is not good for interoperation. Also we only test them as far 
> as the IDE uses them - the value in having undocumented things like this 
> which are only really meant to be used by the IDE is that it is far 
> quicker to add the specific functionality needed which works perfectly 
> when used in the correct way without having to consider dozens of 
> potential edge-cases (which is generally true of virtually any public 
> engine feature we add).
> 
> So they will bend and change to suit what we need to implement the IDE. 
> If you want to use them you are free to do so, but generally the 
> documentation is found by reading the source code - all of which is 
> available on github - and you need to retest things in each new version 
> to make sure something hasn't changed (of course, since all of this is 
> open source code, a keen eye on the changes made to either IDE or engine 
> can help here).
> 
> In many cases the internal engine features supporting the IDE are 
> wrapped in LiveCode Script APIs (again subject to change but far less 
> so) - and are easier to grok. Also many of the 'revIDE'/'ide' commands 
> and functions have docs as comments in the 'revidelibrary'. (We should 
> probably look into if we could suck these out into the dictionary for 
> easier access...).
> 
> In this case, you can subscribe to the propertyChanged message by doing:
> 
>    revIDESubscribe "idePropertyChanged", the long id of 
> tObjectIWantToWatch
> 
> This will then send the calling object an 'idePropertyChanged' message 
> when one of tObjectIWantToWatch's properties changes. Unsubscription can 
> be be done by using 'revIDEUnsubscribeAll' or 'revIDEUnsubscribe'.
> 
> Ali wrote this blog-post way back during the final DPs of 8 to help 
> people start poking around in these APIs:
> 
>      
> https://livecode.com/how-to-create-plugins-and-tools-with-the-livecode-8-0-ide/
> 
> Warmest Regards,
> 
> Mark.