How to return value from external script to MEP?

[dickdorfman]

Hey there,

I'm trying to use an HTA script to get user input. I see there's a field for "Save console output to" a variable, but I'm wondering how to save the data from the HTA script to the console. I could save it to a file I suppose, but I'm wondering what exactly this console is and how to use it.

 

Forgive me if it's a dumb question and thanks for your help in advance,

Mike

[Cory]

Quite simply if you were at a command prompt and execute a script like VBS whatever echoes to the screen is what gets stuffed into that console variable. Did you read that post here in the forums on using HTA? Had a pretty good example.

[dickdorfman]

Thanks for your help with this. I couldn't find that earlier post on HTAs but I did see it a year or two ago and I have a copy of the "multiform.hta". Unfortunately, according to the quote I found at Microsoft Tech Net below, Wscript.Echo doesn't work with HTA. Do you know of a command that will work with HTA? Or should I save it to a file or the registry instead?

Thanks,

Mike

 

"For example, most script writers use Wscript.Echo to report information back to the user. However, Wscript.Echo won't work in an HTA. (Neither will any other WSH methods. That's because WSH methods must execute under Windows Script Host; HTAs do not run in the WSH environment.)"

 

Hey there,

I'm trying to use an HTA script to get user input. I see there's a field for "Save console output to" a variable, but I'm wondering how to save the data from the HTA script to the console. I could save it to a file I suppose, but I'm wondering what exactly this console is and how to use it.

 

Forgive me if it's a dumb question and thanks for your help in advance,

Mike

[kevin]

The Multiple Field Input Form sample creates an HTA file and runs it. When it runs, the HTA file creates a playable macro (with file extension of .mxe) containing Variable Set String commands. After the macro runs the external HTA script it uses the Load Macro Text File command to run the playable macro to write the results in variables.

 

When viewing a macro in Macro Express Pro you can view either script commands or the text based representation of the commands. To see what it looks like, with a macro open in the Script Editor, click View, Direct Editor.

 

Any external program can create a macro this way. In the Multiple Field Input Form sample the Javascript embedded within the HTA file creates the macro commands.

 

Note that the Multiple Field Input Form macro was originally written for Macro Express 3. The Variable Set String commands have a different syntax in Macro Express Pro but Macro Express Pro can read and convert the Macro Express 3 syntax.

[paul]

Quite simply if you were at a command prompt and execute a script like VBS whatever echoes to the screen is what gets stuffed into that console variable. Did you read that post here in the forums on using HTA? Had a pretty good example.

Yes, but the problem is how to get stuff echoed to the screen from within an HTA. Pure VBS offers the Wscript.echo command, but the Wscript environment is not available in HTAs. It is even possible to create a Wscript object and access its methods from within an HTA, but unfortunately Wscript.echo won't work using this method either. And examining the Multiple Field Input Form sample code doesn't teach me how to echo stuff to the screen.

[Cory]

Click here for Floyd's sample. I can't remember but he had a way to write back to the macro variables. But if that didn't suffice I'd probably use the registry to write back the values.

[paul]

Click here for Floyd's sample. I can't remember but he had a way to write back to the macro variables. But if that didn't suffice I'd probably use the registry to write back the values.

No, what he did was quite different (and written for ME3). His HTA code created ME3 code, so he could write a command as if he'd used the Direct Editor to populate a ME3 variable with a vbs variable, as in:

strOutput = "<TVAR2:11:01:" & strFirstName & Chr(01) & ">"

then he wrote the variable strOutput to a text file which he then ran in ME3 by using the load macro command. As you can see, this is entirely different to what is needed in MEP. Joe's code is not at all relevant.

[kevin]

Joe's code is not at all relevant.

Floyd and Joe's code is relevant. See my earlier post. The Multiple Input Field sample macro runs correctly in either Macro Express 3 or Macro Express Pro as long as you stick with the %Txx% variables used in the sample.

 

Macro Express Pro converts the Macro Express 3 macro commands to Macro Express Pro syntax.

 

When you load the Multiple Input Field sample code into Macro Express Pro it is converted. Once converted the macro file will no longer work in Macro Express 3. Make a copy if you want to try it in both Macro Express 3 and Macro Express Pro.

[paul]

Floyd and Joe's code is relevant. See my earlier post. The Multiple Input Field sample macro runs correctly in either Macro Express 3 or Macro Express Pro as long as you stick with the %Txx% variables used in the sample.

 

Macro Express Pro converts the Macro Express 3 macro commands to Macro Express Pro syntax.

 

When you load the Multiple Input Field sample code into Macro Express Pro it is converted. Once converted the macro file will no longer work in Macro Express 3. Make a copy if you want to try it in both Macro Express 3 and Macro Express Pro.

Nobody denies that Joe's code works in MEP - I don't believe that's the issue.

 

In what way does Joe/Floyd's code help to resolve the issue of how to get HTAs to write to the console? I thought I'd explained above how that code works, by creating ME3 macro code that then can be run using the Load Macro Text File command? Have I missed something? I believe the original author wants to have the HTA write/echo text to the console which is then returned to MEP via the "Save console output to:" facility in the External script command. How does Joe's code assist in that exercise? Please clarify.

[Cory]

Though Macronewbie specifically asked how to use the console variable feature I think Kevin and I saw past that to what we believe is his ultimate goal and that is to get the values back into MEP without having to resort to creating files or other methods. From what I can recall about how the HTA works it does that.

[paul]

Though Macronewbie specifically asked how to use the console variable feature I think Kevin and I saw past that to what we believe is his ultimate goal and that is to get the values back into MEP without having to resort to creating files or other methods. From what I can recall about how the HTA works it does that.

As we all know (by now, at any rate ) MEP has a command "External Script" which allows scripts written in one of JScript, VBScript, HTA/HTML, AutoIt to run and return console output which MEP captures in the "Save console output to:" variable. I don't think it's unreasonable to expect ISS to know how to fully use each of these scripting languages without having to resort to workarounds in order to get this feature to work properly. Yet it appears that I expect too much, as no-one seems to have any idea whether HTA scripts support this, and, if so, how to accomplish it.

 

I'd hope that ISS could provide workarounds in those cases where there is a bug in MEP. But in this case, we don't know whether there is a bug or not, because we haven't yet got to the point where we have anything to test. And what would be the point of including HTA in the list of supported scripting languages if we can't after all integrate it into MEP. All that has been suggested so far is different in no useful way to running an HTA script just like we did with ME3, i.e.

Launch Program and Activate Window: Program "xxx.hta", Parameters "", Window "windowname"

[Cory]

Would be cool if we could get some guidance on things like this for MEP and the External Script command. Too bad Floyd isn’t around anymore. And Floyd’s example was really cool but also very complex. Would have been nice to also include a super simple example.

 

I was looking at this just a little bit and did confirm that wscript.echo is not supported in HTA. But in thinking about it I believe the real situation is that it’s not relevant. HTAs don’t run in a console window so how can you echo to that which doesn’t exist? So it’s my cursory opinion that the console feature doesn’t apply to HTAs in MEP.

 

I was tempted to mess with this just now but I don’t have time or an immediate need. And I got another project I need to get done. But I did find one interesting thing. One can launch the HTA from VBScript. VBS guys do it all the time as a prettier method of input. So you could do a VB Script instead and echo the variable values after the HTA closes. Then the MEP console feature would work.

 

With the HTA script you can do all kinds of things. So one could write to the registry, file, clipboard and many other techniques so feedback the data.

 

In looking at Floyd’s script it occurred to me all he really is doing is writing the data to file and reading it back in. He’s just using a clever trick to load the vars from a macro file. But really it would be no different than writing to an INI file , reading in the values, and deleting the file.

 

So I don’t think the console feature applies to HTAs so one must rely on any of a number of relatively painless methods to get your variables back into MEP.

[paul]

So I don’t think the console feature applies to HTAs so one must rely on any of a number of relatively painless methods to get your variables back into MEP.

You may very well be right. If so, that surely begs this question: what on earth is the point of includng the capability to run HTA scripts in MEP's External Script command? What advantages are provided over simply running the HTA via the Launch Program command?

If none, then it ought never to have been included, don't you think?

[Cory]

You make an excellent point. In fact I thought about this very carefully after working on some performance issues with the command when I first got my hands on it. I had a macro that audited a bunch of files for naming conventions and reported back thousands of violators in an HTML file. One ‘feature’ was to get the ownership which I had to do with a VBScript. What I discovered was that all MEP is doing is taking the text therein, creating a file, and executing the file, and returning the result then deleting the script file from the temp folder. When I did the same thing with MEP not using the external script command it was miles faster leading me to believe ISS is doing some extra cleverness probably to make it more stable. But this also makes it slow. My point is the shininess quickly dulled and now I only use it for convenience. I was going to write a smarter VBS with a loop that would do them all in one hit but then I decided I’d make this a VB.NET project instead.

 

You know I love to argue with you but in this case I can’t, there’s no magic here like one might have with a proper API. Mainly I think it just combines some commands in one place and handles the creation of the files and all that. IE puts several lines of code in one command. Also it’s probably conceptually easier for a newbie. And I have to admit I use it knowing all this in most cases but I do it ‘my way’ when I need speed.

 

Man, a nice API to MEP would rock huh? Then again at a certain point we should just write proper compiled programs. But on the other hand developers could make cool compiled add-ons for MEP. Then again if MEP had a full feature set we wouldn’t need them. But how many things to you add and how fat and slow would MEP be then? My mind goes back and forth on the matter.

[paul]

You know I love to argue with you...

I never noticed!

Then again at a certain point we should just write proper compiled programs.

That's the 2nd time you've mentioned the word "compiled". I'm not sure about this one - you do realize that .Net technology doesn't really compile anything, it just converts user code into an intermediate stage, ready for the JIT (just in time) "compiler" to take over at runtime? I don't notice any difference between running AutoIt .exes and AutoIt scripts, but then I'm not running heavy number-crunching stuff.

[kevin]

what on earth is the point of includng the capability to run HTA scripts in MEP's External Script command? What advantages are provided over simply running the HTA via the Launch Program command?

Umm, the ability to edit the HTA script with syntax highlighting?

[Cory]

That's the 2nd time you've mentioned the word "compiled". I'm not sure about this one - you do realize that .Net technology doesn't really compile anything, it just converts user code into an intermediate stage, ready for the JIT (just in time) "compiler" to take over at runtime?

Compiled might be a bad term. I just mean a real high performance program language. But as a practical matter JIT is just as quick and some actually argue faster. And there are certain things that can handled better on the fly. It’s one of those things where we use a conceptually simpler model that for all practical purposes works. Technically I agree it’s not fully compiled, practically it’s academic. Technically electrons don’t flow like water either yet the hydraulic analogy works just fine for most auto mechanics. It’s a functional paradigm. And I'm pretty low functioning;)

 

BTW the CLR components are fully compiled so when you do things like command the array to be sorted it’s all being done in fully pre-compiled code. And even if some of the higher level code is compiled it takes very little time and once it’s compiled into machine language it runs hyper fast.

 

But the proof of the pudding is in the tasting (I hate it when people truncate that saying). I have some macros that take on the order of 20 minutes to hours to run and all they are doing is crunching data. But when I created similar routines in VB.NET and executed them in the debug environment (not even compiled yet) they executed instantly. So fast in fact I initially doubted if it was even working. Ergo for applications like this a ‘compiled’ program is what I should be using. And hey, that’s no knock on MEP as its original purpose was to automate and simulate user input in a GUI where speed is not so much of an issue. In my shed I have a chainsaw and I’m pretty handy with it. But I still have an axe as well and actually end up using it more.

[paul]

But the proof of the pudding is in the tasting (I hate it when people truncate that saying). I have some macros that take on the order of 20 minutes to hours to run and all they are doing is crunching data. But when I created similar routines in VB.NET and executed them in the debug environment (not even compiled yet) they executed instantly. So fast in fact I initially doubted if it was even working. Ergo for applications like this a ‘compiled’ program is what I should be using.

Still not sure about your conclusion. Admittedly I'm not running loops 100000 times or more, but IMHO AutoIt, for example, is very fast and not compiled. I suspect all you're really saying is that, for the most part, MEP is really very slow (much slower that ME3).

In my shed I have a chainsaw and I’m pretty handy with it. But I still have an axe as well and actually end up using it more.

Well, which are you? An axe murderer, or a chainsaw specialist? Surely you're not both?

[paul]

Umm, the ability to edit the HTA script with syntax highlighting?

Well, quite honestly Kevin, anyone who uses MEP actually to develop their scripts is not going to be doing anything very sophisticated or complex! How on earth would one seriously set about debugging such scripts? The very idea beggars belief!

IMHO, the syntax hightlighting feature of MEP is almost irrelevant, and certainly not worth going to the trouble of incorporating a scripting language for.

[Cory]

Umm, the ability to edit the HTA script with syntax highlighting?

Gunna call you on that one. True it is a feature but you put this editing feature in a small dialog box which cannot be resized! It's like looking at the Grand Tetons thru a toilet paper tube. As a practical matter I edit my scripts in UltraEdit (Color syntactical highlighting) where I can use 100% of my screen instead of 25% and then move them to the box. Also I’d like to point out that although the highlighting works for HTA it does not work for VBScript which I use primarily. Everything is black and white though it does bold a few things. Like many MEP features it’s cool but there’s always seems to be a hitch that makes it less than cool.

 

Sorry for beating you with my handbag on this one but I requested the window be resizable back in the beta days and it hasn’t happened. In fact there are several windows that are not resizable and it has always been an annoyance to me. Variable Set String > Set Value Now for instance. I spend a lot of time copying things from there to UE, editing, then pasting back.

 

Ohhhhh... You know what would be cool? If there was a button to link to an external text editor. Meh, copy/paste is easy enough.

[Cory]

Well, quite honestly Kevin, anyone who uses MEP actually to develop their scripts is not going to be doing anything very sophisticated or complex!

Exactly. But I have several VBScripts that are only 10 lines and for this it works fine as long as it's not in a big loop. Keeps the macro cleaner, reduces the lines of code... Meh. For things like this it's fine. And it keeps it all in the MEX file.

[dickdorfman]

Uhhh...

I feel so inadequate reading through all these replies. I really wanted to accomplish 2 GUI things without having to learn a new language:

- I want to be able to prompt a user for a string variable value without the "Enter string value" header that shows up in MEP confusing folks even less sophisticated than I am.

- I would love to read a file into a menu and have a few different buttons to allow the user to act on the menu items they select. (eg select messages to send to someone and have a button for telephone, letter, or email).

 

Fortunately my girlfriend works in IT so she can help me out. It's just going to cost me. Oh well. I don't mind massaging her feet that much.

 

Thanks everyone,

Mike

[terrypin]

In fact there are several windows that are not resizable and it has always been an annoyance to me.

 

Me too, so as this digression for once wasn't my fault, can I remind Kevin that the issue assigned tracking number [iSS6758] on 26th March 2009 remains unfixed.

 

That was about menu windows (pop-up or floating) not being resizeable. Also for longish names the default column is not wide enough, yet when that's manually dragged wider, an unnecessary vertical scroll bar appears and the bottom macro disappears. Neither flaw life threatening - but 26 months and still not fixed?

 

--

Terry, East Grinstead, UK

[terrypin]

I want to be able to prompt a user for a string variable value without the "Enter string value" header that shows up in MEP confusing folks even less sophisticated than I am.

 

Never thought about that before, but I see your point. It would have been better if the Prompt title was customisable, like Text Box Display and Multiple Choice windows. Why not make a formal request here and we'll see how long it takes Insight to implement it?

 

--

Terry, East Grinstead, UK

[Cory]

- I would love to read a file into a menu and have a few different buttons to allow the user to act on the menu items they select. (eg select messages to send to someone and have a button for telephone, letter, or email).

Ha! I just saw cool simple HTA example the other day that read a list of phone number from a file. Ah, here it is. That's areal simple example. All I would add would be to write the value back to the registry and read that back into MEP.