VBScript/WScript issues hooking external application DOM events within VBPro 6.7a [Archive]

View Full Version : VBScript/WScript issues hooking external application DOM events within VBPro 6.7a

mmcgregor

07-08-2009, 12:03 PM

Trying to respond to a created IE window/loaded form. Everything works great except for the limitation of hooking into the onclick of the form buttons and the other form/application messages like onquit. Anyway of making that work? Currently, when a button is pressed on the IE form, the button stays down (graphically stays pressed) and not events ever reach VBP script step.

Using VBP 6.7a on XP Pro OS fully service packed. Script engine is 5.7.

Any thoughts would be greatly appreciated.

The following script and HTML below work fine when launched from CScript or WScript at the command line. Within VBP 6.7a, the buttons just hang (stay depressed) when pressed and nothing happens (no msgboxes appear) in the script hooks within VBP step script.

Script used:
set ie = WScript.Createobject("internetexplorer.application")
set shell = WScript.Createobject("WScript.Shell")

'Variables to control looping and waiting for user input
exitScript = false

'Turn off IE features. We want a bare IE window with just the required form
ie.MenuBar = false
ie.AddressBar = false
ie.StatusBar = false
ie.ToolBar = false

'Disallow popup dialogs
ie.Silent = true

'Show the explorer window.
ie.visible = true
shell.AppActivate(ie.Name)

'Set the page
html = "c:\input.html"
ie.navigate(html)

'Wait for the page to load
do while ie.readystate<>4
Loop

'Get access to IE's DOM to allow hooking to the buttons.
'This succeeds, but pressing the button currently hangs the button in the
' depressed state. No call ever happens in the VB code.
'This appears to possibly be related to the version of scripting and the
' inability to supply an alias in the VBPro WScript.CreateObject call.
set doc=ie.document
'Hook to the buttons to process functions here. Not working correctly
' when buttons are pressed
doc.forms(0).elements("Submit").onclick=getref("iesubmit")
doc.forms(0).elements("Cancel").onclick=getref("iecancel")

'Loop forever waiting until a button is pressed.
do while exitScript = false
WScript.Sleep(1000)
'builder.LogMessage "looping", true
loop

ie.Quit

'The submit button action; hook set above for onclick
Sub iesubmit()
MsgBox("Submit")
end sub

'The cancel button action; hook set above for onclick
Sub iecancel
MsgBox("Cancel")
exitScript = true
end sub

HTML (input.html):
<html>
<body>
<form method="get">
<input name="Test" value="Test" />
<BR>
<button name="Submit" value="Submit">Submit</button>
<button name="Cancel" value="Cancel">Cancel</button>
</form>
</body>
</html>

kinook

07-08-2009, 12:46 PM

Include the /mta command-line switch when starting VBP (not necessary in v7).
http://www.kinook.com/VisBuildPro/Manual/command_linegui.htm

mmcgregor

07-08-2009, 01:40 PM

That solves the control event problem nicely. Thanks for the quick response.

Just to follow up on the second related issue. WScript.CreateObject and the alias (also called event prefix) parameter. Is this/will this be available in VBPro 7.x? The prefix parameter, not avaialble in WScript presented through VBPro 6.7a, appears to be mandatory to make certain window event hooks happen; those that are not settable from the DOM (control OnClick() is, but OnQuit is not). Maybe I'm missing part of the DOM that allows this, but all posts that I've found solve this problem via the prefix parameter in the CreateObject call. The other alternatice that I've seen was WScript.ConnectObject(ieo, "ie_"), and this call is simply not available from within VBPro 7.

Thanks again for the information provided on the /mta switch!

Any thoughts on this issue would be appreciated. Thanks in advance!

Sample:
set ieo = WScript.CreateObject("InternetExplorer.Application", "ie_")

sub ie_onQuit()
'Called when IE is closed
MsgBox("IE is closing")
end sub

kinook

07-08-2009, 02:00 PM

We don't have any plans to enable that capability. The special CreateObject/ConnectObject methods are specific to the WScript object (see http://msdn.microsoft.com/en-us/library/ms974564.aspx). I'm not sure if the ActiveX Scripting interfaces expose any support for that, or if so, how it would be implemented.

You could invoke cscript.exe/wscript.exe via a Run Program action to run such a script externally.

mmcgregor

07-08-2009, 02:18 PM

Thanks for your response.

The code shown above IS how natvie WScript provides it; two argument function call. If that code is run from the CScript on the commandline, it works just fine; i.e. the onquit message fires.

However, VBPro x does not allow the second parameter of the WScript call; even though all documentation about that function states that the WScript.CreatObject has an optional second parameter.

Are you removing it or providing a mock WScript base with very limited "common use" functions for compatibility purposes? The "hooks" should work if the code is being run within the native scripting host. I assume that VBPro does not execute those within that, but rather has a fix up layer for some scripting functionality. It seems awfully close, since it does allow nackward event communication via control event hooks previosuly mentioned; i.e. once the /mta is set in v.6.7a. Why would the remaining event architecture be unobtainable or not defined.

mmcgregor

07-08-2009, 02:34 PM

Thanks for the script sugestion.

The issue with running the script externally was that this method of user input was supposed to be a simplistic way of providing a form interface to the scripting language so that dynamic decisions could be made as the script runs; I expect multiple modes of batch, scheduled batch, and interactive. Running a script externally means parsing a file or stdout text to understand what the user wanted to do. This complicates things, and at that point I'ld write a COM object in C# and expose an interface or wrap VBPro in an application that kicks it off with commandline macro defintion.

Also, the MessageBox/Input forms built into VBScript are way to limited!

But again, thanks for thinking outside the box! Always appreciate alternative ideas.

kinook

07-08-2009, 02:47 PM

Originally posted by mmcgregor
The code shown above IS how natvie WScript provides it; two argument function call. If that code is run from the CScript on the commandline, it works just fine; i.e. the onquit message fires.

However, VBPro x does not allow the second parameter of the WScript call; even though all documentation about that function states that the WScript.CreatObject has an optional second parameter.

Are you removing it or providing a mock WScript base with very limited "common use" functions for compatibility purposes? The "hooks" should work if the code is being run within the native scripting host. I assume that VBPro does not execute those within that, but rather has a fix up layer for some scripting functionality. It seems awfully close, since it does allow nackward event communication via control event hooks previosuly mentioned; i.e. once the /mta is set in v.6.7a. Why would the remaining event architecture be unobtainable or not defined. VBP does not actually use WScript (exposed only within wscript.exe/cscript.exe). VBP's WScript object is just an alias for the Builder object, which implements its own CreateObject (mapped to CoCreateInstance), Echo (mapped to LogMessage), and Sleep methods so that external scripts can be more easily ported into VBP. VBP uses the underlying ActiveX Script interfaces (see http://msdn.microsoft.com/en-us/library/ccd0zt2w(VS.85).aspx) to implement its scripting capabilities. I don't know if it's possible to implement what WScript does with events for CreateObject/ConnectObject using these interfaces, and if it is, how much work it would be. My guess is it's either not possible or a lot of work. If I'm wrong and there is a straightforward code sample available somewhere that implements this, we'll certainly consider incorporating it into VBP.

mmcgregor

07-08-2009, 02:51 PM

Thanks for the clarification. I'll keep that in mind.

kinook

07-08-2009, 02:57 PM

Originally posted by mmcgregor
Thanks for the script sugestion.

The issue with running the script externally was that this method of user input was supposed to be a simplistic way of providing a form interface to the scripting language so that dynamic decisions could be made as the script runs; I expect multiple modes of batch, scheduled batch, and interactive. Running a script externally means parsing a file or stdout text to understand what the user wanted to do. This complicates things, and at that point I'ld write a COM object in C# and expose an interface or wrap VBPro in an application that kicks it off with commandline macro defintion.

Also, the MessageBox/Input forms built into VBScript are way to limited!For more complex or dynamic front-ends, a custom action or GUI wrapper that calls VBP is probably the way to go.
http://www.kinook.com/VisBuildPro/Manual/promptsample.htm

We've considered adding a way to create custom GUIs shown at build-time within VBP, but anything we created would probably be too limited compared to what's possible with the above methods.

Here are a few other possibilities:
http://blog.woodchop.com/2006/08/gooeyscript.html
http://www.toptensoftware.com/quickprompts/
http://www.google.com/search?q=vbscript%20gui