code:

---

$word = olecreateobject ("word.application")
if $word=0
	? "Failed to create object" ?
else
	? "Object created.  Handle= $word" ?
endif

$rs = oleputproperty ( $word, "visible", "b", "1" )

$docs = val("&"+olegetproperty ( $word, "documents" ))
$page = val("&"+olecallfunc ( $docs, "add" ))
$range = val("&"+olecallfunc ( $page, "range" ))
$rs = olecallfunc ( $range, "insertbefore", "s", "KIX RULES!!!" )

$rs = olereleaseobject($word)

---

I am interested in creating a form and buttons on that form. I am also interested in activating the File Open dialog box. Does anyone have any list of what objects are available in what DLLs and what properties those objects have?

There must be more usefull things in this OLE malarky than sending text to applications...

cj

What have you heard my brother ?

Shawn.

[This message has been edited by Shawn (edited 25 May 2000).]

Hi there,

I'm afraid the syntax you are attempting to use is not yet supported. It is scheduled for the next major update of KiXtart.

You can actually achieve the same results, but it will require you to use the OLEPutProperty function. An example of this is included in the latest zip. NB: these functions are ugly and clumsy to use, and this is exactly why I'm working on improving this right now.

Kind regards,

Ruud

creutz wrote:
>attn Ruud
>please could you look at my problem
>as I dont seem to get kix ole's right
>
>
>creutz wrote:
>>there seems to be a lot of questions about kix ole functions
>>and the only answer seems to be "try activex syntax", well
>>i have tried and got a lot of errors, so please
>>
>>can anybody translate this easy vbscript
>>to kix script, as I dont seem to get the
>>OLECALLFUNC/OLECALLPROC lines right
>>thank you
>>
>>set cd = createobject("MSComDlg.CommonDialog")
>>
>>cd.Filter = "All Files(*.*)|*.*"
>>cd.FilterIndex = 3
>>cd.MaxFileSize = 128
>>cd.ShowOpen()
>>
>>
Ruud van Velsen

cj

ALL RIGHT !!!

If Ruud makes these improvements - get ready for a wild KiX ride !!!

This still leaves the question about what automation objects are available and usefull in a KiX script.

One of the ways I look for usefull objects is to start Visual Basic and create an empty project. Then from the "references" menu, add in interesting looking components. Then use the "object browser" to look at the implemented methods and properties. VB is also a create tool for prototyping your script. Get it to work in VB first - then write your KiX script !

I personally use C++ for building components. VB is nice but even a minimal (one method) automation object would build- up into a huge installation package. C++ components are tiny and ship in just one DLL !!!

In terms of KiX - be carefull - automation supports a wide array of variable types (roughly 38 of them and generically called "variants" ). Kix only supports 9 of them. You might also find that alot of the components require that you pass array arguments ( which KiX doesn't support (yet) ).

Even if Rudd does imbed automation support into the KiX language itself, I think there will still be a place for building a "useful" "KiXfriendly" snapin.

This is the sample driver script that I am using right now ...

code:

---

break on

$klib = olecreateobject ( "KiXtart.Library" )

if olecallfunc ( $klib, "GetTotalPhysicalMemory" ) > 64000000
 ?"All right my brother!"
else
 ?"Sorry to hear that"
endif
exit

---

Right now ( as we speak) and am coding the "return value" part of the GetTotalPhysicalMemory method - then I'll be done with the component infrastructure. From there it's easy stretch to build up functionality by adding new methods to new and wonderful Windows API's ...

Why am I doing all this ?

At the end of the day - I want to be able to include a Windows progress (status) bar in some KiX scripted installation packages that I have. Thought it would be a nice touch.

Has anybody been able to implement one with pure KiX OLE functions ? I think the problem is that the Progress Bar is a "control" and is meant to be run in the context of a pure "Windows" application. It think KiX is what they call a "Win32 Console Application" !

Shawn.

[This message has been edited by Shawn (edited 25 May 2000).]

Bryce

Wanna try it out ?

I'll mail it to you right now if you want !

I promise that's there no worms or trojans in it !

Shawn.

Bryce

Try to set the night on fire !

ok - I'll stop now !

Shawn.

code:

---

Right on my brother, thanks for trying ...
KiXtart Library Extentions (Version 0.1)
Feedback: http://www.kixtart.to/script/board/ 
Total available physical memory = 200859648
Hit any key to continue ...

---

Bryce

Thanks Bryce for giving it a try.

Nice to see that it works on someone else's machine. Better than that VB crap eh ?

VB would have polluted your machine with dll's and type libraries and all kinds of junk.

The one thing I haven't tested yet is whether a ordinary user has "priviledge" to register the KixLib32.dll ??? All COM components ( ALL OF THEM ) register themselves in HKCR under CLSID, APPID, and under their component name. Check it out !

KixLib32 will "unregister" itself from your machine by saying ...

regsvr32 /u kixlib32

Clean huh ?

As I said before - I'm currently working on getting the return values from OLE working. Will keep you posted. Then I can use KiX OLE functions in a more "natural" code flow like in the script above ^

Thanks again !

Shawn.

p.s.

Did you notice the version number ?

And nice memory config you got there !

Shawn..

[This message has been edited by Shawn (edited 25 May 2000).]

Everything that tells me total memory is saying 196,152k. with current mem in use being arround 115meg.

Bryce

It's just a rounding thingy ...

Most other tools report memory in kbytes. We can get a little more accuracy than that with Kix ...

Take 200,859,648 / 1,024 = 196,152 kb

Novastar:

I agree !

Gang:

<rant on>

[Oh god - here he goes again ! Skip to <rant off> if not interested]

I think one could go so far as to say that "anything can be done by everything" ( or vice-versa - I don't know)

Having lived by that rule though - we'd probably still be writting logon scripts with .bat files and Rudd would never have blessed us with this wonderful tool we call "KiXtart".

Let's put it this way - Rudd is (supposedly) going to integrate Automation into KiXtart ( at the raw "language" level - and not just through function calls). Calling it "Object Oriented KiX" would probably be a stretch but I think this is vital because Perl and wsh already support it and unless one wants to be left in the dust (like a fossil), one has to let evolution take it's course.

However, adding Automation (in and by itself) doesn't really mean very much. Automation is just a vehicle (a transport)that allows one to talk to Automation Servers (like Microsoft Word, Excel and PowerPoint). Unless one has something worth automating (KiX-worthy), one has to be content with writing scripts that build nice PowerPoint presentations (over and over again). It's like getting the keys to a brand new car and then not having anywhere to go (doh!)

I imagine that Rudd gave us the OLE functions ( way back in version 3.46) for a reason. OLE's sole purpose is to allow programs and scripts to talk with one another. It allows developers/scripters to quickly buildup functionality by "snapping togther" components from many different vendors.

But it's up to us as "KiXters" to decide whats possible and whats needed. Then having made these determinations - to develop the servers (components) that implement the possibilties !

If one looks far down the road - say version 5 or 6 of KiXtart - one might invision a "DOS-free" logon process that runs in a pure Windows context - complete with dialogue boxes, progress bars and tight integration with things like Active Directory, Internet Explorer, ODBC/SQL and other "Automationable" objects !

I don't know about you, but I feel like I've written my last "net use" and "if ingroup()" for my liking !

<rant off>

Sorry if I'm rambling on here guys ! Does anyone have any thoughts/feelings or differences of opinions about the KiX OLE functions ? I mean - that's why we have this board - is it not ?

Shawn.

[This message has been edited by Shawn (edited 26 May 2000).]

Right now the majority of kix scripts are going to be logon scripts/admin scripts. very few people are writing scripts for the end users ( well i am but I'm weird like that ).

I think OLE in kix is just the next step.

Bryce

If that doesn't convince you, maybe this will...

code:

---

break on

$cd = olecreateobject("MSComDlg.CommonDialog")

$rs = oleputproperty ( $cd, "Filter", "s", "All Files(*.*)|*.*" )
$rs = oleputproperty ( $cd, "FilterIndex", "s", "3")
$rs = oleputproperty ( $cd, "MaxFileSize", "s", "128")

$rs = olecallfunc ( $cd, "ShowOpen" )

exit

---

Shawn.

[This message has been edited by Shawn (edited 26 May 2000).]

Damn those Visual Basic runtimes. In order to use this one needs the common dialogue components ( comes with the VB runtimes I think ) ... working ....

If you have the following key in your registry ...

HKEY_CLASSES_ROOT\MSComDlg.CommonDialog

Then you can use these features...

Shawn.

[This message has been edited by Shawn (edited 26 May 2000).]

Has anybody been able to get this puppy to run on their workstation ?

Shawn.

p.s. Works great on my workstation. Must be some kind of Microsoft conspiracy ! I'll keep working on it though !

Shawn..

[This message has been edited by Shawn (edited 26 May 2000).]

Bryce

You are right and wrong at the same time. If you want all these gui goodies why don't use visual basic ? For me kixtart should be a non interactive string and command interpreter. What I want is more string processing functions and file read/write capabilities. I want also to take stdout and pass it directly to variables and arrays.

The scripts are easily editing pieces of text that everyone can make corrections changes and fit ot its needs. I also want some more macros and some winsock functions to create start and stop tcp servers !

There are cases would need much more time and effort to write a visual basic or c++ program in order to do the same things with a clever and small kix or perl script.

PS. whats wrong with dos ?! I am still using it and love it! Many times windows problems can be corrected only from dos mode. By the way I also preffer the old dos games and coin up emulators than windows 3d bloody craps : )

[This message has been edited by novastar (edited 26 May 2000).]

Don't get me wrong - I agree with you mostly !

I don't want the GUI goodies either. When I'm developing an end-user application, KiXtart is my last choice.

I wish VB was my last choice too - but it's just so damn nice to develop with VB. But those friggin runtimes ! Arrrgh !!!

What I am after is the Windows NT internal stuff (the API's) that would be so nice to get at from within KiX. Imagine if one could roll all those ResKit and DOS commands into a single KiX library DLL ! A common interface and a common way of returning values to one's script !

No more would we have to shell-out to a program, pipe the output to file - then read (parse) it back in. What a Kludge !

Here's the driver for the current incarnation of the library ...

code:

---

break on
;--------------------------------------------------------
; Create the kixtart.library object ...
;--------------------------------------------------------

$lib = olecreateobject ( "kixtart.library" )

if $lib = 0
 ?"Error creating kixtart.library"
 exit
endif

;--------------------------------------------------------
; Get the current millisecond counter from Windows NT ...
;--------------------------------------------------------

$start = val(olecallfunc ( $lib, "GetTickCount" ))

;--------------------------------------------------------
; Set the console window title to something else ...
;--------------------------------------------------------

olecallfunc ( $lib, "SetConsoleTitle", "s", "Kixtart.Library Driver Script" )

;--------------------------------------------------------
; Check if console cursor is currently visible ...
;--------------------------------------------------------

if olecallfunc ( $lib, "GetCursorVisible" )

 ;--------------------------------------------------------
 ; Make console cursor invisible ...
 ;--------------------------------------------------------

 olecallfunc ( $lib, "SetCursorVisible", "i", "0" )

 ? ?"Enter an invisible cursor string > " gets $c

 ;--------------------------------------------------------
 ; Set console cursor back to visible ...
 ;--------------------------------------------------------

 olecallfunc ( $lib, "SetCursorVisible", "i", "1" )

endif

;--------------------------------------------------------
; Get the current millisecond counter from Windows NT ... 
;--------------------------------------------------------

$end = val(olecallfunc ( $lib, "GetTickCount" ))

;--------------------------------------------------------
; Display elapsed milliseconds (runtime) for script ...
;--------------------------------------------------------

? ?"Elapsed milliseconds = " $end - $start

;--------------------------------------------------------
; Release the kixtart.library object
;--------------------------------------------------------

$rs = olereleaseobject ( $lib )

exit

---

I use this tool just for the GetTickCount function when benchmarking my scripts to see how long certain kix commands (ingroup) and programs (shells) take to execute !

Anyway - I don't know if this kind of library has any general use within the KiX community or not ! Might make an interesting debugging tool though !

Shawn.

[This message has been edited by Shawn (edited 30 May 2000).]