Differences between revisions 21 and 22
Revision 21 as of 2011-08-05 08:05:32
Size: 2837
Editor: KaiJaeger
Comment:
Revision 22 as of 2011-08-05 08:42:07
Size: 3617
Editor: KaiJaeger
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was copied from UserCommands/Adoc
= User Command ADOC =
<<TableOfContents>>

= User Commands - where should they go? =
Line 4: Line 6:
[[ADOC]] is a utility useful to generate documentation (semi-) automatically from class scripts as well as namespace scripts.
Line 6: Line 7:
Obviously it makes sense to make ADOC's services available as a User Command. By default Dyalog is looking for any User Commands in a sub folder `Salt\Spice` within the Dyalog installation folder.
Line 8: Line 9:
This page offers a small class script `ADOC` which is designed to do exactly that. 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 ...
Line 10: Line 11:
== Assumptions ==
When User Commands got introduced in Dyalog with version 12.1, the User Commands where expected to reside in a sub folder `Salt\Spice` inside the Dyalog installation folder. This means that the script `ADOC.dyalog` attached to this page must go into this directory. Only then the User Commd "ADOC" is recognized. Note that this script only deal with two issues:
 * 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.
Line 13: Line 16:
 * Figure out what command the user want to invoke, "Browse" or "List".
 * Find the real work horse and call it, see below.
== Solution ==
Line 16: Line 18:
That script which represents the ADOC User Command assumes that there is a sibling folder of your APL installation folder available named `UserCommands`. Please make sure that the real [[ADOC]] script is copied into this folder `UserCommands`. This enables the User Command script to address the real ADOC script `{MyDyalogInstallationFolder}..\UserCommands\ADOC`. To achieve that is not too difficult:
Line 18: Line 20:
For example, in case your version of Dyalog APL 32bit is installed in `C:\Program Files (x86)\Dyalog\Dyalog APL 12.1 Unicode` which is the default on Windows 7 64 bit, then the folder `UserCommands` is supposed to be located at `C:\Program Files (x86)\Dyalog\UserCommands`.  1. Create a folder somewhere which is going to host all your User Commands.
 1. Add the folder to the SALT search path.
Line 20: Line 23:
== Samples ==
Given that the two different ADOC scripts went into the right folders, this would be a sample session:
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 ScriptManager) 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 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.

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 [[UserCommands/ADOC | 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:
Line 24: Line 44:
      ]?ADOC
"??" for general help, "?CMD" for more specific info on command CMD

 Group Name Description
 ===== ==== ===========
 ADOC ADOC.Browse Creates full documentation and displayes it in the default browser.
        ADOC.HELP Displays help regarding ADOC.
        ADOC.List Prints syntax of all public stuff to the session.

      ]?ADOC.Browse
Command "ADOC.Browse". Syntax: 1 arguments; accepts switches -b=
Script location: ........\....\....\ADOC

Gathers information from a class script, compiles
an HTML page with these pieces of information
and displays it in your default browser.

      ]?ADOC.List
Command "ADOC.List".
Script location: ........\...\...\ADOC

Prints a list with all sorts of information to the session
about all public stuff given in the script specified in the right argument

]ADOC.Help
Watch your browser

Shows extensive information about ADOC. It's basically doing `ADOC.Browse ADOC`.
∇ r←Run(Cmd Args);browser;cmdparser;cs;ref;⎕IO;⎕ML;path;regKey
      :Access Shared Public
      ⎕IO←⎕ML←1
      regKey←'HKEY_CURRENT_USER\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
      path←ReadRegKey regKey
      path,←'\adoc.dyalog'
      ⎕FIX ReadUtf8File path
      ....
Line 54: Line 54:
== Download == === A workspace ===
Line 56: Line 56:
[[attachment:ADOC_UC.zip | Download]] the script. 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.
Line 58: Line 58:
== Version ==
The script is version 1.2.0 from 2011-08-04
For this you can use the [[UserCommands/ScriptManager | 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←'HKEY_CURRENT_USER\Software\Dyalog\Dyalog APL/W 12.1 Unicode\SALT\CodeFolder'
      path←ReadRegKey regKey
      path,←'\ScriptManager.DWS'
     
      ref←⎕NS''
      ref.⎕CY path
      ref.ScriptManager.Run''

}}}

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:

  1. Create a folder somewhere which is going to host all your User Commands.
  2. 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 ScriptManager) 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 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.

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←'HKEY_CURRENT_USER\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←'HKEY_CURRENT_USER\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


CategoryDyalogUserCommands

UserCommands/WhereShouldTheyGo (last edited 2019-05-30 09:04:34 by KaiJaeger)