Quote:

I'm not trying to put words in your mouth, I just don't understand how some duplicated functionality is OK and the rest is not.



There is probably very little duplication in fact. KiXtart will be calling existing Windows APIs to do the work. Most of the code in the interpreter will be handling parsing and management of KiXtarts own resources.

To take an example mentioned earlier, there is no code in the KiXtart interpreter to manipulate INI files. There is code to interpret the Read/WriteProfileString() function and pass the parameters off to the corresponding API.

Quote:

The real value of KiXtart to me has always been that it contains core functionality that reduces my need for COM reliance.



Yes and no. COM is a way of exposing APIs and objects such that they can be used in scripts. Adding a wrapper function in KiXtart may do the same thing, but you are still reliant on XMLDOM support and in addition you need to build the object management into the interpreter.

Quote:

If the evolution of KiXtart is moving towards tighter COM integration with nothing new added to the core language then I would say it has no real benefit over VBScript.


Not at all. Both KiXtart and VBScript provide access to COM, however the underlying languages have their own unique style and functionality. I personally despise the idiosyncrasies of VBScript and will do everything possible to code in KiX as a preference.

Quote:

If most or all of my scripting tasks will require COM then what value does KiX have over VBScript?



I think you have that backwards If KiXtart has access to all the same functionality as VBScript but with a superior interpreter, why would you ever use VBScript? As it is, sometimes I have to use VBScript because KiXtart has only partial support for things like COM automation objects. Now, that really annoys me.

Quote:

What draws most new users into KiX as a scripting tool is that it contains a large number of functions that don't require COM. For someone that has never scripted before, figuring out "that COM stuff" can be quite daunting.


I think that COM has a bit of mystique around it that means that people assume that it is complicated or difficult to use, however it's not. The major difficulties with COM stem from the fact that object documentation is not readily available or easily understandable to the uninitiated, and KiXtart does not have the functionality built-in to handle all the features of automation objects.

If the manual had a good beginners guide and extensive examples on how to use COM to manage common tasks then it would appear to be less voodoo and more mainstream.

There may be times when it makes sense to provide new functions to interface to Windows APIs to make it easier for starters, but it is a balance.

Just to close, if anyone needs XML file support now I *think* this link is the latest version of the community created XML functions: http://www.kixtart.org/ubbthreads/showfl...part=2&vc=1