EA table t_document and unused fields

[fwoolz]

The table t_document in the EA database has two fields for document content, StrContent (a Memo field in Access) and BinContent (an OleObject field in Access). From what I can tell, EA uses the BinContent field exclusively to store linked documents but ignores the StrContent field completely. There is also a 255 character text field for document notes (t_document.Notes) that doesn't seem to be used. In addition to this, several fields in t_object, particularly Header1, Header2, GenOption and GenLinks (all memo fields) would seem to be available for Requirement elements since these all relate to code generation, something that doesn't apply to Requirement objects.

I'm also looking for a simple way to store an XML file (containing customized requirement revision history records) in either a document element linked to a requirements element or in the requirements element itself without having EA turn all '<' and '>' characters into '&lt;' and '&gt;' (as would be the case with the element Notes field) or adding an RTF header and control codes to it (as would be the case with a linked document). Yes, there are ways to get back the original XML, but this seems like a clunky, inelegant solution. So my questions are:

1. Do Sparx have plans for the StrContent field in the foreseeable future, or would they be willing to allow this field to be used for application-specific plain text objects?

2. Would Sparx consider allowing custom row entries in t_document provided that the rules regarding EA's use of the table were followed? This would allow arbitrary BLOB content (such as images, Autocad DXF or DWG files, PDF files, etc.) to be stored as element attachments WITHIN the database rather than as linked files. This encapsulation is important for cases where a distributed team is working on a project but not everyone necessarily has access to the linked files.

Note that I've tinkered with custom row entries (along with multiple linked document entries) in t_document and EA seems to get along quite nicely with them (it does, however, seem to ignore all but the first linked document for a given element).

3. Are there any reasons why the listed fields in t_object shouldn't be used for custom plain text data in Requirement elements?

4. Would Sparx consider adding improved Automation Interface support for the listed fields in t_document (and for the more obscure fields in t_object while they're at it)? For starters, it would be good to be able to load linked document RTF directly from a string rather than only from a file.

5. As an alternative (or additionally - even better) would Sparx consider adding an option (checkbox in the UI) to treat the element Notes field as plain rather than Rich Text? This would allow the field to be used for XML, HTML, and other markup without it being mangled by the HTML-lite parser used by EA. This probably means another database hack (maybe to StyleEx or something similar?), but it seems eminently do-able.

6. As a side issue, what format does EA use to store RTF files? Is it compressed (e.g. Zipped)?

Cheers,
Fred Woolsey

[Geert Bellekens]

Whoa Fred,

Thats a lot of questions

Of course I can't answer these, but I do have some experience with xml content in the notes tags.
In our method we use xml tags to differentiate different parts of the notes. (don't ask, before my time )
So the contents of the notes look a bit like this:
<Definition>
text...
</Definition>
<Description>
text...
</Description> etc...

I wrote an addin to give the users a sane way to edit the notes (without having to manually type the tags) but keeping the Rich Text features intact.

Although it wasn't easy I managed to keep both the formatting tags out of the xml structure, and the xml structure out of the formatting tags of EA.

To summarize what the addin does each time a notes field is edited

• Have EA format the notes as RTF and back to TEXT to compensate for pre-7.1 notes (where the < and > were not escaped yet)
• replace all < and > characters in the notes by something else (I use "[ch9787]" and "[ch9829]" because they are probably not used)
• use a cunning regular expression to replace the &lt; and &gt; with < and > again (but only if they contain a tag I defined)
• enclose everything in a root node (because xml stuff will complain if you don't have a single root node)
• Use HtmlAgilityPack.HtmlDocument to load the cleaned up notes. (because this is much more forgiving then a standard xml parser)
• Save the HtmlDocument as XML
• Use another cunning regex to replace the html entities with their xml counterpart ("&amp;rdquo;" becomes "&" + "#8221;")
• Format the contents of the different xml tags individually to RTF (Repository.GetFormatFromField)
• (Finally) load the RTF contents of the different xml tags into my GUI RichTextBoxes.

Saving back to EA follows more or less the same steps in the opposite direction.

Seeing this now I think I could have skipped a few steps by using a HtmlDocument directly in my GUI rather then persisting on converting the whole thing to an xml structure.

To conclude, it is possible, but there is quite some work involved to get it working.

Geert

[fwoolz]

Cheers Geert,

I've done some messing around with using a WebBrowser and HtmlDocument in my GUI as well (for handling Rich Text in notes - different issue from the XML one), but found that it was necessary to get down to the unmanaged component level to get what I needed out of it. This proved to be a royal pain, plus the WebBrowser is a resource hog and seemed a bit like using high explosives to kill a fly. I even cobbled together a limited HTML<->RTF parser so I could use a RichTextBox in the GUI, but again it seemed like more work than it was worth.

It's very tempting to expropriate   some of those Memo fields that just seem to be lying around, but as you pointed out in an earlier post, this isn't a good idea unless blessed by Sparx since they may make use of them at some point in the future or make a backend change that breaks either EA, the add-in, or both!

I'll take Neil's earlier advice, I think, and post the questions as a support request as well.

Thanks again,
Fred