EMP Form Designer
(Beta 0.1.1 Released)

The EMP Form Designer is a visual form designer designed specifically for the purpose of being integrated into other software. It generates source code in any language you like. If the language you need source code generated for is not currently available, you can write a small XML file describing your language's source code to generate, and the EMP Form Designer will read the XML file to generate your code.

It is not meant to be an end solution, although for demo purposes I have created a simple application which shows the basic functionality of the designer. The software is being released under BSD-style license, i.e. do whatever you like with it, I am not liable for anything that may happen while you are using it.

It has been coded completely in Java using version 1.4. It has been designed using the Swing toolkit to take advantage of Swing Look and Feel. I envision this designer being used for development on multiple platforms, therefore using Swing would make it easier to give the end user native look and feel

A special version of the demo program uses Guillaume Desnoix's Simple Look and Feel (SLAF) package.

This project served as my theses for MSc in Software Systems. The theses I submitted for the project can be found here (4.78 MB PDF file).

Applicability of the project

Further work to be done

1. Adding a form modification listener: Currently when a modification is made on the form, the external application it is embedded into has no way of telling it. An external application might need to know about new modifications in order to prompt the end user to save the unsaved data before closing the application. By introducing a listener interface that listens to modifications made to the form, the application use the listener to get notifications of modifications.
   
   
2. Placement of a new widget: When creating a new widget, the user clicks on a widget button on the toolbar and the form designer places the new widget at coordinates (5,5) on the form. Normally this does not cause any problems but if a widget already exists at those coordinates, then the user has trouble moving the new widget into place. The form designer has to be modified to allow the user to choose the location of a new widget after the user has clicked on a widget button on the toolbar.
   
   
3. Cut, Copy, Paste functions: Almost all GUI programs feature an edit menu providing options for copying or cutting the currently selected item and paste it at a later time. Since the form designer does allow selection of widgets on a form, it is natural for an end user to assume that it also allows copy, cut and paste functions. These functions will need to be provided to increase the usability of the designer.
   
   
4. Retrieving interface settings: Currently there is no way of saving the GUI interface settings of the form designer’s interface elements, i.e. the location of the toolbar and the location of the split pane divider’s location. Every time the software turns on all elements are put back into the same default setting. The form designer will have to add some methods to its interface allowing outside applications to read the interface settings and set the interface settings.
   
   
5. Introducing if statements for code generation: When generating source code it was noticed that in certain situations a property of a widget might not be of any use in the source code depending on its value set by the end user. For example, if the user designs a form where the form does not have a value for the title, when generating the source code the title will be initialized using an empty string which is not needed. A mechanism should be introduced in the XML file that tells the form designer to not generate a section of the source code if certain criterion is not met.
   
   
6. Better method of specifying combo box and list items: Currently in order to specify items or choices in a combo box or list, the end user has to type out all the choices in a text field separating them by commas. This is a very inconvenient way of doing it. A better way would be to either display a popup dialog with detailed options for specifying the options or maybe use a text area instead of a text field to enter each value on a new line.
   
   
7. Better method for putting text for text area: The text used to initialize a text area is set by inserting it into a text field. A text field cannot be used to enter tab or new line characters. To fix the new line character problem a temporary mechanism was devised whereby the end user can enter //n into the text field and the form designer converts it into a new line character. This is highly inconvenient and unnatural to a computer user. By providing a small scrollable text area instead of a text field, this problem can easily be fixed.
   
   
8. Creating a Java Native Interface: Most of the editors and IDEs available in the market have been created using native languages like C/C++. Since the form designer has been created in Java it will be useless to majority of the potential developers out there. The Java Bean compliance does give it a certain amount of functionality to work with native programs, but this might not be what the developers are looking for. A Java Native Interface for the form designer will create a pure C/C++ based interface that will allow native program developers to integrate it using C/C++ code.