module layout

The framework uses a very simple scheme in communicating with the plug-ins. The rules have to be followed precisely, otherwise the system might either not accept a plug-in or show unexpected behaviour. The precise naming of the functions can be seen in the example plug-ins source. I will now only describe the general functionality required. It is probably easier to alter the example plug-ins then to create a new plug-in from scratch. There exist two different versions, however. These two versions have identical hooks when it comes to displaying their name, version and preferred locations. The difference lies in the actual processing hook. The more advanced plug-ins adds XML data using the MS XML API. Since plug-in developers might not want to use the MS XML parser a plug-in is also accepted if it listens to a second function, but not to the first. This second functions is expected to return a simple text string containing the xml data.

The framework starts by calling the simple text function. If this function returns an empty string or the NULL pointer, the more advanced XML enabled function is called.

It is completely up to the developer whether he wants to create XML enabled plug-ins. The main advantage for the developer is that he can view and alter the open database from within the plug-in and thus has more options than with the the text based plug-in. If this extra functionality is not needed I would suggest creating pure C++ text based plug-ins, since these are quicker to write, smaller in code and easier to port.