Birds Project Developer Information

Bird Man, a painting by artist Lynn Rothan

An Open Call for DERs

When certification documentation for actual deployable airborne software becomes available, the assistance of a DER would be very welcome. The idea would be for the documentation to be pre-inspected, so that 8110 forms could be signed on demand later for a fixed fee. Imagine your name here:

Do178Builder Developer Information

There are plenty of things that could be achieved by additional software developers for Do178Builder. Write me an email, and I'll make some suggestions. Speaking for myself, Do178Builder works well enough, so in spite of having a fairly large wish-list I don't feel very inclined to spend a lot more effort on it. But if you want to email me bug reports, suggestions, or code patches, I would certainly be grateful for them.

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.

Disclaimer

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 stored in the file Do178Builder.wdr. But unless changes to the user interface are contemplated, it's not necessary to have either wxDesigner or Do178Builder.wdr, because wxDesigner generates C++ code which can later be compiled with gcc 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.

Source files

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

Concerning XML

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:

I've discovered somewhat belatedly (over 6 years after I started the project), that the Do178Builder XML project databases are not actually legal XML, although many XML-enabled editors are insensitive to the problems and so you don't really have to confront them unless using a standards-compliant XML processor such as libxml. There are at least two problems with the "XML":

Do178Builder sometimes embeds character entities such as "," in the names of tags. However, legal tag names cannot contain the characters '&', '#', or ';'.
Do178Builder allows tag names to begin with a digit, which is not legal.
When I need to convert a Do178Builder XML database to a legal XML file, what I do is to replace all strings "&#NN;" (where NN is a decimal number) by "_rNNr_", and all strings "<N" or "</N" by "_N_" or "/_N_". This can be done with the sed program, which is always available in *NIX systems, or can be installed for Windows systems. A command for accomplishing the conversion is:

sed "s/&#\([0-9][0-9]\);/_r\1r_/g" <InFile.xml | sed "s/<\([0-9]\)/<_\1_/g" | sed "s/<\/\([0-9]\)/<\/_\1_/g" >OutFile.xml

This conversion is completely reversable, except in the unlikely case that your file really contains strings like "_rNNr_", "<_N_", or "</_N_", using similar types of sed commands.

There's no DTD. There is a file (hidden, if you're using *NIX) called ".template.xml" that is a fully-fleshed out project file except that there's no non-trivial data in it. It serves the purpose of a DTD.
Each project XML file is completely self-contained, except for graphic images. In other words, it contains all of the information from .template.xml (except that which has been deliberately deleted by the user), and hence does not require the presence of .template.xml (or consistency with .template.xml) to be read at a later time.
In fact, .template.xml is really needed merely for determining the validity of insertion or deletion of items to the database.
For DO-254 projects, the file .template254.xml is used in place of .template.xml.
The project data is arranged in hierarchical outline format, in which item has a parent and (possibly) children, which may themselves have children, and so forth. Obviously, this is precisely suitable for XML. I use the titles of the outline items as XML tags for them, with all spaces replaced by underlines, and non-alphanumeric characters replaced by suitable escape sequences. These titles are editable by the user, and so each tag has a TYPE attribute that cannot be edited, but which to which the titles default. In hindsight, this is a foolish scheme, and the roles of the tags and TYPE attributes should have been reversed. Too bad.
Additional attributes for the tags are the HINT, the applicable DO-178B documents (PSAC, SAS, etc., all defaulting to "NO"), and the control categories BA, BB, BC, BD, and BE. As with the tags, all whitespace in these is replaced by underlines, and escape sequences replace various characters (such as '<'). There is no necessity for eliminating the whitespace in this way, but it made parsing the XML file a little easier.

At this writing, the DTD is still being tuned. (I speak of the "DTD" figuratively, of course, since there isn't one.) The easiest way to edit the DTD is to load .template.xml itself as a project file into Do178Builder. Under the Do178Builder main menu, the Options/ModifyFramework function should be chosen. Now when the dataset (.template.xml) is edited, it is possible to edit the variout attributes as well as the XML tags and data. Specifically, the hint, the applicable documents, and the control categories become editable. Furthermore, new outline items and sub-items can be added at will.

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.

This page was last modified by Ron Burkey on 2008-03-16.. Contact birds .