Phillip Khaiat

[Phillip Khaiat]

Have you also added any entries using the Project | Glossary (Alt-2) option?

[Phillip Khaiat]

Have you tried generating the glossary section by itself, after generating the whole document?

[Phillip Khaiat]

Have now written scripts to handle both of these tag value types

[Phillip Khaiat]

If you do it carefully, you can rename a file by:

1. Ensuring the document is not open in eaDocX or Word

Renaming the file on disk

3. Opening the Document details window by double-clicking on the «eaDocXDocument» element
4. Linking the Version(s) in the versions tab to the new file(s)

Not guaranteed to work under all circumstances, but should be worth a try.

[Phillip Khaiat]

You can – edit the Document History profile and sort the version column

[Phillip Khaiat]

If you select Editing | Find | Advanced Find you can search your Word document within eaDocX. No idea why Find/-F doesn’t work in there.

[Phillip Khaiat]

In the eaDocX repository settings, there is an option to specify the EA package for DM document data. That is the (default) package where you will find the eaDocX DM elements.
You can also just search your repository, looking for Artifact elements with stereotype eaDocXDocument

[Phillip Khaiat]

The version history is not lost, it is in DocumentVersion child elements of the original Document element, which is in the default document management folder. When you re-enable DM for the document, you will have a new document element. Just move the old DocumentVersion children under it (replacing the new 0.0.1 child), and all of your versions should be restored. You can also copy the document abstract from the old to the new element.

[Phillip Khaiat]

RTF does it by treating the «package» attributes of model documents as links within the model, and updating their GUIDs as part of the connector clean-up process during import. (Sparx used to treat the package names as links, which did not work very well). I can think of a couple of ways in which eaDocX could piggy-back on this process: make the «eaDocXDocument» element an extension of the RTF model document, and add all of the links to packages currently stored as GUIDs in the XML as «package» attributes to them. If that element is imported as part of a package tree using the Strip GUIDs option, Sparx will update all of the GUIDs, giving you an element containing a set of named packages with updated GUIDs, and allowing you to build an “update links” function for an eaDocX document. You could also do the same kind of thing by using connectors between an «eaDocXDocument» element and the packages included in the document, although I think that this would be a less elegant solution.
I understand that this is not a simple feature to build, which is why I would be happy to settle for a simple macro allowing me to manually replace one set of GUIDs with another in the document XML for now.

[Phillip Khaiat]

You have the right idea. Think of the package tree as an EA Base Project. Its structure will be used as a staring point for new projects, all of which are required to produce the same set of documents from the same package tree structure. Using the RTF generator, I would include all of the virtual documents in the Base Project package tree. When the Base Project is imported, stripping GUIDs, the new RTF model documents will have all of their links updated to point to the new packages, giving me a cloned project with a cloned set of reports (we have 12 documents right now). I want to be able to create a new set of eaDocX documents that pull their content from a newly cloned base project in the same way. That would include the Element and Matrix Reports.
I like the new reporting from model views feature, but can’t see how I could use it to do this very easily without creating a new set of views for each cloned project package. Some of our documents refer to about 20 packages, so I would hate to break the direct link between package content and document, which is one of the attractive features of eaDocX.
To use your example, what I want is:

1. start with a document which refers to Packages (#1, #2, #3)
2. export those packages, & import them stripping GUIDs to get Packages #4,#5 and #6
3. easily clone the original document to get a new one referring to Packages #4,#5 and #6

[Phillip Khaiat]

Just tried again: both report definitions appear in the profile, but the one with custom format options gets copied over as “Use defaults for element type”, so I basically only have 1 report using the default stereotype profile.

[Phillip Khaiat]

Yes (first thing I tried). It doesn’t work because there are 2 custom reports: 1 using the default element layout, & the 2nd with a custom layout. Only the 1st gets copied (sort of). I can send you the example if you want.

[Phillip Khaiat]

Not a bad idea, but sounds a bit tricky to implement, & overlaps with Baseline Compare and Word Compare functions.
A small enhancement I would like to see is the ability to attach document roles to specific versions of a document. I have been manually adding the relationships, but reporting is a bit tricky.

[Author]

Posts