eadocX Support

[eadocX Support]

Can’t tell quite enough from this fragment – please can you email the full Profile to support@eadocx.com
Thanks

[eadocX Support]

..oh no it won’t.
There is no API into EA to save a diagram, so sadly this isn’t possible.
I’ll put in a request to Sparx, but so far their record of creating new APIs to help eaDocX to work better is exactly 0%.

[eadocX Support]

Good idea. I keep doing this as well. I’ll fix it.
It’ll be in 3.3!

[eadocX Support]

Sorry- I mislead you..
When I say ‘I create my own styles’ I’m referring to me-as-an-eaDocX-user.
eaDocX itself doesn’t change ANY word styles EVER.

[eadocX Support]

In v3.2, there are some differences in how styles are used.
in ALL cases, things like spacing, fount, colour (or color) are as defined in Word.
…which is my way of saying ‘any weird stuff isn’t my fault…‘.

I tend not to change the Normal style, as this is a built-in one, which I think is treated slightly differently by Word. I tend to create my own Word styles, based on Normal, but with my own name, and use that style for eaDocX generated documents. I have also noticed that the spacing can change sometimes without my doing anything, but I *think* this doesn’t happen for non-Normal styles.

BTW – in 3.3 we will allow you to use other styles for the Headings, rather than being constrained to the built-in ‘Heading 1’..etc

[eadocX Support]

Open the Profile of your TestCase element – make sure you’re printing it Inline.
Then on the sub-element tab, “Add details of a Sub Element”, choose Element Tests from the drop-down.
You can then format the profile Element Tests, and print out whatever you want.

[eadocX Support]

Doug,
There are some strange problems with caching in the EA glossary – EA problems, not eaDocX.
You may need to re-start EA for it to correctly display the entries in eaDocX, if you have just loaded a load of new ones.
Sparx seem to update their own UI OK, but don’t update the Glossary entries which are available at the API, which eaDocX uses.

[eadocX Support]

Ah – I see.
If you’ve used eaDocX to auto-populate the Profile, as you describe, then you get a whole load of stuff – useful and no-so-useful. Like you, I also use this to generate an initial document, then just delete the bits I don’t want.

It would be quite hard to do an ‘un-do’ on this – it’s a very stateful process!

To get back your particular example, Activity elements link to their ‘next’ Activity elements, using a directional ‘ControlFlow’ connector.

eaDocX will do its best to help you re-create this: look at the Profile for Activity, add an attribute of a related element, choose ‘ControlFlow’ as the relationship type, and the appropriate Direction for the connector, and Activity as the Target element. This should get it back.

This detailed knowledge of your metamodel is what we’re trying to save you from by having the auto-populated Profile!

[eadocX Support]

Doug – I don’t quite follow what you’re asking for here.
When you say the information is ‘lost’ do you mean it doesn’t appear in the Profile list ?
As for the Add Element function, I have thought about using an existing element type/stereotype as a kind of template for the new one. Is that what you mean?
So, if I have an element Wibble, with an Profile forun-stereotyped and <>Wibbels, , and I want to create Profile for <>Wibble, eaDocX would offer me the chance to base the <>Wibble on the format of the un-stereotyped Wibble, or on the <>Wibble.
Is this what you mean ?

[eadocX Support]

‘fraid I will need the document and the repository (or at least simplified versions of both) before I can shed any light on this one

[eadocX Support]

Short answer – none!
Just so I’m clear about the requirement…
When you document a Package, you can set the initial heading level he zero, which suppresses any detail of the top-level package, and just documents its immediate children as H1.
You’d like to do the same for an Element. So, no details of the top-level element will document, just details about it’s children. This also means any diagrams which are children of the top-level element also will NOT be printable.
Have I got this right ?

[eadocX Support]

Oh yes!
The fix will be a release which I’ll be putting onto the website later today – just doing a few other fixes at the same time…It will be 3.2.9.4

[eadocX Support]

OK – problem identified.
eaDocX is correctly producing valid HTML which it is passing to Word, but Word seems to be ‘helping’ by doing strange things to the table when it is put into the document. In my tests, this seems to happen when there are more than about 62 columns: at that point, the table is too wide to fit onto the page (an A3, Landscape page) and Word start to do strange stuff.
As this is happening inside Word, there’s not much I can do.
– I will test with Word 2013 shortly, to see if there are any differences – I’m not hopeful
– In eaDocX 3.3 we have a new feature for Matrix reports which means you can get them to print only rows/columns where this is data. This makes sparse matrices more readable. Maybe this will help.
– I also have a prototype HTML viewer which displays the data correctly, but this won’t be available until later in the year.
Until then, I can only suggest you create more, smaller matrix reports. 🙁

[eadocX Support]

I have tried creating a 100×100 matrix, and I am now seeing the same strange formatting as you – will investigate further!

[eadocX Support]

I have looked at your output document (thanks) and everything looks normal, apart from the extra, wide column at the right-hand side, which I can’t reproduce.
Is that what you are concerned about?
Other than that, this is exactly what a ‘compact’ formatted eaDocX Matrix Report should look like: it’s useful where there are a very large number of columns, which are too wide to fit into a page, so ‘compact’ style lista rows and columns down the page.
A 50×50 matrix will JUST fit into a Portrait-orientation format, A4 page when done in ‘normal’ style, as we write the column text vertically.

What were you expecting ?

[Author]

Posts