eadocX Support

[eadocX Support]

V 3.3.4.0 has fixed this – I think!

[eadocX Support]

I see your problem.
Back in the days of using just plain old Activity Diagrams for processes, we could choose a different stereotype for the ‘complicated’ Activities, and another for the simple, leaf-level ones.
I hadn’t noticed that the EA BPMN mechanism needs to use the <> stereotype for all BPMN-type activities. A truly strange implementation.
Using a stereotype in this way really makes a mess of how eaDocX tried to do things: different stuff gets different stereotypes, and different stereotypes print differently.
I’ve racked my brains for a solution to this, but I just can’t see one.
You clearly want the ‘complex’ Activities to print their child Activities, so they need to print as ‘inline’, so they can print their diagrams as well.
And this doesn’t look so good when printing the child, simple Activities, which have no diagrams or children.
So I’m afraid you’re stuck with always printing them ‘Inline’. Using ‘Compact Document’ should remove some of the useless headings etc, but I’m afraid we’ve been bowled a googly by EA.
🙁

[eadocX Support]

Ah – I see.
Can’t do that with eaDocX.
In a normal hand-made document, I totally understand why we don’t want to repeat information.
But in a generated document, I’m generally not so concerned.

[eadocX Support]

In the Profile for the Class, just choose to print the Method Summary attribute. This is just the names of the methods.

[eadocX Support]

It’s possible to have different Profiles for Interfaces and Classes. Just get Classes to print their Methods, and Interface not.

[eadocX Support]

You’re quite right. EA seems to cache new Glossary entries, and doesn’t make them available at the API immediately. The only way to make the glossary 100% up-to-date is to close EA, which seems to flush the cache, open EA again, and generate the document. I have reported this to Sparx, but no fix has appeared 🙁

[eadocX Support]

You’re right that, when you use a Word Table Style, we don’t try to use the eaDocX-defined cell padding – the effects are unpredictable!
I can’t seem to find a ‘cell padding’ setting in the Word Table definition (in Word). I think this may be because ‘cell padding’ is an HTML idea (eaDocX inserts tables into Word as lumps of HTML).
I got the effect which I think you are looking for by editing the Word Table style and adding indentation to the paragraph settings for the table. This way, you can have different indentation for headings, first column, alternate columns etc.
Probably more flexibility than is useful (this is Word after all!) but hopefully you’ll be able to get the look you want.

[eadocX Support]

You’re right, Phil. The sequence is not saved in the repository.
The easiest way to get around this is to pick a Word heading style which uses outline numbering. Then word will add the numbering back for you.

[eadocX Support]

Not really….:-)
Maybe you could enclose a screen-shot of an example model, plus what you’d want to see in the document(s)

[eadocX Support]

Short answer is no…
..but this is a feature we used to have in the very first, hard-coded version of eaDocX, and one which we’ve been thinking about re-instating. But it won’t be easy!
Just so I understand what you need, is it to have a reference in document #1 which says e.g. ‘See Document #2, page 46’ or ‘See Document #2, section 3.4.1’?

[eadocX Support]

I have not received a reply from Sparx about this, which is fairly typical. They provide a way to ‘request a Feature’ and , as Global Partners, we also have a ‘side door’ for requests, but they usually just develop which ever new functions they want.
I looked at doing a manual re-sizing of diagrams, but its just just too complicated and unreliable to re-calculate all the geometry.
You can help by making a request on the Sparx forum, to ask for an API for resized diagrams.
In v3.3 I have added a feature to print diagrams which (in EA) are flagged as printing Landscape, to print in a separate Landscape page, and I have tried to get these big diagrams to fit that size of page as well as I can, but I’m manipulating a bitmap image, not the individual diagram elements.
I wonder, though, if you have a diagram this big, printed in a document, how will the reader understand it? I always split my diagrams (the ones for public use) into smaller ones, and keep the ‘big picture’ diagrams in my models, just for use by EA users..
…but I realise that doesn’t fix your problem…

• This reply was modified 11 years, 7 months ago by eaDocX Web Support Team.

[eadocX Support]

OK – we’ve had another think about this, and the consensus amongst the eaDocX Elves is that the only way to do this is to:
(1) generate the document using eaDocX, so that ALL paragraphs have a defined Word paragraph style, then
(2) write a Word macro which parses down the document, probably using the Outline levels, remembering at which outline level you are at each point, then change the indent level on each paragraph/table/diagram to have an indent which is appropriate to the indent level, then move down/up to the next outline level.
Should be fairly straightforward, as it could be done in a single pass, and, once you’ve created it, should run against any document which has predictable paragraph styles.

[eadocX Support]

I’m having another look at this, just to make sure…
How do you achieve the effect today? Do you manually indent the text, based on the heading level of the section that the requirements are in?

[eadocX Support]

Ah – I think I see. It’s the indentation.
This can’t be done with eaDocX. We have designed it to make documents which are as consistent as possible, so this is the kind of thing we’re trying to avoid!
Just out of interest, why does the indentation need to look this way? Is it your choice (because it’s just what you want to see), or a restriction imposed on you ?

[eadocX Support]

Ah I see.
I’ve looked at this before, and getting some text in eaDocX to look just like how the text will look in Word is surprisingly hard – there are just so many ways that Word can format text, not just font & size, but colour, indentation, underlining…it was too hard to get it looking right – reliably.

[Author]

Posts