eadocX Support

[eadocX Support]

Ah – I think I’m starting to understand…
So, at the point after you have imported the new packages, and created some new GUIDs, I can’t quite see how we can specify which ‘stuff’ the document should use.
The Document has a arbitrary number of sections, which might be a ‘simple’ section, printing a Package, or Element, or Diagram (or Model view now), or be Element Reports (also keyed on a Package GUID, or EA Search, or be a Cross-ref report) or a Matrix (also has 2 x Package keys). Or a Project-type section e.g. Glossary, which probably should stay the same as the parent document.
All of these would have to be set at the point where the document is cloned.
Can this be done automatically with RTF? How does it know where everything is? Is it done based on relative position of the package/element/diagram in the package tree ?

[eadocX Support]

Well spotted Wayne: didn’t show up in my test environment, but you’re quite right.
Fixed in 3.4.0.2, now available.

[eadocX Support]

I’m not sure I fully understand the Use Case…but here goes:
I have an eaDocX document, which documents some Packages (#1, #2, #3).
I want to create a second document, a ‘clone’ of the first, but which documents Packages #4,#5 and #6.
So I need to tell the second document about the list of packages it needs to document.
What about any Element Reports, Matrix Reports etc which the document contains?
Also, is the idea of Model View-based document, in 3.4, any use to you ?

[eadocX Support]

Ah – I think I see what you need. In most other cases, when there’s an empty condition, we allow some other default string to be printed – looks like we missed one….I’ll have a look.
OK – there is a new Application setting to define what to print where no sub-elements are present. It is not specific to the kind of sub-element which is not present, as that is national-language dependent, so we can’t pick up the sub-element type from EA. So its a fixed string.
New feature will be in 3.4 Beta 2, when that is available.

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

[eadocX Support]

Have you tried using the ‘Compact Document’ option? Does this still happen ?

[eadocX Support]

One way to stop the elements from printing is to delete any Profiles for them – no profile, no print.
I realise this is a bit drastic.
There used to be an option to make Packages not print their Children, but this caused most users angst, as they expected to see the child elements: no printing them is exceptional.
I’ll have a look at some sort of ‘don’t print children’ option (backlog item #167) and the ‘exclude a list of things’ is also a good idea (#168)

[eadocX Support]

OK – I’ll have another look at this. I was a bad day @Sparx when they designed the Package mechanism – I spend a lot of effort trying to make Packages look like Elements, but it’s an uphill struggle.
UPDATE: I discovered that Cross-Reference reports NEVER supported Package. Well, they will, as of the next v3.4 Beta release (Beta 2).

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

[eadocX Support]

v3.4 Beta 1 is now available at https://store.eadocx.com/web-downloads/customer-downloads

[eadocX Support]

I’m working as fast as I can. Just building the beta now. Should be ready for use by start of business 19th Feb 2014. Lots to do to create whole new release…..

[eadocX Support]

By mere seconds, this issue just scraped into v3.4 Beta – both issues fixed. Well, I couldn’t replicate the last one in 3.4, but the first one is certainly fixed.

[eadocX Support]

What happens when you just define it as a ‘normal’ Related Attribute i.e. not using the ‘Advanced’ multi-hop relationship? I’m wondering if something is going wrong when you delete the second hop of what eaDocX thinks is a multi-hop relationship. I know, these should be the same….

[eadocX Support]

Would that it were so simple….
We could, or course, remove the extra lines which eaDocX deliberately adds after each table. But this would have some strange consequences.
If the next thing to be printed is also a table, then the two tables would be ‘glued’ together, which looks rubbish.
We have tried, many times, to ‘fix’ this one, but in the end it’s a compromise between creating a document which looks OK pretty much every time, and one which is perfect sometimes, and rubbish others. We’ve decided at the moment to go for the former, and yes, this does mean the occasional extra line.

[eadocX Support]

1) Allowing multi-hop relationships in the eaDocX Matrix Report is reasonable in principal. We’d use the same multi-hop definition as in the regular eaDocX, but we’d need to do some further changes, as the normal multi-hop will print data about the connection it finds: clearly where there are multiple hops, we can’t do this. So, not for 3.4, but first on he list for 3.4.1
– no chage of relationship matrix in eaXL. WAY too hard.

2) 3.4 will allow greatly increased function, using eaXL scripting….coming soon.
BTW- eaDocX development has now been offshored: to Wales!

[eadocX Support]

I’d not noticed this before, but you’re right – Windows seems to keep the position of the scroll bars from one display of the window to the next – clearly they’re trying to “help”. I’ll see if I can override the default, and make it scroll up to the top every time.
Thanks

[eadocX Support]

Ah – I see.
I designed it this way to look good when printing a short attribute value from each of the related elements. Then, a comma and a CR look sensible. In your case, it clearly doesn’t! Looks like you need a CR, LF, and no comma.
eaDocX does have an internal switch to determine which separator to use: CR+Comma for tables, just comma for Inline, but this isn’t a user setting.
If it was, it would be a document-wide or even an application-wide setting, and it would be hard to make it specific to each element type/stereotype.
The net of which is, I’m afraid I can’t offer any help…
…at least until 3.4, when you’ll be able to define you own EA Script to print that element type/stereotype, and then it’ll work just as you want.

[Author]

Posts