eadocX Support

[eadocX Support]

What does the Admin application say? See the Help for how to run this diagnostic app.

[eadocX Support]

Good idea.
It’ll be in the next maintenance release

[eadocX Support]

And 🙂 customers is what we want !

[eadocX Support]

OK – I get the picture: you don’t like the blank lines!
I’ll have a look at all the places where we add an extra line (usually because it makes MOST documents look neater..) and either remove them, or make an option.
One problem is that sometimes these extra lines are needed. If, for example, you choose to print TWO Relationship Tables, one after the other, then without the extra lines, the tables would stick together and look very strange. The eaDocX Generator is highly modular, and prints each table separately, so one tables doesn’t know it’s followed by another. Hence adding a blank line just to be safe.
What you you like us to do about this? (clue – re-writing the Generator just for this isn’t an option!)

• This reply was modified 11 years, 2 months ago by eadocX Support. Reason: additional comments

[eadocX Support]

The eaDocX ‘Find in Document’ function just finds the section, not each individual element within a section. This is because only the Section has its own Word bookmark: with the elements, we try to reduce the number of Word bookmarks to just those that are needed, as this makes generation quicker.

[eadocX Support]

Hi Robyn,
Thanks for this – I’m pleased you’re now making progress.
Strange that it works one way, but not the other – I will investigate!
Ian

[eadocX Support]

You can control the Word Styles used here in eaDocX, Settings and Options….Diagram settings.

[eadocX Support]

I think I know why.
In recent years, EA has started to blur the boundary between an element type (which is definitively described in the otObjectType enum) and a stereotype.
So, when EA lists what is describes as ‘Element Types’, in many places, that’s a mixture of true element types – like ‘Class’ – and common stereotypes – like <>Class.
There’s no obvious pattern to when EA does this, so eaDocX has no choice but to take a strict view of element types vs. stereotypes.
Element Types are the values which appear in the Object_Type column of t_object, and no others are allowed.
Stereotypes are everything else.
So, to print <>Class elements, create a Profile for that stereotype, and I’m confident that all will be joy and happiness.

[eadocX Support]

See posting https://store.eadocx.com/forum/2-eadocx-queries/918-table-sizes-column-widths-full-table-width#1160.
If you have further questions, please add more to this posting.

[eadocX Support]

Hi Ben,
When eaDocX prints ‘n/a’ it just means that it looked for a tagged-value (of the name you provided), but could not find one for that element.
This is common when using MDGs, where you might have elements of your new stereotype, but they have not been given all the correct new tagged values by EA.
I think the way to fix this is either:
– Gte EA to synch the tagged values – see http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/synchronizetagsandconstrain.html
AND/OR
– when eaDocX tries to print a TV which does not exist, have it print something else (i.e. not ‘n/a’) – see eaDocX, Options and Settings, Application Settings, General, Default Strings, No tagged value present. I like to keep the string as non-blank, because it reminds me that my model does NOT contain the tagged values I expect, which is something I need to fix.

[eadocX Support]

#1 was never going to work, but I rather like the idea of having eadocX look at that little ‘do not print me’ flag, so that’s something we’ll look at…

#2, I just tried this, and it seemed to work: I followed all the same steps as you, and created a Package with a stereotype of ‘wibble’, then created a Profile for <>Packages which said ‘do not print’.
And the package didn’t print.
Can you email a small XMI so I can try with your model? Send to support@eadocx.com

[eadocX Support]

Strange that the order changes. It’s supposed to print the element in order of the names of the element types. So Activities print before Requirements, followed by Use Cases.
We did this because there’s nowhere to specify an another order.
I normally suggest to all EA users, whether they use eaDocX or not, that they try to put elements of a single types in most packages, which then lets you control the sequence.

[eadocX Support]

If you just select ‘Continue’ eaDocX usually just carries right on working.
This is caused by Windows ‘helping’, by spotting that Word & eaDocX have been working away for too long, and might have a problem. So it asks you if everything is OK. There is no known cure to this issue, which is widely documented on the interweb. We’d LOVE to get rid of it, but all attempts over several years have failed. Looks like Windows * is trying even harder to be helpful!

[eadocX Support]

Hi Jeff,
It may be that when printing Landscape, eaDocX is picking up the Word Style setting from the diagram image above it.
Have a look at the Diagram Settings :: Word style for Diagram Picture. Is his set to a style which is left/right justifying the text ?

[eadocX Support]

I’m sad that you’re sad.

[Author]

Posts