the properties

[monte]

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.

Well it would work on both the templateButton and any other object reference just like the properties... but like I said I'm not sure what needs to be done to overload a property like that... property check to see if the next token is "of" I guess... but then it's a function sometimes pretending to be a property...

As with the properties, the propertynames is incomplete.

Is there an open bug report on what's missing. It could be that some things are actually functions so would be in the functionNames

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".

Hmm... I think that would be hard to implement currently... the only way I can think to implement it is to parse the factor table for properties then filter them out against the tables in props.cpp which is the only place object property names are identified... what would be good is if the factor table had an extra field for object type but that's a bit tricky for stuff like filename where there's no inheritance rule you can apply...

[mwieder]

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.

It also means that someone has to maintain that list manually, which is error-prone and usually not at the top of the to-do list. Some way of generating these automatically would be better all around. I don't think it's a high-priority item right now, but it *is* a feature that's missing to make a complete set.

[phaworth]

Hi Mark,
Cane across another couple of properties for the missing list, both in the Graphic effects array - knockout and Effect Source. Neither is in the dictionary.
Pete

[mwieder]

Um. Are those new? Never heard of either of those.

[phaworth]

Um. Are those new? Never heard of either of those.

I'm not sure. You'll see them in the Graphic Effects tab of the Inspector palette. Knockout is a checkbox and Effect Source is a option menu (can't see it's contents 'cause I've never seen it enabled yet.

Pete

[monte]

Hmm... I think what you are asking for is:

put the [global|local] propertyNames [of objectReference]

Right now there appears to be no way to tell if a property is global or local other than if the function just had a heap of constants in it for the local ones. Like I said it would be possible to filter the propertyNames for object type using the arrays in props.cpp. But that would only separate the object properties from the global and local ones... So stuff like lockMessages would be mixed in...

I think this is a separate contribution (should be a separate forum topic/branch/pull request) to the one I'm making which is just intending to sort out `the properties`. I added `the effective properties` because it was easy... but I'd really like to see some design changes before we go adding more features that require more constants that need to be maintained... it's probably actually easier to maintain them in a stackfile come to think of it...

Anyway... my biggest concern now is the change to not include any key that has no value will mean that applying the properties of one object to another will do a union rather than set any empty properties to empty... Is that reasonable? Perhaps I should only filter out the ones that conflict with each other like foreColor,forePattern,strokeGradient...

Next is how to deal with setting the properties from the array when some properties need precedence. For example, rect needs to be set before gradients, style needs to be set before lots of properties... a new one BvG found for me... titleWidth needs to be set before rect

[monte]

titleWidth needs to be set before rect

no it doesn't ... phew

[phaworth]

Um. Are those new? Never heard of either of those.

Here's some more that are missing for a stack, at least if you get the properties of the templateStack

mainstack
systemwindow
stackfiles
textalign (not sure if this is valid for a stack, maybe it sets the default for any controls created within it?)

There's also no mention of external references. Not sure of that qualifies as a property or not.

Pete

[monte]

I've added externals and stackfiles already..

There' a few things like mainstay, substacks, cardIDs, etc that I'm not sure if should be in the properties... Is it the properties of the object only or it's relationship with other objects?

[phaworth]

There' a few things like mainstay, substacks, cardIDs, etc that I'm not sure if should be in the properties... Is it the properties of the object only or it's relationship with other objects?

Good point. I guess I'd always thought of mainstack as a property since it's available in the IDE Inspector palette and is editable.

[monte]

Right.. I guess it depends on how the properties will be used... if you want to set the properties of one object to another you might not want all the relationship stuff...

[phaworth]

Monte,
Sorry to throw more complications your way but I just found that some of the properties on the Table tab of a field are stored in a cprop set named cRevGeneral. Specifically:

table
celledit
cellformat
maxcolumncount

They're not listed in the dictionary.

There's also the following, which seem to have fields in the Inspector palette but I can't get them to show up:

formatcellline
formattypeline
formatvalueline

I'm not sure but I think the latter may have been part of the old db query stuff so no longer relevant

[monte]

right... I'm not sure if the properties should also contain custom property sets. Could be helpful...

[phaworth]

right... I'm not sure if the properties should also contain custom property sets. Could be helpful...

I'd vote for not including cprops in the properties since it's easy to get hold of them in other ways. I guess in this case, those properties should really be in the same place as all the other field properties, not sure why they ended up in cRevGeneral. Overall, I'd say just don't worry about them - I might enter a QCC request to move them into the properties.

Pete

[monte]

most of the table object is just a library built on top of tabstops.. these are library properties