the properties

[LCMark]

That is a good question - I can't really speculate why 'script' wasn't included before... Except (either) compatibility with another xTalk, or password protection.

However, if 'the properties' is to make it possible to recreate an identical object (apart from id, of course) then it probably should.

[monte]

Hmm... that brings the question of what the purpose of the properties is... It's certainly convenient (if it works to get and set all properties in one hit). I guess script brings in the password protection stuff... maybe that's why it's not included... could be a good enough reason I think

Need more info on these scrollbar properties which don't seem to have related syntax.
uint16_t fw;
uint16_t trailing;
uint16_t force;

[LCMark]

They are the decomposed form of the scrollbar's numberFormat property.

[LCMark]

Another thought here... Should properties that aren't set be included?

For example: if the title of a stack is non-unicode then perhaps just a 'title' property should be present; if the title of a stack is unicode then perhaps just a 'unicodeTitle' property should be present.

Similar for the pattern and color properties... If borderPattern is set, then borderColor shouldn't be there and vice-versa.

Not doing it like this causes problems when doing 'set the properties of object to the properties of object'. The properties are set in hash-table order, so if there are ones that overlap (like pattern and color props, and the unicode and non-unicode props) they can conflict (e.g. you might end up with a non-unicode label even though it should have one).

[monte]

other than that the only ones I didn't have were the new unbounded scroll properties for groups... now the question is, can this whole thing be redesigned to reduce all the duplication all over the place... the duplication in props.cpp alone is frustrating... add that to the fact that all these properties are represented in those structs, defined in the lextable and accessed via MCObject et al it's no wonder the properties array hasn't been updated... There's probably no point redesigning props.cpp so it uses the property inheritance from the structs if you have a grand plan for this stuff which I suspect you do. In the meantime it's not hard to update what's there but if we have libraries (lcVCS) relying on it being right it would be nice if it were just automated somehow...

if the title of a stack is non-unicode then perhaps just a 'title' property should be present; if the title of a stack is unicode then perhaps just a 'unicodeTitle' property should be present.

Hmm... I just replaced non-unicode ones with the unicode equivalents so there was no risk of data loss but I guess your idea is better. It will probably make the whole thing more complicated... but I guess just for the unicode props and perhaps a few others.

Similar for the pattern and color properties... If borderPattern is set, then borderColor shouldn't be there and vice-versa.

Hmm... ok, what other properties have that kind of issue.

Not doing it like this causes problems when doing 'set the properties of object to the properties of object'. The properties are set in hash-table order, so if there are ones that overlap (like pattern and color props, and the unicode and non-unicode props) they can conflict (e.g. you might end up with a non-unicode label even though it should have one).

There's also a problem with gradients and rects here too because gradients are relative to the topleft of screen instead of the loc of the object so rect needs to be set first... I handle this in lcVCS... hmm... the whole thing needs a rethink... I guess if the arrays in props.cpp are in the correct order for setting (rather than alphabetical) then there could be a setproparray method that iterated over the array in order rather than in hash-table order...

[LCMark]

other than that the only ones I didn't have were the new unbounded scroll properties for groups... now the question is, can this whole thing be redesigned to reduce all the duplication all over the place... the duplication in props.cpp alone is frustrating... add that to the fact that all these properties are represented in those structs, defined in the lextable and accessed via MCObject et al it's no wonder the properties array hasn't been updated... There's probably no point redesigning props.cpp so it uses the property inheritance from the structs if you have a grand plan for this stuff which I suspect you do. In the meantime it's not hard to update what's there but if we have libraries (lcVCS) relying on it being right it would be nice if it were just automated somehow...

Well, as part of the syntax refactoring project, property handling on objects has changed quite a bit - there will be a (meta-information) structure that describes the properties objects have. However, we are quite a way from integrating any of that.

Hmm... ok, what other properties have that kind of issue.

Not many I don't think... I'm pretty sure its mainly just the unicode and color/pattern ones... Graphic objects fillGradient and strokeGradient unset the relevant color/pattern props too in a similar fashion.

[monte]

Well, as part of the syntax refactoring project, property handling on objects has changed quite a bit - there will be a (meta-information) structure that describes the properties objects have. However, we are quite a way from integrating any of that.

OK... still probably no point me doing too much short term refactoring there then...

Not many I don't think... I'm pretty sure its mainly just the unicode and color/pattern ones... Graphic objects fillGradient and strokeGradient unset the relevant color/pattern props too in a similar fashion.

OK, I think the unicode ones are easy... just forget the MAC/ISO ones... that way you know what you're dealing with. The colours and patterns probably need to do what you say and only return a value if there is one with fill/stroke gradient also coming into the mix. Other than that when setting we need to ensure rect is set first ... I guess I'd need to search the array for rect and if the key is there set it before sending the array off to setprops or add that to setprops...

[monte]

Code: Select all

if (!ep.isempty())
            v->store_element(ep, table[tablesize].token);

If I'm right this would then only add the elements to the array that have a value... would that do the job for colors etc? I'm assuming if it's array isempty is false.

[LCMark]

Yes - 'ep.isempty()' should only return true if the value is empty and not an array.

This is another place where the custom engine getprop's would have an effect on the returned array...

In terms of the changes, I think any improvement on the current version would be good - although we might get some push-back for only having 'unicode*' props though... I think it people would prefer non-unicode ones if the object doesn't have unicode in it (MCObject::hasunicode() can be used to test for this).

It might be that when we finish the fileformat import/export abstraction I was talking about the other day that it might provide a better mechanism for lcVCS than 'the properties'. At that point there'll be syntax like:

Code: Select all

  export <object> to array tArray
  import <object> from array tArray

This would give you an array of the properties that would be serialized into the stackfile, and thus a complete representation of the object. As would be a direct mechanism (rather than working by using setprop() / getprop() iteratively) it also avoids any property clashes (and issues with rects and gradients).

(In regards to rects and gradient positions, I must try and recall why I implemented it the way I did at some point - looking back, it doesn't seem to make much sense now...)

[monte]

Yes - 'ep.isempty()' should only return true if the value is empty and not an array.

OK... so are there any cases where empty is meaningful? Perhaps I should only add this is empty test for colors/patterns/gradients...

In terms of the changes, I think any improvement on the current version would be good - although we might get some push-back for only having 'unicode*' props though... I think it people would prefer non-unicode ones if the object doesn't have unicode in it (MCObject::hasunicode() can be used to test for this).

Hmm.. I'm not sure I like the idea of it sometimes returning label and sometimes returning unicodeLabel... Ideally I'd like to get the UTF8 representation that the engine has under the hood because right now I'm converting everything to UTF8 during the export and I see the engine is converting lots of stuff from UTF8 before it gives it to me... I know it's not only being used by lcVCS but I think it would be more annoying to always need to test for unicode properties than just to have them as a rule. Either way they would need to be dealt with.... please tell me we are getting UTF8 everything soon....

export <object> to array tArray
import <object> from array tArray

That's fairly cool syntax although given the array will be so close to the properties should it just be a synonym... I guess the export to array also includes custom properties and scripts too...

This would give you an array of the properties that would be serialized into the stackfile, and thus a complete representation of the object. As would be a direct mechanism (rather than working by using setprop() / getprop() iteratively) it also avoids any property clashes (and issues with rects and gradients).

Right... that would be nice.

(In regards to rects and gradient positions, I must try and recall why I implemented it the way I did at some point - looking back, it doesn't seem to make much sense now...)

When implementing gradients in lcVCS I queried it and Scott Rossi said one nice thing about it is you can create multiple objects on a card and set all their gradients the same easily.

[phaworth]

Not doing it like this causes problems when doing 'set the properties of object to the properties of object'. The properties are set in hash-table order, so if there are ones that overlap (like pattern and color props, and the unicode and non-unicode props) they can conflict (e.g. you might end up with a non-unicode label even though it should have one).

Presumably, the propertyNames would return all properties?
Pete

[monte]

I hadn't had a look at how the propertyNames is implemented but it looks like it will return any property (object, global, local) added to the language. It really wouldn't be that hard to use props.cpp to add the propertyNames of btn X etc to the language if people wanted it.... although I don't know what hoops need to be jumped through to overload a property name like that.

[mwieder]

I assume the propertyNames would return *all* properties.
And with that in mind, I'd like to suggest "the system properties" or "the system propertyNames", which would return just the subset that apply to the engine, i.e., "the traceuntil" and "the systemVersion".

[phaworth]

I hadn't had a look at how the propertyNames is implemented but it looks like it will return any property (object, global, local) added to the language. It really wouldn't be that hard to use props.cpp to add the propertyNames of btn X etc to the language if people wanted it.... although I don't know what hoops need to be jumped through to overload a property name like that.

Wouldn't that give you the same as the properties? What would be nice is something like the propertyNames of the templateButton or something similar that would get a list of the property names specific to an object type without having to have a specific object of that type to refer to.

As with the properties, the propertynames is incomplete.

Pete

[phaworth]

I assume the propertyNames would return *all* properties.
And with that in mind, I'd like to suggest "the system properties" or "the system propertyNames", which would return just the subset that apply to the engine, i.e., "the traceuntil" and "the systemVersion".

Yeah, that would be nice. You can get the list now from the cRevAllProperties of card "Global Properties" of stack "Message Box" but an official way to do it would be much better.

Pete