On 2015-10-11 08:11, Monte Goulding wrote:
On 11 Oct 2015, at 11:36 am, Peter Haworth <p...@lcsql.com> wrote:

Thanks Monte. Maybe I should file a QCC report or have you already done so?

No I haven’t reported it. I got the impression from the discussion
that it was never intended to support the properties so it wouldn’t
happen. I’m about to propose (on the engine forum) a refactor of the
properties property (which I’ll do if they want me to) that will
essentially make the properties property self maintaining rather than
the current situation which means the list of properties for an object
type needs to be maintained manually. This wasn’t possible before the
refactor and there’s still a few issues like identifying which synonym
of a property is the one to use in the properties array and which
properties should be in the array. The end result will mean the
properties of a widget will be kind + the standard properties for a
control + the standard properties for an object.

I don't think we have ever had the intention not to update the properties property to make it work for widgets - we just haven't done so yet.

Part of the reason for this is that 'the properties' property is quite ill-posed. As it stands it is essentially 'the properties needed to recreate the object' (after the work Monte did on it a couple of years ago); however that concept is difficult as it actually requires hard-coded rules in it to ensure that when you set 'the properties' the properties are set in the correct order.

Widgets complicate matters somewhat. We make no requirement that the state a widget must preserve to recreate itself be directly related to the properties you actually set (this is actually also true of existing engine controls - hence why there is a need for 'hardcoded' rules in the properties property implementation).

Now, I'm not saying this situation is ideal, there are various things we could do in the future to make widgets easier to write if they follow the rule that 'there should be a set of persistent properties which don't overlap and fully faithfully allow recreation of the object' (for widgets that claim to be this, they wouldn't need an OnSave / OnLoad handler as the engine could synthesise one).

However, that doesn't change the fact that currently engine controls don't follow that rule and I'd be loathe to put a restriction on all widgets in that fashion as I cannot forsee the widgets people might wish to write.

Basically there is a bit distinction between:

  1) The data you need to recreate an object (this is what lcVCS needs).

2) The information you need to provide good introspection on created objects (this is what the IDE / inspectors etc. need).

Right now, I'd be incredibly dubious if a single 'properties' property could be made to handle both these uses - the lengthy thread a couple of years ago on this precise topic made that absolutely clear.

Moreover, we have worked quite hard in the IDE to provide a mechanism for (2) - it is what the new property inspector is based on - i.e. APIs for returning information and data about objects in the environment.

Warmest Regards,


Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to