|
Allegro CL version 8.0 |
Before proceeding through the tutorial, make sure that you have not opened or loaded the final version of the tutorial in the current IDE session (as you might have done, say, to see how the final project works). If the final tutorial has been loaded, you will get lot of redefinition warnings and there will be other problems. If you have loaded the final version (or indeed any version beyond where you are), simple restart the IDE (without reopening the tutorial project), and then proceed through the tutorial.
We suggest naming the directory gui-builder-tutorial, as shown, a subdirectory of the C:\allegro-projects\ on Windows and allegro-projects/ on Linux. (Choose any name and location you like, of course) In the documentation, we will assume you have chosen C:\allegro-projects\gui-builder-tutorial\ on Windows and allegro-projects/gui-builder-tutorial/ on Linux. A new project will be created and become the current project.
Because this is the first form we have created in this Lisp session, its initial name is form1. The form you create may have that name or perhaps form2 or formN for some other N. We will soon change its name so its initial name is not important.
The project file will be automatically saved to gui-builder-tutorial.lpr in the project directory. Save the form to doodler.cl (rather than form1.cl).
Note that order is Important in the Project Manager
The order you list files on the General tab is the load order for the files Lisp will use when running your project. The arrow keys on the Project Manager toolbar can help you change the order if you add them to the project incorrectly or want to rearrange them later.
- util.cl contains code for several utility functions for the application you are building. Youll need some of these functions soon.
- cycloid.cl contains the code for drawing the cycloidal curves in the application. Cycloidal curves are the multi-looped figures shown in the illustration of the final application in the Introduction
Here is what the Project Manager general tab should look like now:
You can inspect these files using the Project Manager. Click on a file name to select it and click the View Selected Code button
The file will be opened in the Editor.
Naming Objects
All windows and controls have names. As you begin to write the event handling code for these objects, you will use their names to refer to them.
Making Changes in the Inspector
The right-hand column of the inspector contains values. The left-hand column contains symbols, (in this case, names of properties). Make the changes requested in this step by clicking on each property's value field and typing a new value in its place. In some cases, you'll be offered a drop-down menu of choices when you click on the value, and you will be able to choose one from the menu.
The changes will commit when you hit ENTER or move the focus to a new location in the inspector. Notice that the title of the form changes. From here on we call it the Doodler form.
Package Statements
Youll see an (in-package :common-graphics-user) statement in the buffer. In-package statements need to be included in every form you build for Common Lisp applications. common-graphics-user is the default package for a project, and is the one that we are using for this tutorial. Projects in general may use that package or a custom package.
Working with Editor Buffers in the Workbook
Whenever you choose the View Selected Code button, you are placed in the Editor Workbook in a buffer named after the component you've selected from the Project Manager Dialog.
In this case, doodler is the buffer to display. The buffers all have names displayed on their tabs in the Workbook. Clicking on a tab displays the current code for the named component in a buffer. Once you've opened the Editor Workbook, you don't need to keep using the Project Manager dialog to display the current code.
(defclass doodler (non-refreshing-window) ())
Creating a New Class: doodler
This new doodler class inherits from non-refreshing-window, a class supplied with Allegro CL. non-refreshing-window determines the behavior of doodler. As the tutorial progresses you will add behaviors to doodler that distinguish it from non-refreshing-window.
Youve chosen a parent class for doodler that supports certain types of graphic displays. Well explain later on why there is an even better choice of a parent class for doodler, and show you how to revise it.
Dont Change Pre-Supplied Classes
First create a new class that inherits its behavior from a class which youd like to model, then change the behavior of the new class. You rely on the pre-supplied classes for certain standard behaviors; you dont want to change those. Changing pre-supplied classes is not supported.
There is a brief discussion of creating new classes and inheritance in Paul Grahams Chapter 11 of ANSI Common Lisp.
Mistake-proof Evaluations
The text cursor can also be placed after the last parenthesis. Putting it just after the expression makes the result completely unambiguous; youll never get a mistaken evaluation if you choose that location for your request.
The History List
If it evaluates properly, you will see the following display in the history list (the topmost frame, a drop-down combo box) of the Debug Window.
Protecting the dialog Class: changing the class property
Changing the class property is part of standard preparation for writing events and methods on doodler. We dont want changes we make to doodler to also be made to its parent class, dialog.
The class property prevents that. Once the doodlers class is changed from dialog to doodler, dialog is protected from changes.
See Don't Change Pre-Supplied Classes above.
Notice that you now have an empty window containing scrollbars as well as Maximize, Minimize, and Close buttons. The running form will have no grid pattern on it.
Copyright © 2001-2004 Franz Inc. All rights reserved.
|
Allegro CL version 8.0 |