Colin Wood

[Colin Wood]

Please find attached MDG as requested.

[Colin Wood]

We have looked at other MDGs/Addins and they havnt anticipated this problem; they do not embed the FQN in the local name e.g. BPMN and ArcGIS so they would also have to change their stereotype names if they are to work reliably with eadocx.

Also Ive tried changing the stereotype name in the exported eadoc/Excel from the local name to the fully qualified name, and importing back to EA. EA handles this fine so I am not convinced that eadocx is not at fault here. DO you have evidence that the API is asymmetric in handling FQNs?

[Colin Wood]

Since this capability to drive eadocx with sql searches is included in the marketing literature should it not be included in your test suite for testing new EA versions?

[Colin Wood]

Elsewhere it says that eaDocX works fine with the release of EA v 13. Are you saying this (rather fundamental)issue is fixed now?

[Colin Wood]

Hello is there any progress/sympathy for this bug?

[Colin Wood]

I’m struggling with this one- all the SQL which I submit to the Sparx API (where the SQL has come from an EA search (with no diagnostics: just Error=0…).
So, this is going to take a while.

Any progress with this? What do the Sparxians have to say?
Are you saying that the Sparx API has/may have changed since you tested this feature?

[Colin Wood]

I have this trouble too. I need each diagram to be on one page (of A3 Landscape)and as large as possible between the header, footer and any headings.

I found that I could get the diagrams larger if I changed the Word Style ‘Figure’ to be left justified instead of centred.

But it would still be useful to have an eadocx option called ‘One diagram per page as large as possible’

Some more thoughts:
eaDocX appears to size an EA diagram in Word as top left of the EA page but bottom right most element coordinate, and then uses the eaDocX setting for max diagram height. Trouble with this is that you get different size images, the larger ones don’t fit and the smaller ones cause the next page headings and text to be brought forward under the small diagram. This causes a great deal of manual fiddling!
Couldn’t you have a setting in eaDocX to use the EA page size irrespective of the element positions?

[Colin Wood]

Anyone listening?

[Colin Wood]

I have now installed the latest version of eaDocX 3.8.4.3.
If I insert an Element TReport, with a Profile Source|SQL Query ‘List diagram version’ (which works fine in EA) and generate the section in eaDocX I get a DAO.Datbase [3075] Syntax error (see attachment) and no output.

[Colin Wood]

But I would make this feature very clear in the help pages to avoid people like me bothering you guys.

Also the error message “No element of type: Project Glossary in this repository” is being triggered by another error in my case i.e. there are no matching terms in the document and the repository. If this error were caught then you could put out a more accurate error message that would immediately guide the user to make the necessary correction.

[Colin Wood]

Aahh! Just noticed that eaDocX is clever – only includes terms that are actually in the document, so as soon as I include term ‘PIG’ in the Word doc eadocx correctly outputs the glossary for that term!

[Colin Wood]

OK Now have latest version installed and have tested this problem again. I created a new EA project and added a simple glossary with 3 terms. Then opened a new word doc in eaDocX, created a glossary section and hit generate.

Same error as before: “No element of type: Project Glossary in this repository”. I can confirm that eaDocX picks up in the profile that there is a Term element in EA.

[Colin Wood]

Sorry try these.

[Colin Wood]

Ok we are in a corporate environment with an IT org so this may take some time, but if this is the only way to move forward then so be it!

[Colin Wood]

Full Version 3.7.0.0

Using EA version 12.0.1215

[Author]

Posts