Open Office Toolkit

[Francois Normandin]

Hi LAVAs,

I already picked the curiosity of some of you guys with this Open Office Report Generation toolkit.

So here is a snapshot of what's gonna be made accessible shortly through the Code Rep. But most importantly, I'd like to know what would be useful for the community. I'm having a design decision to make at the moment and I want to get people's opinions.

The toolkit will be based on AODL, a .NET API for Open Document Format. It's still in beta (v1.3) and includes only Text Documents and Spreadsheets, but it's a complete interface. It's a complicated API, but after spendig a few days poking around it, it's a quite simple mechanics.

I'm building this toolkit with LVOOP. For the moment, the "Basic" palette is taking form:

* Init Document

* List Styles

* Add Text

* Add Table

* Add Table of Content

* Add Image

* Save

* Load

* Dispose()

To be used somehow like this:

That's fairly straightforward. Where it gets a little more complicated is that I'd like to propose a true API to extract one part of a document and modify it. For that, each token that is constructed (Content of document) needs to be done by first creating the empty construct with the document reference as input. I haven't found a way yet to create content without first assigning a document reference. (i.e. I would like to find a way to create it with an empty reference and change that reference later on when I decide which document I want to add this content to.)

This constraint quickly adds a bad feel to the whole exercise... What a spaghetti!

So I might solve this problem by creating an active directory a FGV of current documents references (provided there are many) and each new content class (i.e. Create Empty Table) would be provided a Document Name to search the reference in the directory. This allow addition or modification of content in a State Machine. I can see why some people would not like this idea because it clearly breaks dataflow... but since the .NET API is by-reference, perhaps it's an acceptable compromise.

The final toolkit would include some Advanced palette to edit, insert before/after, include content inside other structures recursively, and the like. My initial tests with LVOOP indicate this could be quite versatile and expandable as the AODL (An Open Document Library) is extended.

Any thoughts on this? I'd like to hear your design advices as well as any requested features for the first draft.

PS: BTW, this AODL API is great. You can create reports without OpenOffice being istalled on the machine! I still haven't looked at the "Save as DOC file" yet, but it shows promises.

[crelf]

It might be nice if there were VIs in the API that mirrored those in the NI Report Generation Toolkit. Then it would be easier to migrate to an API that we can edit and expand as we need to.

[Ton Plomp]

It might be nice if there were VIs in the API that mirrored those in the NI Report Generation Toolkit. Then it would be easier to migrate to an API that we can edit and expand as we need to.

Or even better just superimpose them. I can somehow see that only the Report instanziation (spellcheck) has to be changed, but a new class OpenOfficeReport could override the Office Report Toolkit.

This would also limit the number of functions you need to create.

Ton

[crelf]

Or even better just superimpose them. I can somehow see that only the Report instanziation (spellcheck) has to be changed, but a new class OpenOfficeReport could override the Office Report Toolkit.

Now you're thinkin'!

[Francois Normandin]

Or even better just superimpose them. I can somehow see that only the Report instanziation (spellcheck) has to be changed, but a new class OpenOfficeReport could override the Office Report Toolkit.

This would also limit the number of functions you need to create.

Ton

I don't know why, but I missed your answers guys! I guess I should "track" my topics.

Thanks for the feedback. I indeed thought I could mirror the NI Report Generation VIs for the Basic Reports palette. The rest of the code would be hidden inside those to control individually cells, paragraphs and graphics. That's the approach I'll take for the first version. Building on that can be transparent for the end-user of the library.

Still, I found some bumps in the current implementation of the AODL 1.3 library. Its behavior is not polished to the point where it's as easy as OfficeReport. I'll try to document that a little.

[Francois Normandin]

Or even better just superimpose them. I can somehow see that only the Report instanziation (spellcheck) has to be changed, but a new class OpenOfficeReport could override the Office Report Toolkit.

This would also limit the number of functions you need to create.

Ton

On your advice, I checked the hierarchy of vi.lib/Utility/NiReport.llb and I will create two child classes "ooWriter" & "ooCalc" that will inherit from NI_report.lvclass.

It should then be only a matter of adding these two choices to the selector enum of "New Report.vi" and voilà. I think that's the spirit behind OOP, isn't it?

[Francois Normandin]

I should really have read your post earlier, Ton.

At least, I get to use your CCT 2.0. Great work.

BTW, the link to the "thank you" page needs to be refreshed (LAVA 1.0). If you can fix it, I'd pay my regards.

[Francois Normandin]

I've received a few PMs concerning this. Thanks all for waiting. The last few weeks, I've had less time than I would have wanted to continue this work and I am posting my preliminary work as is. There are a lot of holes in there, especially since I have not yet begun coding for the Spreadsheet Documents (Calc), only for Writer. Furthermore, the utility VIs like "Set Font" and "Save to File" should be much more "intelligent". As of today, use a correct OpenOffice filename with a ODT extension to save your work.

Remember that this is preliminary, but it makes use of the NI Report Generation Toolkit that handily comes coded in LVOOP. The "New Report.vi" VI is being replaced by one that can select ooWriter and ooCalc among others. The AODL libraries (DLLs) are installed in the vi.lib\Utility\NIReport.llb\ooWriter\AODL folder.

I have not yet touched all the power of playing with Cell contents, which will be necessary for upgrading to ooCalc eventually.

From now on, please use the discussion thread that was created with the submission in Code Rep for any comments on code or suggestions.

BTW, this is coded in LV 2009... but I don't see a problem in the future to downgrade the code to 8.2. I just don't have time for the moment to test it. (Please bear with me.)

Enjoy!