External Scripts - How far are you pushing them?

[Adam]

External scripts seems like one of the most powerful and least documented features of M/E Pro, so I'm curious who is playing with them in what ways.

 

At a minimum they make regular expressions a snap.

 

I've personally been pondering the the HTA/HTML capabilities. A couple questions come to mind.

 

How would you return multiple variables from a HTA/HTML page? Multiple wscript.echo()?

 

How would you deal with a user filling out half an HTA/HTML page with a variety of form elements, (radio, multiple select, text area, etc) then coming back to it a day later?

 

Cheers!

 

Adam

[joe]

External scripts seems like one of the most powerful and least documented features of M/E Pro

Very true. Very powerful. I presume lack of documentation is because the developers of Macro Express assume the users have knowledge of the script language they are using.

 

so I'm curious who is playing with them in what ways.

My company, PGM, uses the External Script command all the time: date/time calcs, regular expressions, Excel DOM, file data, and all kinds of wonderful things.

 

How would you return multiple variables from a HTA/HTML page?

The only way to halt the macro until you receive a return value from your external script is to use the "Save console output to:" field, which means that your script must write a value to the console. The value will be saved in the variable you choose. I use it to return results from any function in the four allowed script languages. To return multiple values use a tab-separated string and the set a MX Pro array from it. Of course there are other ways to return multiple variable values from a script: write them to a known location in the Registry, write them to a playable macro and then play the macro, and so forth.

 

How would you deal with a user filling out half an HTA/HTML page with a variety of form elements, (radio, multiple select, text area, etc) then coming back to it a day later?

Your macro/script would need to store data for the HTA fields in, say, an INI file which can be read and written to by any of the script languages. There are other ways, of course, but this would seem to be straightforward.

[Cory]

I was a little disappointed with the script feature. Mainly I was learning PowerShell as most of the Windows scripting languages like VBScript have been deprecated but MEP is incapable of running PS scripts apparently because of a lack of Unicode support. But really all the feature does is take the text and stick it in a file in the temp folder (or one of your choice) and execute the script. The benefits are flow control and support for variables but with large scripts I found myself cutting and pasting in and out of the little text window so I could edit them in a proper editor where I could see what was going on. So I think it's nice for small scripts as it saves some macro commands and you don't have to keep your scripts externally so I guess I'm mainly whining about PS.

[Adam]

Thanks for the insight fellahs.

 

Joe,

 

I thought about doing the mid-form registry entries or ini files, but I'm not that familiar with methods for using those from an HTA. When you talk about writing to them for mid-form saving, what method do you prefer?

 

Adam

[joe]

I prefer INI files for this type of work.

 

You could place a VBScript or Javascript code section within the HTA/HTML document to read/write INI files and it would work. But it would be easier to use the Macro Express INI handler commands to do the job. The return string from the HTA/HTML document would need to contain a tab separated list of the values from each field which you would use to update sections in the INI file.

 

If you want to use the values from the INI file for a subsequent call to your HTA/HTML document, simple read the values into variables that are embedded into your script. Remember that Macro Express substitutes the %variables% with actual values prior to writing-out the script.