On the off-chance that somebody wants to wade through the Do178Builder code, here is a brief explanation of how it works. Fortunately, it's pretty simple.
I've grown tired of non-portable software, so I insist that Do178Builder work under both *NIX or MS-Windows. (When I wrote the previous line, I personally was using SuSE Linux on an iMac, which was then based on the PowerPC processor. I read an editorial in EETimes a couple of days after writing the line, which made it clear that nobody does this kind of thing. Then I felt shame.) To accomplish this level of portability, the wxWindows graphical toolkit is used to create the user interface. Other than the GUI, portability is achieved by using the GNU gcc compiler, which is available on a large number of computer platforms.
The wxWindows toolkit itself is available not only for MS-Windows and for *NIX (with either GTK+ or Motif), but also for Mac OS. (Since this was written, "wxWindows" has changed its name to "wxWidgets". But I'm not going to waste time rewriting my website for that.) Unfortunately, the Mac OS version requires the non-free (and non-cheap, relative to my interest in it) Metrowerks Code Warrior compiler rather than gcc, and hence I have not as yet produced a Mac OS version of Do178Builder. If/when wxWindows works with gcc on Mac OS, or when it can be compiled with inexpensive versions of Code Warrior, perhaps I will create a Mac OS version. If someone would like to do this and send it to me, I'll be glad to post it here.
I guess I should admit that this is the first non-trivial GUI project for which I've tried to use wxWindows, and it definitely has some rough edges to it. The main problem is that new major versions of wxWindows tend to break compatibility with earlier versions, so people complain to me that my program doesn't compile. But my other (non-portable) GUI projects with Borland C++Builder weren't that great either. Perhaps GUI isn't my cup of tea. But, that's life. Do178Builder is free. It's a learning experience. What can I say? If Do178Builder turns out to be useful for you, learn to look past the rough edges.
All other things being equal, I would prefer to use only free
tools for this project. However, for the sake of expedience, I've
used the non-free (though inexpensive) wxDesigner
tools for building the user interface. The wxDesigner data is
in the file Do178Builder.wdr. But unless changes to the user
are contemplated, it's not necessary to have either wxDesigner or
because wxDesigner generates
C++ code which can later be compiled with
and linked to wxWindows,
whether or not wxDesigner
itself is available. Important
update: With some Do178Builder
versions from 2005-06-21 and later, it was
necessary to manually add code to one of the files that was
originally auto-generated by wxDesigner;
therefore, it wasn't possible to use wxDesigner,
because its automatic
code-generation would overwrite these changes. Fortunately, I
seem to have fixed this problem somehow, and thus using wxDesigner is no longer a problem.
The result is a pretty run-of-the-mill event-driven program, much as one would see in Delphi, C++Builder, or with the GTK+ toolkit. Interacting with the user interface -- for example, clicking buttons with the mouse -- causes "events" which activate callback functions. Thus, after designing the user interface with wxDesigner, it's necessary merely to provide the proper callback functions to respond to events.
wxDesigner completely generates all C++ source code relevant to the GUI dialogs as the files Do178Builder_wdr.h and Do178Builder_wdr.cpp. These files should never be manually changed, since any changes will be overwritten if wxDesigner is used later to regenerate GUI code from the RAD environment. wxDesigner also partly creates the source files Do178Builder.h and Do178Builder.cpp, in the sense that it creates prototypes and stubs for new GUI objects in these files. However, the stub functions are then manually edited to create the callback functions for the user-interface events. Thus, quite a lot of user-interface code appears in Do178Builder.cpp. wxDesigner does not later overwrite this manually-created code.
The rationale for creating GUI dialogs with wxWindows generally results in creation of a C++ class for each type of dialog. To simplify the appearance of the code somewhat, I've separated code for some of the more-complex dialog classes from Do178Builder.cpp (where initially placed by wxDesigner) into their own source files. Thus, we have the files XmlEditorDialogClass.cpp and SearchBoxClass.cpp. The former is the main editing screen; the latter is for initiating text searches.
Finally, LoadXmlFile.cpp contains basically all of the non-GUI related code. Specifically, it contains the code for loading and saving the development data XML project files, and for writing DocBook SGML files
While Do178Builder definitely stores its project data in XML files, I freely admit to being an XML neophyte, and to have very little interest in advancing beyond that point. Even the little experience I've gained makes me realize that anyone with actual XML knowledge will look with disdain on my XML. Too bad; it works; it's too much trouble to change. Here are some basic points that will make it somewhat easier to understand:
All of this, of course, can render the new .template.xml incompatible with existing project data. This is not really a problem until one wishes to insert new data items into a project dataset, because the incompatibilities that have been introduced may make this impossible. The most insidious incompatibility that can be introduced is modification of the TYPE attribute. As mentioned above, each data item has an title (the XML tag name) and a TYPE attribute; these are initially the same, until the user edits the data-item's title. The TYPE attribute, however, is not similarly changed, and can therefore continues to correspond to what appears in .template.xml even though the title (tag name) does not.
But that's only if the Options/ModifyFramework function isn't being used. If Options/ModifyFramework is used, then Do178Builder can change the TYPE attribute of an item when the item's title is changed. In fact, Do178Builder prompts to see if this should be done. Generally, to achieve what you're trying to achieve in editing the framework, the TYPE attribute should be changed when the title is changed. But one needs to be aware that this modification of the TYPE attribute is the primary mechanism by which new DTDs become incompatible with old datasets.