Page header when using DocumentGenerator

[KristoferG]

Hi!

I am generating a report using the DocumentGenerator class (a jscript), but I cannot figure out how to add a page header.

The code looks like this:

Code: [Select]

var docGenerator as EA.DocumentGenerator;
docGenerator = Repository.CreateDocumentGenerator();
docGenerator.NewDocument("LM Objekttypskatalog");      

var generationSuccess;
      
generationSuccess = docGenerator.DocumentDiagram(diagram.DiagramID, 0, "LM Objekttypskatalog - Diagram");

// some more code
docGenerator.DocumentCustomData(GetClass(currentElement.ElementID), 0, "LM Objekttypskatalog - Klass");

// and some more code

var saveSuccess;
saveSuccess = docGenerator.SaveDocument(OUTPUT_FILE, DOCUMENTATION_TYPE );

The template "LM Objekttypskatalog" contains a header, but none of the other templates (they are template fragments).

How do I add a page header to the generated document?

[Matthias Richter]

Anyone has a solution for this? I struggle with the same problem.

[Geert Bellekens]

I don't have a solution, but I don't see the need to use the DocumentGenerator class.

I'm working on really complex documents, and I managed to do it all using virtual documents.

(I do use scripting to create the virtual document and its model documents)

This approach has the added advantage that the user can review and adapt the virtual document before printing.

Geert

[Matthias Richter]

Thanks for your reply!
I started with virtual documents and looked for a possibility to start the documentation generation of my master document at the end of a data import/update script with the help of the DocumentGenerator class.

Is it possible to do that or call the Documentation Generator dialog with some presets?

I want to avoid that users have to search the master document and start the documentation generator dialog through the context menu.

Any help is appreciated!

[Geert Bellekens]

You could create the master document and its part as part of your import script.
And then at the end select the master document you just created in the project browser and show a message box saying "please press F8"

(if really needed you should even be able to simulate pressing F8 using sendkeys())

that is how I would probably do it.

Geert

[Matthias Richter]

I am not the  topic owner, but your answer works for me.

The page header of the master template is visible in the final report, if the Documentation Generation dialog is used to trigger report generation.

Code to open the Documentation Generation dialog:

Code: [Select]

Repository.ShowInProjectView(Repository.GetPackageByID(<master document package ID>));
var wshShell = new ActiveXObject("WScript.Shell");
wshShell.SendKeys("{F8}");
Thanks you very much!

[Uffe]

Hello,


In order to set header and/or footer in a DocumentGenerator-generated document, use DocumentGenerator.InsertLinkedDocument().

The linked document is passed as a string containing a GUID, which must resolve to an EA "linked document" (ie an RTF document stored in a «document» Artifact) present in the project where the generation takes place.

All you need to do is create such a document and edit its header and footer to your specifications. Since the document exists outside of the context of any document generation you can't include generation-time fields (such as element Name), but you can include generic fields like page number.

In your generation script, you simply pass the Artifact's GUID to the document generation right at the beginning.

Code: [Select]

var docGenerator as EA.DocumentGenerator;
docGenerator = Repository.CreateDocumentGenerator();
docGenerator.NewDocument("LM Objekttypskatalog");
docGenerator.InsterLinkedDocument("{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}");

var generationSuccess;
etc....
It's not the world's robustest solution, especially if you're working with MDG Technologies, but it works.

Cheers,


/Uffe

[KristoferG]

Thanks! That actually works!

The reason why I am using the DocumentGenerator class is that I want the user to be able to right click on a diagram in Project browser, and select to generate a report on that diagram. But, not the whole diagram, only some classes in that diagram based on its color in that diagram.

Any suggestions how to accomplish this without using the DocumentGenerator class, since it seems a little bit buggy (still can't figure out how to set the page format and scale the image to fit that page)?

/Kristofer

[Uffe]

I don't see how you could do that without scripting it (that is, using DocumentGenerator).

The reason is that while there are all sorts of weird and wonderful things you can do with RTF template fragments, virtual documents and even filters in the Generate Documentation dialog, they are all based on the actual underlying model elements -- within the context of document generation, there's no way to retrieve the colour of an element in a specific diagram.

A script on the other hand, and as I'm sure you're already aware, is perfectly capable of checking the graphical attributes of a diagram object and based on that decide whether to include the element in the document.

This is part of the reason I always advise against using colours as information carriers in models. It's better to create a stereotype with a shape script which sets the colour according to some criteria such as element Status or your own tagged values. That way, the colour is a consequence of an attribute which is stored in the element and which can be checked in places like document templates.

WRT page format, I think you can set that with SetStyleSheetDocument(), but I'm not sure. It's always good practice to make sure all the templates are consistent anyway; the whole process is a little quirky and you sometimes find that formats from one template propagate backwards towards the start of the document and things like that.

Image scaling I think you can only set in the diagram properties, but again, not certain.


/Uffe

[KristoferG]

We are using the color to indicate that in this particular diagram, the class is not really part of that model, and are defined elsewhere. So the class has different colors in different diagrams, hence the DiagramObject carries the information, and not the class element.

The DocumentGenerator class does not properly (or i can't understand it) work with scaling and page format. If I use the Generate Documentation (F8) it works fine.

It also seems that when I use the DocumentGenerator class, I cannot omit rows (table row with label and custom field) in the template that are empty. According to the documentation, a bookmark with .Begin and .End should do what I want, but I can't get it to work when I call DocumentCustomData(...) with my template.

Code: [Select]

docGenerator.DocumentCustomData(GetClass(currentElement.ElementID), 0, "LM Objekttypskatalog - Klass");


/Kristofer

[Geert Bellekens]

Thanks! That actually works!

The reason why I am using the DocumentGenerator class is that I want the user to be able to right click on a diagram in Project browser, and select to generate a report on that diagram. But, not the whole diagram, only some classes in that diagram based on its color in that diagram.

Any suggestions how to accomplish this without using the DocumentGenerator class, since it seems a little bit buggy (still can't figure out how to set the page format and scale the image to fit that page)?

/Kristofer

That is exactly what I do for this client. (except for the color bit).
I have one document that is started from a diagram script.
It will report all use cases that are within the boundary.
But not only the use cases appear on the document, also things like the related requirements, the application function related to those requirements, the Business processes related to those requirements etc..

My script creates the virtual document and all the model documents. Often I use an SQL search called "searchElementByGUID" to define the contents of that document section.
The elements guid is than added as parameter.
All of this is created in a script. A typical document can easily contain 50 different Model documents, each for a different element, or some even for the same element but with a different template.

Creating a document this way is a two-step process.
1) run the script to create the virtual document
2) Generate the document manually (F8).

The advantages is that there is also room between step 1) and step 2) to review the contents of the document, and change or reorder it where required.

Geert