Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Geert Bellekens

Pages: 1 2 [3] 4 5 ... 517
In the past I've used this workaround to get the actual image from a diagram:
Code: [Select]
/// <summary>
/// returns diagram image
/// </summary>
public Image image
        EA.Project projectInterface = this.model.getWrappedModel().GetProjectInterface();
        string diagramGUID = projectInterface.GUIDtoXML(this.wrappedDiagram.DiagramGUID);
        string filename = System.IO.Path.GetTempPath() + Guid.NewGuid().ToString() + ".png";
        //save diagram image to file (format ".png")
        projectInterface.PutDiagramImageToFile(diagramGUID, filename, 1);
        //load the contents of the file into a memorystream
        MemoryStream imageStream = new MemoryStream(File.ReadAllBytes(filename));
        //then create the image from the memorystream.
        //this allows us to delete the temporary file right after loading it.
        //When using Image.FromFile the file would have been locked for the lifetime of the Image
        Image diagramImage = Image.FromStream(imageStream);
        //delete the temorary file

        return diagramImage;

Do you want to retrieve a diagram image from EA and use it in Word, or get an image from Word and put it in EA?

For the first one you can use EA.Repository.PutDiagramImageToFile ()


In my case, the elements are relatively simple, so I can't see any problems in duplication. Anyway, if duplication is possible through user interface, why it is not possible in scripting?

It is possible, just not as simple as you thought it would be.
And "why?" is simply because it hasn't been exposed in the API.


Automation Interface, Add-Ins and Tools / Re: Discussions and Reviews
« on: December 04, 2017, 04:18:39 pm »
We do, but here Sinterklaas mostly brings hollow chocolate figures, speculaas and toys for the kids. :P
Traditions like that vary strongly from region to region.


Uml Process / Re: Tagged values
« on: December 02, 2017, 08:18:34 pm »
I don't think so.
I think "UML compliant" means that you can model UML according to the specification, and with EA you can.
There are loads of non UML things you can do with EA (databases, wireframes, BPMN,...) but that doesn't negate the fact that you can model UML Compliant models as well.

Now it would be good if there was some kind of option, similar to Strict Connector Syntax,  that would enforce all the rules of a given modeling language. That would really be a great feature (and much more needed then things like "Instant Chat", or "Charts" or, ...).


Uml Process / Re: Tagged values
« on: December 02, 2017, 05:42:25 pm »
So "tagged values" are now "stereotype properties". That somehow makes sense. Shouldn't EA get its wording aligned with the UML specs?

However, that still leaves the question: what are those "free tagged values" which should be "stereotype properties"? Which stereotype do they belong to? And the same with the "free stereotypes" which, according to the specs, should belong to a profile.


In UML 2.5 and 2.4.1 (maybe earlier as well, I didn't check) there is no such thing as a "free tagged value" or a "free stereotype".
A tagged value is always a property of a stereotype, and a stereotype always belongs to exactly one profile.

EA has historically allowed these floating tags and stereotypes, and it does still today, but if you use them your model won't be completely UML compliant.
In some of the xmi formats, stereotypes and tagged values are all mentioned at the end. In this format they have to be part of a profile, so EA invents a "default" profile to store them all.


Check the diagram filters, there quite lot you can do with those.


What happens if you leave out the where clause?

I don't see any inner joins, so it must be the where clause.

If you are using it as a search in EA then you can replace the '*' by '#WC#<Search Term>#WC#'

#WC# will be replaced by the wildcard appropriate for your database


Automation Interface, Add-Ins and Tools / Re: Discussions and Reviews
« on: December 01, 2017, 03:28:16 pm »
Geert, you like Santa, always accurate answers and also quick packed in nice wrappings  ;D

Hohoho!  ;D

Automation Interface, Add-Ins and Tools / Re: Discussions and Reviews
« on: November 30, 2017, 11:34:24 pm »
select * from t_document doc where doc.ElementType = 'Post'


The elementID contains the GUID of the discussed element.


Hi Andrew,

I have since long published a simple Excel importer on my website
This Excel file uses VBA to import elements and attributes into Enterprise Architect.

It does what I need it to do, and I sometimes update it with new features if/when the need arises.
You can download it and use it as a starting point for your tooling.

I know other people have extended it for their own use with capabilities such as
- importing more fields
- Importing operations
- Importing connectors

If you would like me to build something for you, we can organize a call and discuss details.
I could build something in Excel VBA, or use EA scripting engine, or do something in C# as well, depending on your needs.


Hi Adrian,

First and foremost I would report a bug to Sparx.
After all you are trying to fix an obvious bug for them using your add-in.

Then I think only the context item event approach will work.
The upside of it is that you can control everything with that. Editing, deleting, creating



Depending on the database you'll have to use a dot "." or a hyphen "-", so that error you got is normal.
The custom field in the template is always uses a dot.
Yes, I have several templates that use this and it works.


I think an XMI import includes references (GUID) to out-of-scope elements, so that they can be resolved if the referenced elements are present in the target project, but I think the import ignores those that cannot be resolved. I may be wrong on this.

That is exactly how I understood it works, so if you are wrong then so am I.


Pages: 1 2 [3] 4 5 ... 517