#Q 4.4-1) Do I need the project system? I already have a way of
organizing (eg, using tools such as defsystem) my source files for compiling and
loading. Is there any reason for me to switch to using the project system?
#Q 4.4-2) Why can't I create Common Graphics windows from my *common-lisp*
buffer in Emacs?
#Q 4.4-3) How do I not save prefs.cl when I exit the ide?
#Q 4.3-4) Sometimes when a run my project, I get mysterious redefinition
warnings. Why and should I worry about them?
A 4.1-1) The project system (new in Allegro CL 5.0 on Windows) was introduced as a way of helping users organize their files as they develop new applications with the Allegro CL 5.0 Interface Builder. The "File -> Build Project EXE" and "File -> Build Project Distribution" menu commands also use the project system by taking user defined projects and generating from them calls to the Allegro CL functions BUILD-LISP-IMAGE and GENERATE-APPLICATION respectively.
Since the project system is primarily oriented towards Allegro CL 5.0 Interface Builder applications, you may find you don't need to use the project system if you are porting an existing application, with its own way to load/compile source files, to Allegro CL 5.0.
Note that for Allegro CL 5.0 it is necessary to include runtime Common Graphics functionality in all applications built with the project system. Therefore, if you are not using Common Graphics, you can save space by not using the project system.
If you have been developing your Common Graphics application independently of the project system and would like to use the project system to generate standalone and deliverable versions, you can simply follow these steps to create a project encapsulating your application:
(1) Create a new project using the "File -> New Project" menu item.
(2) Bring up the Project Manager using the "View -> Project Manager" menu item.
(3) Delete the default form by clicking on the "formN" line in the "General" tab of the Project Manager and then clicking on the "delete" button (second from the left -- looks like an "X") of the Project Manager.
(4) Use the "add" button (first from the left -- looks like a "+") of the Project Manager to add as many source files as you wish to the project. Note that you may choose simply to add a single file which when loaded loads the rest of your application.
(5) In the "Options" tab of the Project Manager, you may wish to change the name, and initialization function for your project. In the "Advanced" tab, you may wish to deselect (if you don't need them) all of the "Build Includes" items >> except "cg" (which must always be included) << to suppress these Common Graphics modules from being loaded into your standalone.
To save the project, use "File -> Save All".
Q 4.4-2) Why can't I create Common Graphics windows from my *common-lisp* buffer in Emacs?
A 4.4-2) In order to handle events properly, all actions having to do with windows (creating them, displaying them, etc.) must take place within a single (Lisp) process. (On Windows, a Lisp process corresponds to an Operating System thread.) That process is the IDE/Common Graphics process and all interaction with windows (such as the debug window and editor windows) while Allegro CL is running is done within that process. The Emacs-Lisp interface, however, runs in another process. So an action such as creating a window (by, say, calling cg:make-window) cannot be done in Emacs since it would then occur in the incorrect process. You can edit common graphics code in emacs but to evaluate it, you cannot use emacs-lisp interface tools such as C-M-x. Instead, you must save the buffer to a file and load that file into Lisp using tools like the File | Load menu command.
Q 4.4-3) How do I not save prefs.cl when I exit the ide?
A 4.4-3) The idea of writing prefs.cl each time is to "remember" where you last placed your windows (as well as other settings) so that they will be "where you left them" the next time you start up.
If you do not want this behavior, as soon as you start up, toggle Tools | Save Options on Exit to off (unchecked). Then click Tools | Save Options Now. That will write a prefs.cl file with saving prefs.cl on exit disabled (meaning you do not have to toggle it off the next time you use the IDE).
Q 4.3-4) Sometimes when a run my project, I get mysterious redefinition warnings. Why and should I worry about them?
A 4-4.4) The warning likely looks like this:
Warning: FORM1-BUTTON4-ON-CHANGE, :OPERATOR was defined in EDITOR 1.unsaved and is now being defined in C:\Program Files\acl501\form1.cl
This warning occurred after placing a button on a form, displaying the Events tab of the Inspector for the button, and clicking on the extended editor button for the on-change event handler. (There is nothing special about buttons. The same behavior would be seen with any control with event handlers.) That generated code for the function FORM1-BUTTON4-ON-CHANGE, which you see in the form1 editor buffer. However, for system reasons it is first stored in a hidden buffer and evaluated (to ensure that the function is defined). When the definition is later read from the form1 buffer, a redefinition warning is signaled.
This is a minor design flaw. You will not get the warning if you display the form1 editor buffer before clicking on the on-change extended editor button. You do this by displaying the Project Manager, View | Project Manager, selecting form1 in the pane, and clicking on the View Selected Code button. Those actions cause a form1 buffer to be displayed in the Editor Workbook, making storing and evaluating the FORM1-BUTTON4-ON-CHANGE code in a hidden buffer unnecessary.
© Copyright 1998, Franz Inc., Berkeley, CA. All rights reserved.
$Revision: 1.1.2.8 $