User Commands - where should they go?

Overview

By default Dyalog is looking for any User Commands in a sub folder Salt\Spice within the Dyalog installation folder.

Therefore the easiest way to get your own User Commands recognized and dealt with is putting them into that directory. Easy may it be but it also has a couple of serious disadvantages: messing up Dyalog scripts with your own scripts is not a good idea because ...

Dyalog might introduce a new User Command with a name already used by you.
When a new version of Dyalog arrives you are in trouble. Which shall go into the new version?

It's certainly a much better idea to keep Dyalog's User Commands separate from others.

Solution

To achieve that is not too difficult:

Create a folder somewhere which is going to host all your User Commands.
Add the folder to the SALT search path.

Of course the folder can have any name you like but in this document we refer to this folder as MyUserCommands\.

Complex User Commands

If the code which is the "real thing" is small it can and probably will go into the script which is defining the User Command as such. If it is a big thing (like ADOC) or a complete application (like Fire) than it will reside somewhere else.

Again it's not a good idea to put it into MyUserCommands\: name clashes and difficulties to tell User Command scripts from work horses are looming.

For that reason I am proposing to have another folder for hosting the "real thing" - let's call it MyUserCommandCode\. This name should go into the Windows Registry with the key name:

HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder

Of course you need to change the Dyalog version number to the version you are actually using.

$/!\$ Watch out: MyUserCommandCode\ must not be a sub-folder of MyUserCommands\. The reason is that Dyalog searches the folder recursively for User Commands!

Now your script need to honor this. There are two possibilities:

A Script

Your User Command script needs to find out where to find the workhorse. For this it needs a function which can read the Registry key. It then needs to read the script file and fix it.

For this you can use the ADOC User Command as a role model: it has two private methods, ReadRegKey and ReadUtf8File solving these two problems.

The Run method makes use of these two private methods:

∇ r←Run(Cmd Args);browser;cmdparser;cs;ref;⎕IO;⎕ML;path;regKey
      :Access Shared Public
      ⎕IO←⎕ML←1
      regKey←'HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
      path←ReadRegKey regKey
      path,←'\adoc.dyalog'
      ⎕FIX ReadUtf8File path
      ....

A workspace

Your User Command script needs to find out where to find the workspace hosting the application. For this it needs a function which can read the Registry key. It then needs to read the script file and fix it.

For this you can use the ScriptManager User Command as a role model: it has a private method ReadRegKey which is solving this problem.

The Run method makes use of this method:

∇ r←Run(Cmd Args);browser;cmdparser;cs;ref;⎕IO;⎕ML;path;regKey
      :Access Shared Public
      ⎕IO←⎕ML←1
      r←''
      regKey←'HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
      path←ReadRegKey regKey
      path,←'\ScriptManager.DWS'
     
      ref←⎕NS''
      ref.⎕CY path
      ref.ScriptManager.Run'' 
∇

Author: KaiJaeger

-  ⇤ ← Revision 22 as of 2011-08-05 08:42:07 → 
  Size: 3617
  Editor: KaiJaeger
  Comment:
+   ← Revision 26 as of 2015-02-03 17:06:05 → ⇥
  Size: 3788
  Editor: KaiJaeger
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 27:
-If the code which is the "real thing" is small it can and probably will go into the script which is defining the User Command as such. If it is a big thing (like [[ADOC]]) or a complete application (like ScriptManager) than it will reside somewhere else.
+If the code which is the "real thing" is small it can and probably will go into the script which is defining the User Command as such. If it is a big thing (like [[ADOC]]) or a complete application (like Fire) than it will reside somewhere else.
 Line 31:
-For that reason we are proposing to have another folder for hosting the "real thing" - let's call it `MyUserCommandCode\`. This name should go into the Windows Registry with the key name `HKEY_CURRENT_USER\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder`; of course you need to change the Dyalog version number to the version you are actually using.
+For that reason I am  proposing to have another folder for hosting the "real thing" - let's call it `MyUserCommandCode\`. This name should go into the Windows Registry with the key name:

`HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder`

Of course you need to change the Dyalog version number to the version you are actually using.

||<tablestyle="background:magenta; both; font-size:large;"> /!\ Watch out: `MyUserCommandCode\` '''must not''' be a sub-folder of `MyUserCommands\`. The reason is that Dyalog searches the folder '''''recursively''''' for User Commands! ||
-Line 39:
+Line 45:
-For this you can use the [[UserCommands/ADOC | ADOC User Command]] as a role model: it has two private methods, `ReadRegKey` and `ReadUtf8File` solving these two problems.
+For this you can use the [[UserCommands/Adoc | ADOC User Command]] as a role model: it has two private methods, `ReadRegKey` and `ReadUtf8File` solving these two problems.
-Line 47:
+Line 53:
-      regKey←'HKEY_CURRENT_USER\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
+      regKey←'HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
-Line 67:
+Line 73:
-      regKey←'HKEY_CURRENT_USER\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
+      regKey←'HKCU\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
-Line 82:
+Line 88:
-CategoryDyalogUserCommands