Calling this a bug is really a misnomer, SET really a feature available for ACL.

 

 

There are many different ways that a person can have ACL configured on their computer.  Different people have different preferences that they like to have set up when working on ACL.  In many cases these options are cosmetic that have little or no impact on the execution of a script.  In some cases, the options can have a direct impact on how a script works.  For example, the SET EXACT command will determing if ABC = ABCD.  If SET EXACT ON, then ABC <> ABCD, but if SET EXACT OFF then ABC = ABCD.  This command option is one that some people may toggle between within scripts depending on the exact nature of the analysis they are performing.   There are scores of other commands such as SET SAFETY that people should be familiar with.  There are other settings (such as delete the data file when you delete a .fil) available only through the toolbar.

 

 

ACL assumes that if you make a change to a preference that you permanently want that change to be in place.  In many cases this is true.  If you want the default for SET EXACT to be ON/OFF, then you always want that setting established.  To this end, ACL will change the system settings based upon changes made via the toolbar or through the use of the various SET commands.  As the assumption is being made that a user always wants the same settings, the changes are not embedded within a particular project.  Similarly, as ACL does not require a login, the settings are not tied to the individual user.  Nor are they tied to a specific terminal/laptop/desktop computer.

 

The settings are preserved in a file that is maintained in the same folder where a project is stored.  This file is triggered when ACL is first opened up.  What this means is that if I have my ACL program stored at:

C:\ACL\Program

 

ACL will have a file preserving my SETTINGS at C:\ACL\Program.

 

If I have a project saved at C:\ACL\Program\Project, then ACL will have another file preserving my SETTINGS at C:\ACL\Program\Project.

 

If I have another project saved on a shared drive, then ACL will have another file preserving my SETTINGS on that shared drive tied to that particular project.

 

Now, if I open ACL up via the main program at C:\ACL\Program, then my project will be opened with the settings saved there.  If, however, I open ACL by clicking on the project at C:\ACL\Program\Project then the project will be opened with the settings saved there.  This can mean that I am running the project with different settings without realizing it.  Usually this does not matter, but on occassion it might.  For example, suppose I didn't realize that the SET EXACT option was turned on in one place but turned off in another?  This could produce very different results. 

 

If I later access a different project, which has different settings, it does not matter because the settings are determined when ACL is first accessed.

 

 

First, always access ACL in the same manner.  Most people suggest accessing it via the main program and then accessing individual projects via ACL after ACL is opened rather than clicking on a project icon.

 

Second, many of the commands can be SET within the scripts themselves.  Some commands such as SET ORDER, SET SAFETY, SET SUPPRESSXML, SET EXACT should become standard parts of the control/master script in any project.  This will ensure that the settings are what the programmer intended.  Using the SET command with no parameter will restore the system to the system defaults. 

 

 

I consider this a bug for two reasons.

 

First, while it is a design feature, if the user is unfamiliar with ACL then it can cause major problems in the execution of a script.

Second, there are a few SET options that can have a major impact to the way a script works that are not supported via a SET command.  The most notable being the option to DELETE the data table when you delete a .fil. 

 

Note: there is an unsupported command that will turn this option on and off.  That command is SET 39 0 or SET 39 1.  I spoke to a developer at ACL and he advised me not to use this command as it is an unpublished and thus not supported.  While it works, there is no guarantee that it will work in the future or that it has been fully tested.