UpPreviousNext

Code Generation

The following sections describe the files generated by Builder Xcessory for each language.

C Code Generation

Builder Xcessory generates the following files (see Files generated for C for more information):

· main-c.c contains function calls necessary for any application.

· creation-c.c contains the code to initialize and create all widgets in the application.

· creation-c.h contains include information, constant definitions, and pixmap specifications.

· callbacks-c.c contains code for all callbacks specified.

· bxutils-c.c contains functions used by Builder Xcessory-generated code.

· makefile-c and Imakefile allow the generated code to be built into the application.

When using classes, Builder Xcessory generates the same files and adds some new ones. The differences are listed as follows:

· creation-c.c is the same for all widgets not part of a class. For each instance of a class, this file has a call to a function to create and initialize the widgets comprising that class. This results in a smaller file.

· creation-c.h also includes the <class>.h files for each class <class> that is generated.

· makefile-c and Imakefile contain the same targets, but include the additional class files to compile and link in to create the targets.

In addition, the following files are created for every class, <class>, created in Builder Xcessory:

· <class>.c contains the code to create and initialize the widgets comprising the class.

· <class>.h contains a data type that is a structure of the widget ID's of all widgets that are part of the class.

C++ Code Generation

If you do not have any classes when you generate the C++ code, the contents of each TopLevelShell are generated as a class and named using the instance name of the shell's immediate child.

In all cases, the following files are generated (see Files generated for C++ for more information):

· main-C.C contains function calls necessary for any application and calls the constructor of each generated top-level class.

· <class_name>.C contains the code for the constructor and destructor for each class generated. In the constructor, all the objects in the application are created (similar in C code to the creation-c.c file).

· <class_name>.h defines the class created by <class_name>.C and any required structures.

· UIComponent.C contains the base class for all objects created.

· UIComponent.h contains the definition of the UIComponent base class and any required structures.

· callbacks-C.C contains code for all callbacks specified on top-level shells and on other elements that are not specific class members.

· bxutils-C.C contains functions called in the other generated files.

· defs-C.h contains definitions of constants, pixmaps, and global instances of widgets or classes used in the application.

· makefile-C and Imakefile allow the generated code to be built into the application.

UIL Code Generation

Builder Xcessory generates the following files (see Files generated for UIL for more information):

· main-uil.c contains function calls necessary for any application.

· uil.uil contains a description of the widgets.

· callbacks-uil.c contains code for all callbacks specified.

· main-uil.h contains declarations of constants, and global instances of widgets or classes used in the interface.

· bxutils-uil.c contains functions used by Builder Xcessory code.

· makefile-uil and Imakefile allow the generated code to be built into the application. Imakefile specifies both UIL and C imake information. Makefile has targets for UIL as well as the associated C files.

· app-defaults includes all resources with app-defaults value set to App.

ViewKit Code Generation

Builder Xcessory divides ViewKit code generation into the following files (see Files generated for ViewKit for more information):

· main-vk.C contains function calls necessary for any application. VkApp is instantiated here along with other application level classes, such as your top-level window classes.

· <class_name>.C contains the code for the constructor and destructor for each class you created. In the constructor, all objects in the application are created (similar in C code to the creation-c.c file). The constructor also binds any callbacks assigned to widgets and contains the methods for those callbacks.

· <class_name>.h defines the class created by <class_name>.C and any structures that it needs.

· defs-vk.h contains the constants registered in your interface.

· callbacks-vk.C contains code for all callbacks specified on elements that are not specific class members.

· bxutils-vk.C contains functions for Builder Xcessory-generated code calls.

· makefile-vk and Imakefile allow the generated code to be built into the application.

Builder Xcessory automatically subclasses from VkWindow, VkSimpleWindow, and VkComponent as appropriate. Additionally, Builder Xcessory subclasses any classes you create from Motif widgets from VkComponent.

Java Code Generation

Builder Xcessory divides Java code generation into the following files (see Files generated for Java for more information):

· MainApp.java creates an instance of each top-level class in your program. If you have only one top-level class, you might not need to use this class. (This is similar to the C language file main.c .)

· MainApp.html is an HTML file in which your applet is embedded, or with which you can launch your application using the Java Virtual Machine in your browser.

· <class_name>.java contains the code for each class you created.

· Defs.java contains the constants registered in your interface.

· makefile-java allows the generated code to be built into the application or applet.


Note: All generated files have comments generated in the JavaDoc format.

Java application attributes

Builder Xcessory allows you to create Java applications or Java applets. Java applications have the following attributes:

· Contain a single main() method

· Execute in a stand-alone fashion

· Do not require a browser

Java applet attributes

A Java applet runs from a browser. Rather than having a single main() method, an applet implements a set of methods that control how it is initialized, drawn, handles events, and so forth. Java applets have the following attributes:

· Require a Java-enabled browser or applet viewer

· Must be embedded in an HTML page

· Typically subject to restrictions, depending upon the browser, due to security issues relating to the transfer of code


Note: Due to security restrictions present in most web browsers, many commonly used system methods, such as System.exit() cannot be used.
UpPreviousNext