Automation Interface: Attribute Order

[Uffe]

Hej allihopa!


When I use the Automation Interface (Java) to create classes, the attributes end up ordered by name, not the order specified. I'm just calling elements.AddNew() a number of times.

The thing is, while the order is not important in UML I am in fact creating classes which, in the next transformation step, will get turned into Enumeration types. In other words, I do want the order preserved.

Is there a way of doing this in the Automation Interface?

Cheers,


/Uffe

[Frank Horn]

Have you tried EA.Attribute.Pos?

[Uffe]

I hadn't, and it works like a charm.

Thanks, Frank!

You (or anyone else) wouldn't happen to know how often it makes sense to call Update(), would you?
Right now I'm calling it after every single change I make to an element; would it be OK to call it once after I've done all the changes I need to do (such as calling it once on a class after I've added the stereotype and all the elements)?
And would that give me any sort of performance improvement?

/U

[Frank Horn]

You (or anyone else) wouldn't happen to know how often it makes sense to call Update(), would you?
Right now I'm calling it after every single change I make to an element; would it be OK to call it once after I've done all the changes I need to do (such as calling it once on a class after I've added the stereotype and all the elements)?
And would that give me any sort of performance improvement?

Uffe,

I wish I knew. Last time I experimented with the API I ended up calling update and refresh everywhere, and certainly more often than necessary, and to hell with performance. Those who are in the habit of fiddling directly with the database might know. At least I guess that you can set all properties which will be written to the same table before calling update. If this is so, you ma well gain performance this way.

Frank

[Geert Bellekens]

Update() will save the properties of an object to the database, think name, notes etc..
Refresh() will save the changes made to a collection such as element.attributes.

Usually it is enough to update or refresh after making all the changes to an element, except when creating new elements. Then you need to call update right after you created it (that will give it its ID). Only then you can continue to work with it.

... I think ... :-?

Geert

[Eve]

That's pretty much right Geert.

Update is a save.  You basically need to call it when you've finished changing something.  Also, there are some things that you can't do with a new object until it is saved.  So it is easier to save it immediately after it is created.

Refresh doesn't actually save anything.  What it does is updates the in memory representation of a collection from the database.  So if you've added an attribute, or removed one and you want to iterate over the attributes again, you will need to call it.

[Frank Horn]

Update is a save.  You basically need to call it when you've finished changing something.  Also, there are some things that you can't do with a new object until it is saved.  So it is easier to save it immediately after it is created.

Which still leaves the question whether you can improve perfomance by calling update only when necessary. And what exactly are the "some things" you can't do with a new object before? I suppose these are things involving a reference to the new object (like a new connector).