Messages

1

General Board / Re: Exception specification code generation

« on: December 05, 2003, 03:13:44 am »

Hi Ben,

Thanks for the response and for fixing the bugs. I'll use == in future.

Thanks for a great product !

Regards,

  g.

2

General Board / Exception specification code generation

« on: December 01, 2003, 07:32:09 am »

I am struggling to get EA to generate exception specifications for C++ code. I set the "throws" tag on my methods, but to no avail. After scratching in the code templates, I uncovered the following (which may or may not mean something):

The code template used for generating exception specifications for C++ code seems suspect. The line in question is

 %opTag:" throws" ? "throw " value : ""%
               ^^^

and is part of the "Operation Declaration" C++ code template (9th line from the bottom on EA 3.60.653). Note the space before the 't' in the "throws" tagname. Is this perhaps an error in the template ?

A similar occurence (tagname prefixed by space), involving "opStereotype", happens a few lines down -  does those spaces carry special significance ?

I "fixed" this by removing the space, but still no exception specification: it appears that there may be a problem with EA's conditional expressions (or in my head).

I create a class, "aclass" and set a tag, "atag" with value, "avalue". When I generate code for the class from the following class template:

// 1. %classTag:"atag"%
// 2. %classTag:"atag" != "" ? "yes" : "no"%
// 3. %classTag:"atag" ? "yes" : "no"%
%if classTag:"atag" != ""%
// 4. %classTag:"atag"%
%endIf%

I get the result:

// 1. avalue
// 2.
// 3.
// 4. avalue

As you can see, the tag does contain the correct value, but the conditional expressions all seem to evaluate to empty (not just stuck on false but completely empty). As number 3 is similar to the one used for the exception specifications, I suspect that that is where the problem with the exception specifications lies.

I eventually got exception specifications working, but only after using an explicit if (i.e. no conditional expression).

3

General Board / Re: Code generation defaults and scripting

« on: December 01, 2003, 04:56:31 am »

Thanks for the responses. I wouldn't call the behaviour a "problem" but rather just a bit of an iriitation on the user interface side. This is probably due to me being more used to a Unix environment, where scripting is big, allowing most tasks to be automated.

Even if I configure it to always overwrite (and never sync), it still wants me to confirm that I want the files overwritten.

4

General Board / Code generation defaults and scripting

« on: November 27, 2003, 03:23:16 am »

Hi,

Each time I generate code from EA, I follow the same canned sequence of steps: select "Overwrite code", click "Select all", click "Generate code" and then click "Yes" about 20 times (depending on the number of files) when prompted for "Overwrite existing file".

Although this works in principle, it is time consuming, error prone (I might click "No" by accident) and doesn't scale to large projects (number of clicks asymptotically linear w.r.t. number of files). I would therefore be grateful if there is a way to script or automate this whole process (if I could generate code without opening EA it would be insane). Second prize would be if EA remembered the choices I made last time when I generated code.

I couldn't find anything relating to code generation in the automation and scripting interface docs. What am I missing ?

Any ideas ?

5

Automation Interface, Add-Ins and Tools / Re: Use automation with Python

« on: January 12, 2005, 10:46:17 pm »

Bu66le,

Thanks alot! Changing from "GetClassForProgID" to your way using "Dispatch" works much better. Although "OpenFile" now fails with "The server thew an exception", "OpenFile2" works just fine.

However, I noted a strange thing: the "Dispatch" interface does not seem to distinguish between function and attribute references on an object. For example, where I previously did "repo.GetProjectInterface().EnumViews()",  using the static interface, I now have to do "repo.GetProjectInterface.EnumViews", using the dynamic interface.

As for your Python code, it seems fine and traversed my model without any problems. Thanks for the help.

  gerhard

 

6

Automation Interface, Add-Ins and Tools / Re: Use automation with Python

« on: January 12, 2005, 04:10:08 am »

Hi Oscar and bu66le,

I've had some success with accessing the EA model from Python in the past, but my luck seemed to have run out after upgrading to a more recent EA (4.50.743).

As I'm not that clued up on COM, I'm struggling to figure out exactly why things stopped working. Maybe someone can piece together a solution from my experiences.

I wrote a Python script that extracts and typesets requirements into a PDF document. After upgrading to EA 4.50.743, the script ceased to work (I cannot recall with which version it last worked, but I think it was 4.10.737) without any changes being made to the script. In the process of debugging the problem, I noted the following:

1. Executing "makepy" with no arguments presents a list of libraries in which EA *does not* feature. Previously, it featured there.

2. Using Microsoft's OLE/COM Object viewer ("oleview"), I see "Enterprise Architect Object Model 2.10 (Ver 2.a)" listed under "Type Libraries".

3. Executing "makepy" with "EA.tlb" as argument works, in that it generates the static dispatch Python proxies
to the EA objects (stored in gen_py). I noted that the new proxy was generated as version 2.10 and my old one as 2.2.

4. Using "GetClassForProgID", I am able to instantiate a repository object, using "EA.Repository" as prog ID. Unfortunately it fails at a call to "Repository.OpenFile" (as others reported) with a "Type mistmatch" error.

5. Calling "Repository.OpenFile2", results in a "Member not found" error.

6. Comparing the proxy objects of versions 2.2 and 2.10 shows the actual invocation (via "InvokeTypes") in OpenFile to be identical.

7. I can execute some other calls without causing errors, e.g. GetCounts().

Hope this can help us solve the problem. Any comments or suggestions would be appreciated.


   Gerhard