|
|
|||||||
Quote: Release notes for KiXtart 2010 (version 4.60) BETA 1 New functionality/enhancements: 1) Added option to disable/enable file system redirection on Windows x64: SetOption( "WOW64FileRedirection", "OFF" ) 2) Fixed AScan issue. 3) Added a COM implementation of the KiXtart engine. In order to use the COM implementation, copy KIXTART.DLL to a location on your system and run the following command: REGSVR32 KIXTART.DLL (Note that this command requires administrative privileges.) Once installed, you can use KiXtart from within any Windows application. The KiXtart COM component is called "KiXtart.Application" and can be instantiated using the CreateObject call: CreateObject("KiXtart.Application") Supported methods ================= RunScript( scriptname, script password, async option ) ------------------------------------------------------------------------ scriptname - fully qualified name of the script. script password - password used to encrypt the script. Optional. async option - boolean indicating if the script should be processed asynchronous (TRUE), or synchronous (FALSE). Optional. RunScript can be used to run a KiXtart script. By default, scripts are run in-process and synchronously. Optionally, a script can be run asynchronously using the async option. Note that only 1 script can be run at the same time. TerminateScript( option ) ------------------------------------------------------------------------ option - boolean indicating if the script should be terminated forcefully (TRUE), or not (FALSE). Optional. TerminateScript can be used to stop execution of a currently running script. Supported properties ==================== ScriptStatus ------------------------------------------------------------------------ ScriptStatus can be used to retrieve the exitcode of a script. If the script is still running, ScriptStatus will be 259. Sample Visual Basic Script ========================== Set oMy = CreateObject("KiXtart.Application") If err.number then wscript.echo err.description wscript.quit else x = oMy.RunScript( "c:\demo\demo.kix", , TRUE ) stat = oMy.ScriptStatus do while stat = 259 ' script still active? wscript.sleep(1000) ' yep, wait stat = oMy.ScriptStatus loop wscript.echo stat ' display exitcode End if Please report any issues with this release on one of the KiXtart discussion forums on the Internet: http://www.kixtart.org http://www.scriptlogic.com/kixtart If your issue can not be resolved on the forums, please email full details on the problem, configuration and script(s) involved to kixtart2001@hotmail.com. Note that KiXtart is provided to you as CareWare. Please see the manual for full details on the KiXtart CareWare distribution policy. |
||||||||
|
|
|||||||
Quote: 3) Added a COM implementation of the KiXtart engine. "Honest Boss... all of our scripts are using VBS." |
||||||||
|
|
|||||||
I wonder if Ruud will eventually wrap this up in an MSI for ease of installation via GPO? |
||||||||
|
|
|||||||
two crucial me wanna's: 1) must allow async execution of multiple instances 2) must have execute() method in da dll too |
||||||||
|
|
|||||||
I'm just wondering where Ruud is heading with this. Wonder if he will be exposing all the Kixtart functions as methods. That would be interesting ... like maybe: Code: Set oMy = CreateObject("KiXtart.Application") oMy.Map("\\server\share", "M:") sVal = oMy.ReadValue("Software\Microsoft...", "SomeValue") |
||||||||
|
|
|||||||
I was wondering the same thing. When I was reading all the "COM" messages (in another post), I had hoped that meant full support for COM, but after seeing this, my reaction was much more like... "Yawn" |
||||||||
|
|
|||||||
Not sure if it's doable, but I would love to see variables or constants that I can use in my includes. So instead of Include "U:\Scripts\UDF\Function1.udf" Include "U:\Scripts\UDF\Function2.udf" Include "U:\Scripts\UDF\Function3.udf" I can say Const UDFDIR "U:\Scripts\UDF" Include UDFDIR\Function1.udf Include UDFDIR\Function2.udf Include UDFDIR\Function3.udf |
||||||||
|
|
|||||||
yeah, define pragma |
||||||||
|
|
|||||||
At least it woke you guys up. Most posts here today in a while. |
||||||||
|
|
|||||||
If you could read and write to global variables in the COM instantiated script then perhaps you could do something similar to multithreading. |
||||||||
|
|
|||||||
On the COM implementation: I am working on exposing the macro's directly as COM properties. If you are interested in any other specific functionality: let me know. Ruud |
||||||||
|
|
|||||||
How about exposing the UDF's return values directly as COM properties ? |
||||||||
|
|
|||||||
well, like said before, simple execute() would be nice. |
||||||||
|
|
|||||||
Well it would be great if we could have a mechanism of communication between the calling script and the script being called. That would open up many advanced scripting possibilities. The best way would be to access global variables as properties. Maybe something like... Code: If $Kix.Vars("Progess") = 4 And $Counter = $MaxCount $Kix.Vars("LoopFinished") = 1 EndIf Being able to access Kixtart functions as methods would also be fantastic! |
||||||||
|
|
|||||||
Reading and writing 64-bit branch of the registry would be nice. I don't know if this can be done without re-coding for 64-bit OS. Many more OS installations will be 64-bit in the near future and this inability is a bit crippling. |
||||||||
|
|
|||||||
hmm... thought that the fileredirection option would also take care of that. |
||||||||
|
|
|||||||
I tested the 4.60 beta's ability to read the 64-bit branch of the HKLM\Software hive with the following code on a system running Windows 2003 R2 with Service Pack 2 and it did not read the non-redirected branch of the HKLM\Software hive: $A = setoption("WOW64FileRedirection","OFF") ? ReadValue("HKEY_LOCAL_MACHINE\software\Diskeeper Corporation\Diskeeper","build") This key exists in the 64 bit branch but not in the 32 bit branch so it is a good test. |
||||||||
|
|
|||||||
ok. that would then be a great thing to get improved before RC-1 |
||||||||
|
|
|||||||
The question is whether a 32-bit application can access the 64-bit portion of the registry. I seem to rememeber that Microsoft build in an automated redirector. |
||||||||
|
|
|||||||
Yes, Windows x64 does have built-in registry redirection. That is what you can (should be able to...) influence using SetOption("wow64alternateregview", "ON") If this does not work for you, please let me know. Ruud |
||||||||
|
|
|||||||
I missed the announcement of KiXtart 2010 - 4.60 Beta 1, until now, because it's not on the kixtart.org main page [news] section. Last entry here is 15th Sep 2006 for V4.53 release. |
||||||||
|
|
|||||||
yep. currently can't upload files on the site as my account is f'ed up. waiting for one of the server admins to fix it. |
||||||||
|
|
|||||||
resent your password |
||||||||
|
|
|||||||
k, now it's available via the website too. |
||||||||
|
|
|||||||
Originally Posted By: It_took_my_meds Well it would be great if we could have a mechanism of communication between the calling script and the script being called. That would open up many advanced scripting possibilities. The best way would be to access global variables as properties. Maybe something like... Code: If $Kix.Vars("Progess") = 4 And $Counter = $MaxCount $Kix.Vars("LoopFinished") = 1 EndIf Dear Ruud, I was looking through the documentation on the Kixtart COM object, and just realised you added this functionality with the GetVar and SetVar methods. I don't recall seeing it in any release notes but maybe I missed it? In any case, thank you very much! That really enhances the COM object significantly Cheers, Richard |