2) Is there a way with boundaries to set the "Boundary Style", from the default of "Solid - No Fill" to "Solid"?
Why, yes there is. Strap in.
It's all a bit complicated. By the looks of things, the functionality to deal with boundaries has been not so much designed from scratch as patched and added to in several phases.
The Shape and Style properties are actually split between t_object and t_diagramobjects. This kinda works because boundaries are diagram-only elements, meaning they're not shown in the project browser and there is a one-to-one relationship between the t_object row and the corresponding one in t_diagramobjects.
One-to-one, I said, and by that I mean almost: it is quite possible to copy/paste diagram-only elements between diagrams, resulting in two t_diagramobjects rows referencing the same t_object one. How exactly that affects the contents of the two tables is not something I've gone into.
So. Disregarding that special case, here's how a boundary's properties are stored.
Before we move on, I should say that I haven't found anything relevant in t_object.NType, t_object.PDATAn or t_xref. But it's always possible that I've missed something.
There are three columns of interest: t_object.BorderStyle, t_object.StyleEx and t_diagramobjects.ObjectStyle. Their use is not quite consistent, as I alluded to above. In addition, t_object.Backcolor holds the background colour.
Boundaries with Shape Rectangle only use t_object.BorderStyle. This is likely because way back when boundaries were first implemented, there were no other possible shapes (and therefore no Shape attribute as such). Thus only the Style property is represented.
Shape RectangleStyle (t_object.BorderStyles): 0 = Solid
1 = Dotted
2 = Dashed
3 = Solid - No Fill
For boundaries with other shapes, t_diagramobjects.ObjectStyle comes into play to hold the Shape property. The Style is still in t_object.BorderStyle, but now with a different set of values.
t_diagramobjects.ObjectStyle is a string containing a set of properties expressed as key=value pairs, each terminated by a semicolon. The order of these pairs does not appear to be significant. (There is always the "instance GUID", or DUID, which appears as 'DUID=xxxxxxxx;', where xxxxxxxx is an eight-digit hex number, but it appears in different positions in the list for different rows.)
Shape Rounded Rectangle, Ellipse and User DefinedStyle (t_object.BorderStyles): 4 = Solid
5 = Dotted
6 = Dashed
7 = Solid - No FillShape (t_diagramobjects.ObjectStyle): "shape=rounded;" = Rounded Rectangle
"shape=ellipse;" = Ellipse
"shape=freestyle;" = User Defined
User-defined shapes adds the last little wrinkle. They have a t_diagramobjects.ObjectStyle property 'LBL' which controls the label (and whose value is a sub-list of key=value pairs, separated by colons). I won't go into any details for this here, just note that it is created automatically for user-defined shape boundaries which means you may have to create it too if you plan to create user-defined boundaries through the API (but probably not).
User-defined shapes also get a key=value property 'Path' in t_object.StyleEx. This also contains a sub-list, a '@'-separated one of ':'-separated X/Y-coordinates. You probably do have to populate this in order to create a user-defined boundary through the API. For a rectangle, this will be something like
Path=20:-398@143:-398@143:-498@20:-498;I haven't been able to change the number of co-ordinates through the GUI, but it seems to me like it should be possible to create any polygonal shape by setting this property through the API. if you try it, please let us know how you did.
Finally, the
background colour. This isn't quite consistent either, but at least it's stored in just one place: t_object.Backcolor holds a signed integer whose value is either -1 for the default colour, or an eight-bit RGB value. When accessing the data from an Intel machine, the order of bytes from most to least significant is Blue, Green, Red.
Note that the background color is handled differently for different shapes and styles. For user-defined shapes, the background colour is only used for the
Solid style. For all predefined shapes, the background is only
not used for the
Solid - No Fill style.
The default colour also varies. For predefined shapes with style
Solid (three in total), one colour is used, but all other combinations of shape and style use another one (although strictly speaking,
Solid - No Fill shapes never use the fill colour). In my tests, these were pale yellow and white, respectively, but it may be controlled by the theme.
Since I haven't written any code to test this stuff, I'm not sure how to set all these properties through the API.
t_object.StyleEx is simple enough, that's just the Element.StyleEx attribute. But you only need this for user-defined shapes.
t_diagramobjects.ObjectStyle is probably DiagramObject.Style -- there's no "Style" column in t_diagramobjects and the API documentation says that this attribute is a "semi-colon delimited string" so they probably match -- although you may note that the DUID, which is stored in t_diagramobjects.ObjectStyle, has its own attribute DiagramObject.InstanceGUID.
t_object.BorderStyle is the most crucial one, and there's no attribute for it in Element. This probably means you have to write directly to the database. There's also a (slim) chance it can be set through some attribute in DiagramObject, but I think that's unlikely. Again, if you find a way to do it without invoking the dreaded Repository.Execute(), let us know.
Update -->I forgot the background colour. That at least is straightforward: either set the DiagramObject.BackgroundColor attribute, or call the Element.SetAppearance() method.
<--HTH,
/Uffe
