Speaking of the manual, the KiXtart manual has pretty high information density. This means you won't find a 10,000 page manual that repeats itself dozens of times. Almost every key aspect of KiXtart is covered in a few pages before getting to the actual commands and functions, but it bears reading several times. I've used the language for a couple of years and I still find tidbits of useful information in the manual.

There are areas I'd like to see improved. For instance, I'd like to see more and better code examples in the HTML version of the manual. In programming practice, an example is worth a thousand words.

BTW, don't think you were just getting slammed by the suggestion to try your own examples. While there are some excellent coders here, keep in mind that no one cares about your code more than you do. Creating your own test code not only allows you to prove to yourself for certain how KiXtart behaves, but it helps you get more comfortable with creating good code.

I have a directory called 'test' where I try all my stupid KiXtart tricks. There are lots of junk files there, and occasionally I just delete gobs of files just to clean up. If any code in that directory becomes a project or a good example to keep, I move it to another directory.

I also created a batch file ks.bat in my path to run the executable, so all I have to do at the command line is type 'ks file' to test a kix script. Another shortcut batch file ue.bat allows me to edit that file in UltraEdit with the command 'ue file'. (I also have one for notepad.exe 'np.bat' and wordpad.exe 'wp.bat'. Basically, anything to shorten the edit-run loop will drastically improve your development time.

Another small tip is to put the HTML version of the help file on your desktop for quick reference.

I'm sure there are dozens of tips others could offer to speed/ease development, but I just thought you might find those useful.

New Mexico Mark