#25869 - 2002-07-25 07:36 PM
advance scripting: Finding info to help starters become more advanced
|
JJscorpio
Fresh Scripter
Registered: 2002-06-17
Posts: 34
Loc: Houston, Tx
|
Over the past 2 days I have read dozens of post on UDF's, COM scripting, WMI, ADSI etc... I am trying to find the "how to" / "101's" of the more advanced functions available in KIX. I can see the potential and want to advance beyond the basic "flat" scripts using only the command set provided... But I don't know where start! I know this is a complex question that requires an extensive and varied answer. My knowledge level is still basic, I got bitten by the scripting bug when I found ScriptIT and managed to put out some basic task automation. I built a crude user build script that builds any number of users in NT and several other apps. from an .xls. Then I found KIX! I have a logon script and a post-image script that requires only a phone ext. and completely configures the pc and installs all the apps needed. I have this basic knowledge and seeing the potential available makes me hungry to grasp the next level! Thanks in advance, Jesse
|
|
Top
|
|
|
|
#25873 - 2002-07-25 09:59 PM
Re: advance scripting: Finding info to help starters become more advanced
|
JJscorpio
Fresh Scripter
Registered: 2002-06-17
Posts: 34
Loc: Houston, Tx
|
This BB is fantastic! There is so much knowledge here and a solid group of pro's willing to share their passion. Information is generally easy to find and presented in a manner that allows people at various skill levels to all get something out of it. Over the top... maybe but it is a sincere compliment and an expression of appreciation for the effort involved to reach this end. Suggestions... that's tough. I guess the FAQ would be the place I expected to find more. More basics such as "What are's" and "How to's". I know "what is a UDF" and "how to make a UDF" is easier said then done, esp. the latter. I have just recently gotten into the COM and UDF sections of the board and it took me some time to even figure out what each was. Please understand I am very new to scripting and really don't know how realistic this request is. Basically I am finding the next step in the learning curve to be a rather large step. Thank you for you help
|
|
Top
|
|
|
|
#25874 - 2002-07-25 10:36 PM
Re: advance scripting: Finding info to help starters become more advanced
|
Shawn
Administrator
   
Registered: 1999-08-13
Posts: 8611
|
Hi JJ,
I think you might be "past" this short introduction to "How COM Works Under-The-Covers", but just case, thought I would re-print this here (this came from the COM forum by-the way) ... I tried to express my "Mental Picture" of how COM works, in relation to how we normally shell-out to commandline utils, etc (not to different really, just a different mindset is required, thats all) :
quote:
Sometimes it helps to have an abstract mental picture of how things work. I'll tell you my mental picture in terms of how KiXtart COM (KOM) works. I think of COM objects as sort of like smart DOS programs. For example, lets say you wanted to add a new user account to your local workstation. There are two ways to do it in kixtart:
1) Shell-out to the NET command 2) Use the ADSI COM object
Using the Shell method, we would code:
code:
shell "%comspec% /c net user john.doe /add"
and what happens here ? net.exe is loaded into memory and run. net.exe then queries the command line for the parameters passed to it then simply creates the account. Then it exits, the process is unloaded from memory and your kixtart script carrys on. Pretty basic stuff eh ? If you wanted to create another user, you would have to shell out again and create another running instance of net.exe and so it goes, again and again. And the only way to communicate with these programs (specify what we want done) is with commandline parameters on the input side. And to extract information on the output side, use temporary files and read them back into our script. You know the whole story
Well with COM, things are a little different. Instead of shelling-out and running the program every time you need it, you create an instance of the running program that is always "running" in the background, waiting at all times to recieve (service) our requests. And sending information in and out of the "program" is handled much, much more eloquently. Oh yeah, and instead of calling them programs, we call them OBJECTS.
With COM, instead of using the SHELL command, we use a kixtart function called CREATEOBJECT(). For example, if I wanted to create a running instance of Internet Explorer, I would code this:
code:
$IE = CreateObject("InternetExplorer.Application")
This one function does a whole lot. Here's the blow-by-blow play (start regedit and follow along):
1) COM first looks in the registry for a key in HKEY_CLASSES_ROOT called "InternetExplorer.Application" (try finding it yourself). If you crack open that key, there's a subkey called CLSID which is basically an unique identifer for this application. Every COM object has one and they are all differnet from one another. They have to be or else COM couldn't locate your object. The string "InternetExplorer.Application" is like a shortcut, or a friendly name for the object. Heres the CLSID I have for Internet Explorer:
{0002DF01-0000-0000-C000-000000000046}
2) If you copy the value of this CLSID into your clipboard, then go back up to the top and select HKEY_CLASSES_ROOT again, then scroll down until you find a key called "CLSID", then do a find on this identifier, it should take you to a very strange place in the registry where all the identifiers are kept. Crack it open and look for LocalSever32 - whats the value there ? Look familiar ? Here's what I have:
LocalServer32 = "F:\Program Files\Internet Explorer\iexplore.exe"
COM then starts Internet Explorer using this path, but it puts it into a mode (via simple commandline switches) where it is continually running in the background. If you create an InternetExplorer object, then look at taskmgr, you will see iexplore.exe running. So like using the SHELL command, CREATEOBJECT() just starts the program.
But then here's where the fun starts. iexplore.exe is running in the background, along side your kix script and it's just waiting for requests. How does one talk to the object ? Well if you remember, the CreateObject() function returns a variable, here it is again:
code:
$IE = CreateObject("InternetExplorer.Application")
What is $IE ? $IE is a pointer to your running instance of iexplore.exe that you just created. It's like a channel or a pipe to the process (proper term is an address of an interface). Sometimes for whatever reason, the object your trying to create doesn't get created. We used to be able to test for this by querying the value of the object pointer itself, like this:
code:
$IE = CreateObject("InternetExplorer.Application") If $IE = 0 ?"Some error occurred" Endif
With the introduction of Kixtart 4.10, we now test for object creation like this:
code:
$IE = CreateObject("InternetExplorer.Application") If @ERROR <> 0 ?"Some error occurred" Endif
CreateObject() will either return the address of the object, or return a 0 (zero) if it fails. Try creating an object that doesn't exist and see what i mean. So this object pointer or interface pointer, in simple terms, consists of the following two things:
1) Properties 2) Methods
Properties are "attributes" of the currently running object. The syntax is like this:
Setting a property:
code:
$Object.Property = 1
Querying a property:
code:
$Variable = $Object.Property
We can set these attributes and/or we can query them. For example, IE has a property called "Visible" that tells wether the browser window is actually visible to the user or not (by default, when you create an IE object, it is *not* visible). I tend to think of properties as simply variables maintained by the object, inside the object itself. And in order for us to get at them, we have to specifically ask the object to set or get them for us. So, to make IE visible we must "set the Visible property", in this case to TRUE (1)
code:
$IE = CreateObject("InternetExplorer.Application") $IE.Visible = 1
So not only does IE set it's internal variable "Visible" to 1 (on our behalf), it actually went ahead and made itself visible. So now that its visible, we can query the value of this property (read it back in) to see if it really did set it.
code:
If $IE.Visible = 1 ?"Yup, it is visible..." Endif
or, since the value 1 is "true", we could just as easily code it this way:
code:
If $IE.Visible ?"Yup, it is..." Endif
Methods calls are simply function calls that you can invoke within the running instance of IE. The syntax of invoking a method call is like this:
code:
$Object.Method(Parm1,Parm2,...ParmN)
So for example, continuing our IE script:
code:
$IE = CreateObject("InternetExplorer.Application") $IE.Navigate("http://www.kixtart.org")
so we have just told IE to navigate to the best little KiXtart board on the Internet. There just like any other function call, but they are implemented inside the object. And since the IE object is always running in the background, we need a way to stop it. We do that in kixtart like this:
code:
$IE.Quit() ; another method call - gracefully closes the browser $IE = 0
Just set the variable to 0 (zero). What that does is to stop the running instance of iexplore.exe and unload it from memory. So here's our little example script in it's full form:
code:
Break On $IE = CreateObject("InternetExplorer.Application") $IE.Visible=1 $IE.Navigate("http://www.kixtart.org") GetS$ ; just pause for now $IE.Quit $IE = 0
Hope this helps. [ 25 July 2002, 22:38: Message edited by: Shawn ]
|
|
Top
|
|
|
|
#25875 - 2002-07-26 04:16 PM
Re: advance scripting: Finding info to help starters become more advanced
|
JJscorpio
Fresh Scripter
Registered: 2002-06-17
Posts: 34
Loc: Houston, Tx
|
Shawn, Thank you for taking the time to post this. Yes it is helpful, I was having some trouble pulling all the parts of COM's (and UDF's) together. this makes it very clear! I am still quite new to scripting... only been a month since I wrote my first! I now spend most of my spare time here... SeaLeopard and Chris, I know there is no better way to learn then trial by fire! (don't we all...) I DL'd KIXGUI and am playing (Thanks Chris) and will look at some of the past tourneys and maybe get in on the next. Not sure I wouldn't be in way over my head! Again thanks everyone for the positive feedback.
Jesse
|
|
Top
|
|
|
|
#25876 - 2002-07-26 04:24 PM
Re: advance scripting: Finding info to help starters become more advanced
|
Chris S.
MM club member
   
Registered: 2002-03-18
Posts: 2368
Loc: Earth
|
Don't be afraid to ask questions if you get stuck. Make sure you search the BBS and read the documentation first. Some peeps around here like to use RTFM and STFB.
|
|
Top
|
|
|
|
#25878 - 2002-07-26 05:16 PM
Re: advance scripting: Finding info to help starters become more advanced
|
JJscorpio
Fresh Scripter
Registered: 2002-06-17
Posts: 34
Loc: Houston, Tx
|
ok... RTFM makes sense, but see that fuzzy box?
|
|
Top
|
|
|
|
#25879 - 2002-07-26 05:18 PM
Re: advance scripting: Finding info to help starters become more advanced
|
JJscorpio
Fresh Scripter
Registered: 2002-06-17
Posts: 34
Loc: Houston, Tx
|
ment fussy...
|
|
Top
|
|
|
|
#25880 - 2002-07-26 05:20 PM
Re: advance scripting: Finding info to help starters become more advanced
|
Chris S.
MM club member
   
Registered: 2002-03-18
Posts: 2368
Loc: Earth
|
I think he meant...
RTFM = Read The 'Friendly' Manual STFB = Search The 'Friendly' Bulletin Board
|
|
Top
|
|
|
|
#25881 - 2002-07-26 05:34 PM
Re: advance scripting: Finding info to help starters become more advanced
|
JJscorpio
Fresh Scripter
Registered: 2002-06-17
Posts: 34
Loc: Houston, Tx
|
Crystal! Thanx
|
|
Top
|
|
|
|
#25883 - 2002-07-26 05:58 PM
Re: advance scripting: Finding info to help starters become more advanced
|
JJscorpio
Fresh Scripter
Registered: 2002-06-17
Posts: 34
Loc: Houston, Tx
|
Yeah... Newbies... :-Þ~ LOL
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 2679 anonymous users online.
|
|
|