Project Manager Build Tab

This tab on the Project Manager Dialog shows several options associated with building the application associated with the project. (Build an application with File | Build Project Executable, which builds a test version for use on your machine; or File | Build Project Distribution, which creates a directory of all files needed for the application, suitable for sending to another machine. See also build-project, which is a programmatic equivalent of the two menu commands. Be sure you are properly licensed before distributing an application to another machine.) Note the Help File widget, which has never been supported, has been removed in release 6.2.

The options are:

• Enable Debugging of Runtime Errors: if this option is checked (as it is by default), then the console window is available in the standalone application to allow debugging until the application is ready to ship. Aborting from an error in the console will re-enter an event-handling loop, allowing the application to continue running. If *show-console-on-standalone-error* is true, as it is by default, then the console will also appear automatically when an error is signaled and not trapped by the application. The application's icon will also appear in the system tray, which may be double-clicked to expose the console window if it does not appear for some reason on an error, or to expose it when no error has occurred. (If a standalone application stops responding entirely, it is a good idea to double-click the tray icon to see if there is an error in the console.)

  Note that it is the Franz Liszt icon that is displayed. The application icon specified by the Icon File option is not used in the system tray.

  When this option is selected, the symbol :allow-runtime-debug will be included in the build-flags of the project.

  We recommend leaving this option checked for debugging purposes until shortly before delivering an application, and then turning the option off for delivery, to shield the end user from the debugging console and tray icon as well as from the possibility of continuing to use the application after an unhandled error. When this option is turned off and an unhandled error is signaled in the delivered application, the project's default-error-handler-for-delivery function (see the Advanced tab) will be called, where the default function will show a simple dialog informing the user that an unhandled error has occurred and that the application will now exit. The lisp error string is included in the dialog, but the end user is not allowed to continue running the application in its broken state. To make a Common Graphics application handle errors more cleanly, an application should add its own signal handlers (such as calls to handler-bind) around code that could possibly signal an error.

  Note that it is the Franz Liszt icon that is displayed. The application icon specified by the Icon File option is not used in the system tray.

• Enable Debugging of Build Errors (console will not exit): if checked, the debugger will appear if an error occurs while generating the standalone application. This is implemented by passing the symbol :interactive as the build-debug keyword argument to generate-application. This allows debugging in the lisp that was generating the app, but also means that the console for that lisp will never exit, even when no build error occurs. Therefore, this option is not selected by default, and you would typically select it only if a build error has occurred, and then try again. When this option is selected, the symbol :allow-build-debug will be included in the build-flags of the project.
• Splash Bitmap: the filename of a bitmap file which will be displayed while the application is starting up. See splash-file.
• Icon File: the filename of an icon file (typically a .ico file) to be used for the application icon. If none is supplied, the Allegro CL icon (a bust of Franz Liszt) will be used. See icon-file.
• Kill the Splash Screen When the App is Ready: Whether to remove the standalone app's initial banner window as soon as the main window has appeared, to avoid making the end user wait any longer. See cg:kill-splash-screen-when-ready.
• Full Recompile for Runtime Conditionalizations in Project Code. This option is needed only if the project source code contains #-runtime-system or #+runtime-system reader conditionalizations to make the project behave somewhat differently when it is run as a standalone application than when it is run in the IDE. See full-recompile-for-runtime-conditionalizations. If checked, all project code will be recompiled with :runtime-system included on the *features* list before a project distribution is produced, as described on the full-recompile-for-runtime-conditionalizations page.
• Include a manifest File for Microsoft Visual Styles: if selected, the generated application for the project will have the newer "Visual Styles" look and feel on the Microsoft Windows platform. The illustration uses this new look and feel (it looks rather different from the illustrations of the other tabs of the Project Manager dialog). See ide:include-manifest-file-for-visual-styles and also a-visual-style-is-active.
• Runtime Option (to generate-application): generate-application must be called with a value specified for the runtime argument. The choices are :standard, :dynamic, and :partners (and these are the three values for this option). You must be licensed for whatever choice you make. See runtime.htm for details. See also runtime-build-option.

See the general description of the Project Manager Dialog for details of the toolbar buttons.

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