Now to me, that seems like a lot of work compared to typing "scriptname" in a command prompt window. \:\)

I guess it is based on our development process, too.

We have a dev share on the network that is mapped to all users that do development. There is a KixLib folder in the root of that share that holds every one of our UDFs. Development of Kix scripts is done in a folder somewhere in that share. Large scripts are often broken into smaller pieces, with the header and var inits in SCRIPTNAME.TXT, and other components in .KXF files. When we're ready to build the script, we just run KGEN in that folder. It loads the SCRIPTNAME.TXT and all .KXF and .UDF files from that folder and then scan for external UDFs. Based on settings in the BUILD.INI file, KGen will tokenize the script and even copy it to one or more locations, run Sanity, and perform other tasks.

We can usually test the code right there in the dev folder. If it relies on other config files, we might have two command prompts open, one to the dev folder and one in the app folder. Up-Arrow and Enter to repeat the command for testing and we're done.

Then too, most of our Kix scripts are admin tools that run as system services or under the control of the task scheduler. A few are invoked manually, but its a small percentage compared to the other tools.

I'm not saying that one way is right or wrong, but if you never tried anything other than Drag-n-Drop or Double-Click methods, you might not ever realize some of the shortcomings of those methods, or be aware that Kix can run as a system service.

One case in point.. our LogCleanup script can run interactively, from the task scheduler, or as a system service. There's no difference between running it manually or from a scheduled event - both require an argument to define which cleanup task to perform. As a service, however, it is self contained. The cleanup config file not only defines the source and destination paths and other parameters, but defines the cycle in which to execute. The service mode "wakes up" every 60 seconds, checks if a task should be run, and dispatches a child process to perform the cleanup. All of this is in a single .KIX file. The point is, using methods other than the command prompt to launch scripts might mask some of the capabilities by limiting your imagination.

I am aware of several ways to launch Kix, and they are all in my arsenal for appropriate use. One of my favorite Kix scripts is KGen.bat. Yes, .BAT. Kix32 needed to be able to locate the script, assuming only that Kix32 would be in the PATH or current folder. Over 2100 lines of this BAT file are Kix code, with 4 lines of Batch commands:
 Code:
;@echo off
;kix32.exe "%~f0" %*
;Goto END
All the Kix code follows, except that the last line is ":END", which is valid for both DOS and KIX. The batch file can be placed anywhere as long as Kix32 is in the PATH. It could be a fixed location as well, but that creates consistency issues. The %~f0 represents the full path to the KGen.bat file, telling Kix32 exactly where the script is that should be run. All of the arguments are passed directly to the script.

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