I may have struck upon a seriously powerful nugget tonight.
I'll be the first one to admit that I despise the syntax of Powershell, but there are those that think Kixtart is dying and PS is the future. To each his own opinion I guess. Anyway, tonight I was fumbling around looking for god knows what and found the following article:
After I downloaded the exe, I installed it. I don't know if it was because I have a 64bit OS or not, but I had to copy the dll to the system32 directory, and the use regasm in the .net folder to register it.
Thankfully I hadn't gotten rid of that book I bought on Powershell (although the dust was piling up on it). So I started trying things...
First I made a UDF to initialize PS with it's constants.
(As I was testing I realized you must turn on "NoVarsinStrings" and "NoMacrosinStrings")
And here is just some of the things I came up with...
#199181 - 2010-07-3111:18 AMRe: Com Interface to Powershell
[Re: Arend_]
Arend_Arend_ MM club member
Registered: 2005-01-17
Posts: 1895
Loc: Hilversum, The Netherlands
Hastables, brings back fond memories, in mIRC Scripting Language I made lots of use of that if I had to store a LOT in memory, for instance the search results of .exe files on your C Drive. Basically you can think of a Hash Table as a MDB file loaded into memory, never touching the Hard Drive (unless it exceeds your memory limit and gets pushed into a swap file.
Hash Tables can seriously speed up things, given you have a LOT of things to store.
Eventhough your find can be reversed by using the KiXtart.dll in PowerShell ;\)
...but using that dll would mean I've left my warm and comfy kixtart environment.
The nice thing about this ps.dll is now we can basically use/steal code and import it right into kix. Hmmmm speaking of that, I wonder why there is no load/run method? Regardless, I was thinking about writing a wrapper/importer that takes an existing ps script and put the kix code around it.
Hey Bryce... check this out... Run PS scripts right in Kix.
A couple of things about this... first I ran into the permissions thing. I guess not allowing any PS scripts by default is a good thing, but talk about frustrating when you don't really understand why. Here is the article I found that help with this: http://technet.microsoft.com/en-us/library/ee176949.aspx
Next I ran into the problem of still not being able to run the script. The examples all said either fullpath\script or .\script or by setting an environment variable. Nothing was working. Happened to notice that it was truncating the directory and found the following link on what to do when there is a space in the path name... http://arcware.net/running-a-powershell-script-with-a-space-in-the-path/
I finally got it to work. I'm assuming the & is a escape character, but have yet to find anything concrete explaining its purpose. Anyone?
That didn't work because are far as PowerShell is concerned we gave it a string, so it just echoes it back to the screen. It did this because it parsed this line in expression mode. We need to tell PowerShell to parse the line in command mode. To do that we use the call operator '&' like so:
What's going on with this example is that PowerShell looks at the first non-whitespace character of a line to determine which mode to start parsing in. If it sees [_aA-zZ] or & or . or \ then PowerShell parses in Command mode. One exception to these rules happens when the line starts with a name that corresponds to a PowerShell language keyword like "if", "do", "while", etc. In this case, PowerShell uses expression parsing mode and expects you to provide the rest of the syntax associated with that keyword.
My first real use of the Powershell Object. WMI does not have a way to get the Window Title, however, .Net does... and Powershell's get-process can tie all this together...
#199646 - 2010-08-2404:21 PMRe: Com Interface to Powershell
[Re: Allen]
MartMart KiX Supporter
Registered: 2002-03-27
Posts: 4673
Loc: The Netherlands
Wow
This is really useful stuff. Just finished a small kixtart/kixforms.NET app that puts some text into an application window. There are nine possible titles of the window that are now hardcoded into the script. Getting the title of the window would make things a lot easier. I can get the PID easily so getting the title should be doable.
I'll do some testing when I'm back at the office next week.
#199649 - 2010-08-2501:16 PMRe: Com Interface to Powershell
[Re: Mart]
Arend_Arend_ MM club member
Registered: 2005-01-17
Posts: 1895
Loc: Hilversum, The Netherlands
Well, I hate to be the one to point this out, but AutoIT (a KiX-like scripting language) also has a dll with COM interface which does the same. One of my first posts uses this. Found it
Edited by apronk (2010-08-2609:39 AM) Edit Reason: Updated link
Next up... using dlls with Powershell. In the past we've used a number of methods including the DynamicWrapper.dll(Dynawrap). The problem I had with dynawrapper is it was so complicated and cryptic to read, especially after I hadn't looked at the code lately. I had read it was possible to import dlls in PS. So I decided to see if I could convert some of the dynawrap udfs to ps.
The first one I decided to translate was the SetKeyState UDF. And after much trial and error, I got it to work. (I can't say that about the second one, which will be the topic of another post)
You can find the $sig or signature to use the dll at http://www.pinvoke.net The C# sigs work with Powershell. Powershell uses the @ to define a multi-line string (called a here string) and all the powershell examples defined the sig this way. Unfortunately, the ActiveXPosh dll doesn't like here strings, so I had to break each line down and add the @CRLF.
The lines with the -memberdefintion basically take the $sig and assigns it to a var. The namespace and name values seem to be completely up to the coder, with (as far as I can tell) little to no value. I think they can contain just about any value, they just can't be the same value, and they have to be there.
