AutoItX ActiveX quirk...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

AutoItX ActiveX quirk...

Christopher J. Demers
I am trying to drive AutoItX ( http://www.hiddensoft.com/AutoIt/ "AutoIt is
a simple tool that can simulate key presses, mouse movements and window
commands (maximize, minimize, wait for, etc.) in order to automate any
windows based task" and its free!) from Dolphin Smalltalk.  I generated the
interface class from the ActiveX wizard.

Given:
    ait := AUTOITXLibIControl new.
This line causes a very strange error (see bellow):
    ait winWait: 'Untitled - Notepad' bstrText: '' nTimeout: 5.
This line does not error, but does not do what I need it to since I need the
second argument to really be an empty string:
    ait winWait: 'Untitled - Notepad' bstrText: 'blah' nTimeout: 5.
Other messages work for me such as:
    ait sleep: 1000.
    ait send: 'Test'.

Here is the relevant code the wizzard generated:
============
WinWait: bstrTitle bstrText: bstrText nTimeout: nTimeout nRes: nRes
"Private - Invoke the WinWait() method of the COM object.
Helpstring: method WinWait
HRESULT __stdcall WinWait(
[in] BSTR bstrTitle,
[in] BSTR bstrText,
[in, defaultvalue(0)] long nTimeout,
[out, retval] long* nRes);"
<virtual stdcall: hresult 8 bstr bstr sdword sdword*>
^self invalidCall
============

It looks like the instance of AUTOITXLibIControl somehow becomes a
SmallInteger.  Here is the error:
----------------------------------------------------------------------------
------------------------
6:15:44 PM, 2/18/2004: Unhandled exception - a GPFault('Invalid access to
memory location. Reading 0x0, IP 0x9A15CEB (C:\Program
Files\AutoIt\AutoItX\AutoItX.dll)')

ProcessorScheduler>>gpFault:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
SmallInteger(Object)>>doesNotUnderstand:
SmallInteger(AUTOITXLibIControl)>>WinWait:bstrText:nTimeout:nRes:
AUTOITXLibIControl>>winWait:bstrText:nTimeout:
UndefinedObject>>{unbound}doIt
CompiledExpression>>value:
SSWSmalltalkWorkspace(SmalltalkWorkspace)>>evaluateRange:ifFail:debug:
SSWSmalltalkWorkspace(SmalltalkWorkspace)>>evaluateItIfFail:debug:
SSWSmalltalkWorkspace(SmalltalkWorkspace)>>evaluateItIfFail:
SSWSmalltalkWorkspace(SmalltalkWorkspace)>>evaluateIt
Symbol>>forwardTo:
CommandDescription>>performAgainst:
[] in Command>>value
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Command>>value
ShellView>>performCommand:
----------------------------------------------------------------------------
------------------------

Does anyone have any thoughts about what the problem might be?

Chris


Reply | Threaded
Open this post in threaded view
|

Re: AutoItX ActiveX quirk...

Bill Schwab-2
Chris,

Dumb question: what about the out parameter?  Could the control be stomping
on memory because it is not set correctly?  I'd hope it would default to
nil, and that a NULL pointer would result, with nothing being done, but that
might be too much to ask.

You could try creating a new DWORD instance and pass it as the last
parameter to give the control a place to strike.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: AutoItX ActiveX quirk...

Christopher J. Demers
"Bill Schwab" <[hidden email]> wrote in message
news:40340f4a$[hidden email]...
> Dumb question: what about the out parameter?  Could the control be
stomping
> on memory because it is not set correctly?  I'd hope it would default to
> nil, and that a NULL pointer would result, with nothing being done, but
that
> might be too much to ask.
>
> You could try creating a new DWORD instance and pass it as the last
> parameter to give the control a place to strike.

I did not include this method in may last post, this is another method
generated by the wizard.  I am actually calling this method, which calls the
other method I posted.  It looks like it is doing what you suggest it would
need to DWORD, unless there is a subtlety I am missing.

=========================
winWait: bstrTitle bstrText: bstrText nTimeout: nTimeout
"Answer the <SDWORD> result of invoking the WinWait() method of the COM
object.
Helpstring: method WinWait"
| answer |
answer := (SDWORD new).
self
WinWait: bstrTitle
bstrText: bstrText
nTimeout: nTimeout
nRes: answer.
^answer asObject
=========================

I wonder if Dolphin is doing some kind of optimization on the empty string
that is hurting its ability to pass it.

Thanks for taking a look,
Chris


Reply | Threaded
Open this post in threaded view
|

Re: AutoItX ActiveX quirk...

Blair McGlashan
In reply to this post by Christopher J. Demers
"Christopher J. Demers" <[hidden email]> wrote in
message news:c10sg7$1cr097$[hidden email]...
> I am trying to drive AutoItX ( http://www.hiddensoft.com/AutoIt/ "AutoIt
is
> a simple tool that can simulate key presses, mouse movements and window
> commands (maximize, minimize, wait for, etc.) in order to automate any
> windows based task" and its free!) from Dolphin Smalltalk.  I generated
the
> interface class from the ActiveX wizard.
>
> Given:
>     ait := AUTOITXLibIControl new.
> This line causes a very strange error (see bellow):
>     ait winWait: 'Untitled - Notepad' bstrText: '' nTimeout: 5.
> This line does not error, but does not do what I need it to since I need
the
> second argument to really be an empty string:
>     ait winWait: 'Untitled - Notepad' bstrText: 'blah' nTimeout: 5.
> Other messages work for me such as:
>     ait sleep: 1000.
>     ait send: 'Test'.
> ...
> It looks like the instance of AUTOITXLibIControl somehow becomes a
> SmallInteger.

The control is GPFing. The odd error report you are seeing is just an error
in the reporting of the GPF. There is a known issue that when the VM traps a
GPF in a virtual function call (i.e. a COM interface method call) it will
not set up the Smalltalk stack pointer correctly and so it appears that the
COM interface receiver has transformed itself into a Smallinteger.

>...Here is the error:
> --------------------------------------------------------------------------
--
> ------------------------
> 6:15:44 PM, 2/18/2004: Unhandled exception - a GPFault('Invalid access to
> memory location. Reading 0x0, IP 0x9A15CEB (C:\Program
> Files\AutoIt\AutoItX\AutoItX.dll)')
> ...

I suspect what is happening here is that the control is not handling the
"empty" BSTR correctly. BSTR's representation of an empty string is a NULL
pointer.
I tried downloading the control, generating the interface, and testing out
your expression, and the GPF is definitely an attempt to read a null pointer
occurring in AutoItX.dll. One can't be entirely sure, but it strongly
suggests that the control is not handling an empty BSTR (i.e. null)
correctly. It seems likely that AutoItX.dll assumes that all BSTRs it
receives are valid Unicode string pointers, which they are with the
exception of the special case of the empty string.

As a workaround you could do this:

    empty := OLEAutLibrary default sysAllocString: ''.
    ait winWait: 'Untitled - Notepad' bstrText: empty nTimeout: 5.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: AutoItX ActiveX quirk...

Christopher J. Demers
"Blair McGlashan" <[hidden email]> wrote in message
news:c1316s$1cr8qf$[hidden email]...
> I suspect what is happening here is that the control is not handling the
> "empty" BSTR correctly. BSTR's representation of an empty string is a NULL
> pointer.
...
> correctly. It seems likely that AutoItX.dll assumes that all BSTRs it
> receives are valid Unicode string pointers, which they are with the
> exception of the special case of the empty string.
>
> As a workaround you could do this:
>
>     empty := OLEAutLibrary default sysAllocString: ''.
>     ait winWait: 'Untitled - Notepad' bstrText: empty nTimeout: 5.

Thank you!  That eliminates the error.  This is probably a case of an of
ActiveX client being geared towards VB.  Their example code is in VB and
passes an empty string (I have not tested it, but assume it would work).   I
wonder if there might be value in having a way to mark (possibly through
subclassing) an interface class in Dolphin as needing to more closely
emulate VB's habits when calling ActiveX functions.  You would know better
than I if the number of potential issues would make such a thing practical.
In a perfect world all ActiveX clients would conform to standards, however
it seems that some expect VB's quirks.  Just a thought for the future. ;)

Thanks again,
Chris


Reply | Threaded
Open this post in threaded view
|

Re: AutoItX ActiveX quirk...

Blair McGlashan
"Christopher J. Demers" <[hidden email]> wrote in
message news:c13c35$1dbg8u$[hidden email]...
> "Blair McGlashan" <[hidden email]> wrote in message
> news:c1316s$1cr8qf$[hidden email]...
> > I suspect what is happening here is that the control is not handling the
> > "empty" BSTR correctly. BSTR's representation of an empty string is a
NULL

> > pointer.
> ...
> > correctly. It seems likely that AutoItX.dll assumes that all BSTRs it
> > receives are valid Unicode string pointers, which they are with the
> > exception of the special case of the empty string.
> >
> > As a workaround you could do this:
> >
> >     empty := OLEAutLibrary default sysAllocString: ''.
> >     ait winWait: 'Untitled - Notepad' bstrText: empty nTimeout: 5.
>
> Thank you!  That eliminates the error.  This is probably a case of an of
> ActiveX client being geared towards VB.  Their example code is in VB and
> passes an empty string (I have not tested it, but assume it would work).

Well it will work like this (I've just tested it):

Dim ait As New AUTOITXLib.Control
ait.WinWait "Untitled - Notepad", "", 5

But if you write it like this:

Dim ait As New AUTOITXLib.Control
Dim s As String
ait.WinWait "Untitled - Notepad", s, 5

Then make sure that (unlike me) you save your work before running it, since
it will bring VB down.

>...I
> wonder if there might be value in having a way to mark (possibly through
> subclassing) an interface class in Dolphin as needing to more closely
> emulate VB's habits when calling ActiveX functions.  You would know better
> than I if the number of potential issues would make such a thing
practical.
> In a perfect world all ActiveX clients would conform to standards, however
> it seems that some expect VB's quirks.  Just a thought for the future. ;)

We do try and allow for that where it does not compromise things too much.
In this case, though, I think it is a straightforward bug in the control.
The AutoIt web site seems to suggest it is an open source project, but I
couldn't find any source, otherwise I'd have submitted a fix. There is a
facility to submit a bug report though...

Regards

Blair