eadocX Support

[eadocX Support]

Hi Ken – you’re quite – the behavior is different, and deliberately so.
The Element Report collects all the elements of the required type into a flat list, then prints that list. So, if you tell it to collect ‘Package’ elements, you’ll get the packages all printed in a flat list, including sub-packages and sub-sub-packages, all the way to the bottom of the tree, but all printed in the same way. We deliberately don’t print children of packages, here, because you’d get lots of packages multiple times.

If you want to print the packages ‘as normal’, that is, with their children and sub-packages, then they way I’ve done that is to connect the required packages to something else. In my case, this was an element which represented a particular software release, which I connected to packages of Requirements, Changes, Issue etc.
This worked well, and allowed me to print documents for each release, even though the EA model wasn’t structured by release (it was by business area).

[eadocX Support]

“Package” has a profile, just like all other EA elements. Just tell it not to print its name as part of the title. This might work.

[eadocX Support]

Please see heading overrides in the help. You can override this setting with your own style.

[eadocX Support]

Just to check – these are not the styles for regular tables. They are for elements which print Inline, but have little tables as part of their formatting, which have data from just the one element. Did you want to change the formatting for regular tables? That’s a different setting.

[eadocX Support]

Is the problem still there in 3.5 ? I made some changes in this area, so it just might have got fixed…

[eadocX Support]

Melson is right – we add an extra line to stop one table from joining itself onto a following one.
We have looked at this several times, and we think whilst doing it this way does add extra lines occasionally, it is more reliable at creating a sensible-looking document. All the alternatives had bad side-effects in some circumstances.

[eadocX Support]

The Sparx Licence Manager is not an open API, so we can’t use it. In any case, we now have so many customers using the eaDocX floating licence mechanism that it would be very disruptive to change now.

[eadocX Support]

Update to this: the error is incorrectly reported as ‘no more licences’. In fact, it’s a communication error between client and the LSA, usually caused by network changes.
Best solution is to create a new LSA for the SAME machine as where eaDocX is installed. Remember, each LSA is IP-address specific, so you will need to go to the eaDocX website and create new LSAs.
Once this works OK, then create a new LSA on a network machine, is possible, one where you have Admin rights, and can control network and firewall settings.
Once this works, carry on looking at your network settings.

We have also seen many problems where the LSA is running on a Virtual Server: it’s a high-security application, designed to prevent fraud, and we think that the application doesn’t really understand VSs and throws strange errors. Sorry about this, but it’s out of our control. So, we recommend LSAs run on real servers.

• This reply was modified 10 years, 2 months ago by eadocX Support.

[eadocX Support]

Just so I understand this (so I can put it in the instructions for the LSA install) – you downloaded the LSA application to a network drive, then just ran the installer from there to install it onto the target machine ?
Weird stuff.

[eadocX Support]

There seem to be three distinct questions here:
1 – External trigger to generate a document
2 – Make eaDocX TFS aware
3 – pull-in different versions of a package to put in a document.
Suggestions
1 – There’s currently no support in eaDocX to have the Generator triggered by an external program. This would be harder than you might think, as, if you are using eaDocX Document Management, the UI will prompt for information about any new version, so that would have to be passed as parameters. But other than that, this might be possible. What would be the trigger ?

2 – TFS-aware. We’ve been asked about this a couple of times before, but we’ve always lacked any in-house TFS knowledge. And access to a TFS installation. But if you’re prepared to help us with these, all things are possible!

3 – Multiple versions. This might be the killer. eaDocX works only on the current contents of a single EA Repository. So, we’d have to load v1.0 into the package, generate that section, stop, reload the next version of the same package, then generate the next section.
This sounds hard! So we’d have to be convinced that there is demand for this facility.

[eadocX Support]

Have you tried installing this on another platform? (you’ll need to create a new LSA, as they are IP-Address sensitive). This is just to isolate this to a security/permissions problem, which I’m sure is where the issue lies.
There are no detailed diagnostics because we buy-in this crypto system, and there are no tracing options which we have found. We’ve not needed any before, as this LSA is a really simple application with (usually) not much to go wrong! Where we see issues with eaDocX floating licences it’s usually do do with connectivity from client to server, not with installing the LSA application in the first place.
Beyond this, I don’t quite know what to suggest….

[eadocX Support]

I think we need a few more clues here!
What OS are you installing on? What Service packs? Has it ever run on this platform before. If yes, what changed which may have caused the error?
Is it being installed with admin rights?
Is this error generated at install time, or at startup time?

[eadocX Support]

Ah – that’s interesting.
Creation of cross-references is where eaDocX is most sensitive, as each time it resolves a cross-ref, we have to make a call to MS Word, and these are expensive (a few 100ms each call), which is why we have the ‘Draft’ document option which lets you produce docs with not cross-references more quickly.
I can’t think of any specific changes to the cross-ref mechanism between the releases you mentioned, but it’s in the larger documents that we start to see different effects, as working arrays of variables get larger etc.
For the next non-maintenance release, I’ll put the performance analyser on the code, with a larger document, and see if there are any surprises.
Thanks

[eadocX Support]

Just checked that <>Attribute of a Class can be excluded, and that seems to work OK (eaDocX v3.5.0.4)

[eadocX Support]

Sounds like you are doing everything right!
Can you conform which eaDocX version you are using ?
Also, how did you change the stereotype of the PK attributes? When I created an example model to test this, I used EA’s Transformation mechanism, which makes class.attribute into <

>.<>, so I can’t then change the stereotype of the attribute, as it’s already set to <>.
Also, I’ve just noticed in the EA user interface, when I edit a column of a table, there isn’t a stereotype attribute for me to edit!
So, how did you do it!

• This reply was modified 10 years, 2 months ago by eadocX Support.

[Author]

Posts