developer's mag
main page
article
part 1
part 2
part 3
part 4
part 5
part 6
6 - Future
The ebm Form Editor is designed to be open-ended - other objects are just a matter of creating new children classes, and adding handlers for them in the CFormGroup class and main form as needed.However, if the program was to be expanded greatly, it would benefit from being even more object oriented. Two annoying issues are the long case statements when creating an object - letting each class create an instance of themselves would eliminate the case, and improve maintenance. Likewise, the e_paramType values should probably be a class, with individual functions for loading, saving, verifying, and so on. This would make adding new type classes a little easier (for example, a new class for event handlers), but at the expense of memory.
Another area to explore would be changing the output of the form. Right now, the CFormGroup::ExportFile() currently outputs the class info in a C++ class source code format. By changing each class slightly, output could be in an entirely different format - such as byte code for another language. Originally, one goal of the editor was to output code for a BASIC compiler I was thinking of writing, allowing programmers to bypass the complexities of C++ entirely.
Finally, an interesting option is Linux. Borland Builder has a Linux equivalent called Kylix. In beta testing it, I was pleased to see how easily I could port Windows Builder code to Linux - often, with little more than a recompile. Since Borland offers the Kylix product in an open source (ie free) version, the port might be simply a matter of finding a small amount of free time - a commodity as valuable as it is rare.
In any case, the ebm Form editor has been a useful tool in my programming, and ultimately the goal of any tool is to be useful. My hope is the program has benefited others as well.
Previous Section