the properties

[mwieder]

For my xml export function, I first do the properties, then the custom properties, then the custompropertysets at the same level:

<property>
<rect>1,2,3,4</rect>
<whatever>42</whatever>
</property>
<custompropertyset name="pogo">
<property>
<aligator>albert</alligator>
</property>
</custompropertyset>

[monte]

similar here for lcVCS but I put all custom property sets into one key (customPropertySets) at the same level as properties... still they are properties of the object so maybe they should be in properties?

[mwieder]

I think it makes sense for them to be in properties. Otherwise you have to think about it separately.
Kind of the same way that custom properties are part of properties.
For recreating an object from version control you would treat custom properties the same as properties ("set the... of... to ..."), and with custompropertysets it's just one extra step, so for me thinking about them all in the same breath makes perfect sense.

[monte]

Hmm... ok so what should the array look like?

for lcVCS I have:

Code: Select all

customPropertySets
    customKeys
        whatever
        ...
    cRevGeneral
        whatever
    dgProps
        whatever
        ...

Does that work if that's a key of the properties? Should customKeys here be moved to its own key customProperties???

[mwieder]

Do you need to handle customkeys differently? You've got two options:

treat the custom properties in customkeys the same way as built-in properties (set the custompropertyset of ... to empty, set the...) or
treat them like other custompropertysets (either set the custompropertyset to "customkeys" or trap "customkeys" as a tag and do the right thing

the first seems easier to me both in terms of exporting the properties (built-in properties and custom properties are at the same level and treated the same) and in terms of importing/recreating objects (again, a simple "set" command handles both).

But I don't even bother with the "customPropertySets" tag... just put the customPropertySet tag at the same level as the built-in properties>

Code: Select all

button name="btnCreate" id="1046"
  ...
  menuHistory 1
  custompropertyset name= "cGLX2General"
    cHscrollScript 0
    cHilitedLine 4

... and keep in mind that someday soon we'll have multidimensional custompropertysets...

[monte]

hmm... the second way (treating them as a set) seems to make more sense to me. Actually depending on the current customPropertySet the properties level customKeys might not actually be the default set... They are always the customProperties[""] though... which I think should be a synonym of the customProperties["customKeys"] but that's another story...

We kind of already do have multi-dimensional sets. I use them all the time. lcVCS handles it because the whole thing is just passed off to ArrayToJSON.

Getting and setting multi-dimensional keys though is problematic because it's hard to work out if you are referring to a key of a customProperty or a key of a customPropertySet where the first key is the set name. I think the answer is all multi-dimensional property set access is done via the customPropertySet...

[mwieder]

hmm... the second way (treating them as a set) seems to make more sense to me.

OK - I don't have strong opinions one way or the other on this. As long as it works, it should be fairly transparent.

Actually depending on the current customPropertySet the properties level customKeys might not actually be the default set....

Yes, I explicitly set the custompropertyset to empty before accumulating the custom properties.
And after accumulating a different set as well.

We kind of already do have multi-dimensional sets. I use them all the time

Well, you know what I mean... you can't set the wakeUpTime[roomNumber][guestName] of control "alarmClock" to "08:00"
Yet.

[monte]

OK, I might wait for runrevmark to comment on this because it is documented as not returning custom properties. I've tried to make it conform to docs so far by adding missing properties and removing read only properties. The docs can change though...

[monte]

Really need a comprehensive list of properties that set other properties.... So far I have:
- rect messes with gradients
- style messes with a heap of things
- textSize messes with textHeight

If anyone can think of any others then please post here.

[mwieder]

If you're using rect exclusively then you don't have to think about the interactions between width/height, top/bottom/left/right. But they have to be done in order as well.

[monte]

that's a good point. Setting the properties will try and set any properties in order. So I guess, rect,width,height then the left,top,bottom,right,topLeft etc can be set whenever they are found in the array

[mwieder]

I guess that's right, but my point was more that if you're going to set the rect you don't need to bother with the others.

[monte]

Right but the way the properties is set it will just set any properties that are keys of the array. It doesn't matter if they are ones that were returned by the properties or not. So someone could get the properties, delete rect, add width and height and topLeft and now i should work right...

[mwieder]

OK. Got it.

Filler to get past the forum sillyness:
You cannot make another post so soon after your last.

[phaworth]

OK, I might wait for runrevmark to comment on this because it is documented as not returning custom properties. I've tried to make it conform to docs so far by adding missing properties and removing read only properties. The docs can change though...

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

Pete