Since Visual LISP hasn’t added anything new to the world of DCL interfacing from LISP, this chapter will instead focus on how DCL can be used within VLX applications.
There are quite a few methods for dealing with callbacks from dialog forms. I am not going to preach any particular method to you. The methods shown herein are only my own habitual ways of working with DCL callbacks. If you have other preferences, please continue on your merry way unless you feel like changing habits now.
Referencing DCL Definitions
In the old days of AutoLISP, you had two files for any application that used a dialog form. You had the LSP file and the DCL file, and both had to be present and available to the user at runtime to execute the application successfully. With the new VLISP Application features, you can now compile the LSP and DCL source code files into a single VLX application file to provide to your users. This not only protects your source code somewhat, but it makes for easier deployment and maintenance, especially in a networked or distributed environment.
For example, in AutoLISP you might setup a LSP application to access the DCL source as follows (again, your style may be different. This is for example only):
(cond
( (setq dcfl (findfile “mydialog.dcl”)) (setq dcid (load_dialog dcfl))
You can still use this “legacy” code with only very minor changes to enable it to be compiled into a Visual LISP VLX application file. Simply remove the check for the file location and assume it is always there (because, when you compile it into the VLX it will be). You would only need to check for the form loading itself, which is already being done in the original code.
As you can see, it also shortens your code a bit. You can use this to help guide you in porting your older AutoLISP dialog form applications into Visual LISP VLX applications by referring to chapter 13 for how to build VLX applications.
Dynamic Dialog Interaction
A very common feature requirement in dialog-based applications is the need to have form features dynamically change in response to user interaction. Such things as changing an image or edit box values based upon selections in other parts of the form. Probably the most common is the need to enable or disable features based upon user selections.
The following example will step through how to make a dialog form that enables or disables certain features based upon selections in another part of the form. First, we’ll show the example dialog form definition:
// save as MyDialog.dcl
Now, we’ll see how to enable only one of the edit-boxes at a time, with respect to which of the radio-buttons are selected on the left-hand side of the form. To do this, we’ll define a few functions. The first will handle the dialog form and the call-backs using an
(action_tile) call-back for the radio_column “viewpoint”, which will receive the key-name of the radio button selection within its collection. Then we can use that key key-name to perform a conditional action using the other two functions to manipulate the other tiles.
;;; Save as MyDialog.lsp
(defun C:Myform ( / *error* dcid ok choice) (defun *error* (s)
(princ (strcat "\nError: " s)) (vl-bt)
(princ) )
(setq dcid (load_dialog "mydialog"))
( (new_dialog "myform" dcid); form name is case sensitive!
(set_tile "viewpoint" $MYFORM1)
(change-form $MYFORM1); initialize tiles using default value (action_tile "viewpoint" "(setq choice (change-form $value))") (action_tile "accept" "(setq ok 1)(done_dialog)")
(action_tile "cancel" "(setq ok 0)(done_dialog)") (start_dialog)
;;; apply tile mode changes in response to given tile to enable
(defun change-form (val)
;;; apply tile mode to list of tilenames
(defun mode-tiles (tiles mode)
(foreach tile tiles (mode_tile tile mode)) )
Now simply follow the steps in Chapter 13 to compile both of these source files into a single VLX application file and load it into your AutoCAD session. Type in MYFORM to run the command and see how the edit boxes react when you select the radio buttons.
Your dialog display should look something like this example image if you compile and load it correctly.
Controlling Images From Call-Backs
Now that we’ve seen how to enable and disable tiles from call-back values, let’s try going a tiny step farther and use this to change the slide image in a dialog form image tile. To demonstrate this, you should load the sample code slide files into a common folder and make sure the folder is in your default search path. Once we compile the VLX
application and load it, it will still need to find the .SLD files used for the image tile display. Unfortunately, VLISP doesn’t provide a means to compile slide files into the VLX as it does for DCL, DVB, INI and LSP files.
Let’s take the dialog form defined above and modify it slightly to add a single image_tile:
// save as MyDialog2.dcl
In order to properly control the image_tile, we should define a special function that takes care of finding the image file and adjusting scaling to suit the DCL configuration. You can load this example from MyDialog2.LSP in the sample files collection for this book.
If you look closely, you’ll notice that this function accepts either a SLD or SLB (slide-library) file, thereby making it possible to bundle your slides into a SLB and keep the total deployment down to just the VLX and SLB files.
(defun slide-show
(fill_image 0 0 xc yc 0) (if slb
(progn
(setq slb (vl-filename-base slb)) (setq sldnam (strcat slb "(" sld ")" )) )
(setq sldnam sld) )
(slide_image 0 0 xc yc sldnam) (end_image)
)
( T (alert "Slide image file not found...") ) )
)
Assuming that you use the provided slide files TOP.SLD, SIDE.SLD and FRONT.SLD and place them in a folder that is in the current default search path, you should be able to compile and load the MYDIALOG2.VLX and run it successfully.