the properties

[monte]

Removing read-only properties? Not in favour of that - unless there's some other way to get them.

It's documented not to return read-only properties but it does return some. So I made it conform to the docs. You can get read-only props directly (not via the properties). There's lots of read only properties that aren't in there and only a couple that are.

[phaworth]

Removing read-only properties? Not in favour of that - unless there's some other way to get them.

It's documented not to return read-only properties but it does return some. So I made it conform to the docs. You can get read-only props directly (not via the properties). There's lots of read only properties that aren't in there and only a couple that are.

OK hadn't realized that. I guess I must have seen some of the read only ones that were included

Pete

[mwieder]

I'm not sure I'm in favor of it either, but either that or the docs have to change.

Maybe "get all the properties" would return the read-only ones as well? Or "get the full properties"?

[jacque]

While you're messing around with properties, I noticed last night that "the properties of fld 1" does not include its graphic effects. Would be nice if you could include those. It's probably true for other objects also but I was only working with fields when I saw it.

[mwieder]

Yep - graphic effects are on the way.

[monte]

yep, graphic effects and gradients are already done... just waiting on runrevmark to get back from holidays to take a look at the pull request. Hopefully will be in 6.1 although given it's a bug fix it could be in 6.0.2 I guess if there is one????

[monte]

I don't think it's trivial to add adjectives to properties other than effective (which I've already implemented). I guess I could look at how the effective working screenrects is implemented... I'm not really sure what the point of returning the read only ones would be. It would just slow down both getting and setting the properties because of all the extra properties it would need to get.

I can only really think of a use for returning read only properties in an IDE context... just for info... but even then why would you need them all in an array? The whole intent of the properties seems to me to apply read-write properties from one control to another or store them for later application....

If we can't think of anything outside the IDE context perhaps they can be implemented in an IDE only property which makes use of the properties for the read/write ones but also adds read only ones. runrevmark doesn't seem to like bloating standalone engines with code that's only useful in the IDE which is fair enough. So my suggestion for anyone that wants read only props in the properties would be to work on that.

[phaworth]

I can only really think of a use for returning read only properties in an IDE context... just for info... but even then why would you need them all in an array? The whole intent of the properties seems to me to apply read-write properties from one control to another or store them for later application....

I agree they only make sense in an IDE context, but assigning properties from one control to another isn't the only use - folks who write property inspector alternatives may want to display them. Not having them in the properties array is OK since that's the way it's supposed to be according to the docs but it would be nice to have a way to return just the read-only properties, not necessarily with an adjective to properties, maybe a separate property like readOnlyProperties. Maybe that's a separate change request though.

[monte]

Right if it's IDE only it should be separate I think and just rely on the properties to get the read/write ones. I'm putting this squarely in the 'not useful for me so I'm not doing it box'

[LCMark]

Okay seems like there's been quite a lot of traffic on this since I was away

I think one of the things to get very clear is what 'the properties' should do and here is my suggestion. Ignoring script (which also implies ignoring custom properties), doing:

Code: Select all

set the properties of tObject to the properties of tObject

Should 'never' fail and result in the object being exactly the same as it was before.

This, I guess, implies several things:

• 1) Only the minimal set of properties needed to define the object should present when fetched.

• 2) The script and custom properties of an object should not be present when fetched.

• 3) Any overlapping properties that must be present (because it isn't possible to fully define the object without both) should be specially handled when set.

• 4) The id property probably shouldn't be present when fetched.

• 5) The field object should probably only have the 'styledText' property returned.

• 6) Only properties that can be set (and are persistent?) should be present when fetched.

( I'd also strongly suggest that things like unicodeLabel should only be present if the control actually requires unicode encoding. )

Really, for IDE-type plugins a more complete 'meta-description' of the object is required that would be beyond the scope of such a 'simple' property as 'the properties'. Similarly, for VCS, what you really want is to be able to import/export a control as an array of 'things that make it what it is'. The former might be better provided as a standardized form of metadata that could be fetched in some other way; the latter is most certainly better provided by array import/export of controls (which is something that's being looked into here).

Of course, in the meantime, I'm not going to put up too much resistance to improvements to 'the properties' as it is somewhat broken for any purpose at the moment. However, if we are going to change its functionality it does need a clear and bounded set of things it does and doesn't do that can be adhered to in the future as we can't really justify continually changing it...

[mwieder]

1. While the rect of a card appears in "the properties" of the card, you can't set it, as it's inherited from the stack rect.
2. I'm not sure the id shouldn't be fetched as part of the properties, since it's necessary in a version control system. Disambiguating id conflicts is a separate issue, and I suppose it could be argued that getting the id of an object is a separate task, but I don't think this is as straightforward a rule as the others.

Possibly an analog of "the files" vs "the detailed files" would be nice for "the properties", although "the detailed properties" doesn't imply the right thing. Maybe "the complete properties" or "the full properties"?

[phaworth]

Possibly an analog of "the files" vs "the detailed files" would be nice for "the properties", although "the detailed properties" doesn't imply the right thing. Maybe "the complete properties" or "the full properties"?

I agree with that. There are uses for the properties other than setting the properties of one object to another or for vcs purposes and some of those uses involve getting as many of the properties as possible (within the constraints of synonyms, derived properties, etc)

Pete

[monte]

@mwieder I will remove card rect

1) Only the minimal set of properties needed to define the object should present when fetched.

OK, think I've done that

2) The script and custom properties of an object should not be present when fetched.

OK

3) Any overlapping properties that must be present (because it isn't possible to fully define the object without both) should be specially handled when set.

Can you give me an example of overlapping properties that require both? I can't think of any at the moment.

4) The id property probably shouldn't be present when fetched.

I agree with @mwieder about ID... I think that should be in there because we don't know the context of how and where the properties will be set and the error lock is on during setting anyway...

5) The field object should probably only have the 'styledText' property returned.

Hmm... Isn't htmlText a complete representation of styledText? At least in the context I'm using it in it's much easier to work with because I don't need to worry about encoding... for styledText I'd need to parse it for unicode and utf8 it... I do realise it's not just me using this thing and I could delete the key and add htmlText but htmlText is already there and if it doesn't lose any data then it would be good to stick with it...

6) Only properties that can be set (and are persistent?) should be present when fetched.

Right, that's what I've done. There were a few extra read onlys in there and I was going to add some more like paintCompression but after thinking about it I went through the list and deleted read onlys.

I'd also strongly suggest that things like unicodeLabel should only be present if the control actually requires unicode encoding

Hmm... OK, I don't think it will impact me a great deal... it's a little frustrating that the data appears to be utf8 encoded no matter what and that's what I want to end up with but to get it I'd need to implement a whole separate property... I guess hasunicode() is my friend?

[mwieder]

I had the same sort of concerns about #5, but not having followed the latest field paragraph changes I was reluctant to add a comment. But the htmlText seems to be a complete representation of the field effects. Is there anything that "styledText" has that "htmlText" doesn't?

[monte]

Yeah... I might be wrong about htmlText being a complete representation but I thought that soon after styledText was implemented that htmlText was upgraded to cover everything.