Drag & drop? LOL!

I don't think I've ever used drag-n-drop to run a script, except once when Doc mentioned a problem and I tried it as part of the diagnosis. If I have a GUI script, the script is in my start menu. Non-GUI scripts (Kix, Bat, or otherwise) are run (exclusively) from the command line, never by double-clicking. Invoking a command line script from the GUI results in one of two crucial compromises - either you don't see the result/error message when the window closes, or you need to add a "press a key" mechanism. Unless you somehow build a timeout into the "press a key" process, that makes the script effectively useless for any form of unattended operation.

I never configure end-user systems this way to maintain security, but management and development systems have the following settings defined to allow direct execution of Kix scripts:

 Quote:
Kix32.exe is installed in a specific location in C:\Program Files, along with WKix32.exe. These are the latest versions (4.61). I also have these named Kix32_4.61.exe, and a copy of 4.53 named Kix32_4.53.exe (and the corresponding WKix32 files) in the same folder. 4.53 and 4.61 are the two most stable versions, but are incompatible when scripts are tokenized. Having these named this way allows me to invoke specific versions either for testing or backward compatability. This folder is added to the beginning of the system PATH variable.

I define the following extension associations:
.KIX Kix32.exe "%1" %* Kix Scripts (source or tokenized)
.KX Kix32.exe "%1" %* Kix Scripts (tokenized)
.KXW WKix32.exe "%1" %* Kix GUI Scripts (source or tokenized)
.K53 Kix32_4.53.exe "%1" %* Kix 4.53
.K61 Kix32_4.61.exe "%1" %* Kix 4.61
.K53w and .Kw61 are similarly associated with the WKix versions

All of these extensions are added to the PATHEXT variable.


I also define .UDF and .KXF associations to my editor, allowing direct access to UDF files. The content is the same, but we use .UDF to identify externally developed UDFs and .KXF to identify those developed internally.

Since the implementation of GetCommandLine, I never use BAT files to launch kix scripts anymore. The exception is KGEN.BAT, which is a hybrid script - the first 3 lines and the last line are BAT code that invokes Kix to run the actual kix script that is in lines 4 through 2122 - thus, one file that handles both the DOS prep and the Kix script commands. ;\)

Anyway, what all of this does for me is provide the ability to place my Kix scripts in the same folder as Kix32 executables. That folder is first in the PATH, writable only by admins. Thus, when I run a script - say LogCleanup.kix, I simply open a command prompt (actually, define a scheduled task) and run "LogCleanup --S:EventLog" to invoke the daily event log cleanup. It recognizes the .KIX extension as a command, and knows it's associated to Kix32.exe and launches it, passing the arguments. Likewise, the shortcut to tsAdm.kxw - the Task Scheduler Admin Tool - is simply "tsadm.kxw". I can invoke it from the command line simply as "tsadm".

No "kix32" or path statements, no .KIX extensions.. nice and clean. Very few of my scripts run outside of an administrative context.. no scripts are run by end users other than the login script, which is invoked explicitly - Kix32.exe kixtart.kix - so it runs anywhere. (remember, Netlogon is in the path during logon.) In the environments that I support, users are not local admins, so most of my kix scripts would be pointless for them.

I do have a couple of end user scripts, mostly to automate data collection or perform special reporting. In these rare situations, I do use a Bat file to invoke "@%S_BIN%\Kix32 "@%S_BIN%\script.kix", but it's the rare exception.

As an aside, the Customize package that can be downloaded from my web site performs all of these file associations, path updates, and related modifications, along with installing Kix executable, the KixForms DLL, and any additional tools you wish to deploy.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D