New Form

This dialog is displayed by the File | New Form menu command. It creates a new form window for interactively laying out the widgets of an application window. A name for the new application window may be specified here (see name), along with the window class that will be instantiated for it (see device).

A form window must be part of a project. If there is no current project, then the New Form command will instruct you to first use the File | New Project command or the File | Open Project command.

The Window Name

The first widget on the New Form dialog is for the name of the new application window. This is a symbol by which the window may be found with functions such as find-window and find-application-window. A keyword is recommended to avoid package considerations. This name will also be the suggested filename for the form when you save the form for the first time.

The name is also used to name the finder-function and maker-function that are automatically generated for creating the form's window. For example, if the form name is my-main-window, then a finder-function named my-main-window and a maker-function named make-my-main-window will be generated, and may be called by your application code to find and/or make the window.

So it is a good idea to initially assign a useful name for the new form, though you can also use the inspector to change the name property of the form at any time. The finder-function and maker-function will then be named according to the new form name the next time the form is saved.

The Window Class

The other two widgets on the New Form dialog are for the class to instantiate to create the application window. The list widget at the left includes a set of built-in instantiable window classes, plus any subclasses of these classes that you have already defined. The class that is selected here will be the class of the application window if no new subclass name is entered in the widget to the right, and otherwise will be the direct superclass of the new subclass that is created.

A symbol to name a new subclass for this application window may optionally be entered into the widget at the lower right. If a name is entered, then a defclass form is automatically generated and evaluated to define a subclass with this name, with the class selected from the list to the left as a direct superclass. It may be desirable to define a subclass for each application window, so that methods that are specific to it may be written.

Creating the Form

When the new form is created, a form window will appear, allowing you to place widgets onto it from the Components Toolbar. An inspector will also appear for a new form if no inspector was already present. To place a widget onto a form, just click a button in the Components Toolbar for the desired type of widget, and then click in the form window to place it there. Left-click a widget on the form to edit its properties in the Inspector (double-clicking also exposes the Inspector).

Creating a new form will also create a new editor buffer into which you can write source code related to this application window. If you have requested a new subclass for the window, then the generated defclass expression for the new class will be written into this editor buffer, and you can modify it anytime later to add slots and so on. Additional source code will be generated into this buffer if you use the inspector to create event-handler starter functions for widgets on the form; this is done while inspecting a widget by clicking on the small button beside an event-handler property on the Events tab of the Inspector.

Saving the Form

You can save a form by using the File | Save command whenever either the form window itself or its associated editor buffer is selected. This saves the editor buffer for the form (if present) to its .cl file, and also generates a file with the same name except for a file type of .bil; this generated file contains code for creating the application window with the widgets that you have laid out interactively (see maker-function).

User-written code associated with a form does not have to be placed into the suggested .cl file, but doing so helps keep the code organization tidy. In particular, a form's .cl file is loaded just before its .bil file, and having the defclass expression for a form in the .cl file ensures that it is loaded before it is used by the .bil file.

Copyright (c) 1998-2019, Franz Inc. Oakland, CA., USA. All rights reserved.
This page was not revised from the 9.0 page.
Created 2015.5.21.