eadocX Support

[eadocX Support]

There’s no practical limit to how many different ways you can print things – I have Profiles with 60 element types, some of which have 10-12 different stereotypes, in a 40 Mb model. This is towards the top end of the complexity we’ve seen, but eaDocX seems to cope OK.

[eadocX Support]

Is your diagram larger than an A4 page? If so, this is a known problem, and one for which we don’t have a solution. For these big diagrams, what do you want to see ?

[eadocX Support]

If I understand your problem correctly, perhaps the best solution is to have a profile for ‘proper’ classes, and another for <> classes. Then you can choose to print them in different ways.
See if this helps – if not, send a example of your model (a diagramis OK) and what you want your document to look like, to support@eadocx.com

[eadocX Support]

We didn’t include table numbering, as it’s not somewe use ourselves, but what you suggest seems very sensible. I have added it to the ‘to do’ list for the next release (this will be 3.3, as 3.2 is reserved for the new eaDocX Corporate Edition)
I think we will make the options just the same as for figure/diagram numbering – would that be OK
Thanks

[eadocX Support]

Only solution I can think of is to take the Activities outside of their Lanes, and then print them. But this would change the structure of the document…

[eadocX Support]

We took a very strict view on which kind of scenarios can re-join.
Only Alternate paths can rejoin, as Exception paths, by definition, fail. So, Exception paths don’t rejoin.
Does this answer your question ?
Or the problem might be that you haven’t set the ‘rejoins’ value in EA – it’s quite hard to do, as the EA user interface to set it is complicated.

[eadocX Support]

New attribute ‘Path’ is now available, ro Packages and element, in V3.0.0.2, which is now available from the Downloads part of eadocx.com

[eadocX Support]

Ha – you don’t want much 🙂
The first idea is no problem – the second would require much more complexity – we would have to make another parameter for ‘how far back up the tree to print’ – in your case 3-levels. Other might want to start from the top and print :
Functional View::Static Structure::Classes::Classname
– so there would need to be another parameter to say where to start. This will have to put put in the requirements list for 3.1

So, for the moment, I’ll just create a new attribute for Packages and Elements which is something like ‘Full path name’. I’ll have a look today, and see how hard it will be, then I’ll re-post when I know which release it will be in.

[eadocX Support]

Fixed this one – will be in 3.0.0.2 later today.

[eadocX Support]

I just noticed that as well – just thought maybe it was too early in the morning.
I’ll have a look.

[eadocX Support]

Certainly looks like a bug to me!
Can you send a .eap and document to support@eadocx.com, and I will have a look
Thanks

[eadocX Support]

Michael,
It’s not currently possible to have arbitrary text, except as you describe.

As for the path, what would you like that to look like? All the package names, with some kind of delimiter ?

[eadocX Support]

I think that perhaps the supplied definitions for method parameters are not compatible from V2 to V3. Until I can rectify the error, I suggest that you delete the ‘parameter’ attribute, and add it again – maybe using the new ‘Parameter summary’ attribute, which gives a similarly formatted string to that which EA proivides.

BTW – when eaDocX prints “n/a” it’s a polite way of saying “I’m looking for an attribute which the Generator doesn’t recognise” i.e. a system error 🙁 That would make it our problem!

Glad you’re having a good time with eaDocX – keep us posted on your experience.

[eadocX Support]

I always thought that 😉

[eadocX Support]

I’ll investigate, but I worry about slowing-down the generation process.

[Author]

Posts