ActiveX Calls Where Arguments Are "Out"

Hello Forum,

I've searched the archives for insight into ActiveX calls where the
arguments are designated as "out" (in other words, the call will return
values to the addresses of the arguments, but no values are expected as
inbound.

In testing GetClientRect() of our XtremeCommandBars ActiveX control, we
seem to be having trouble getting this method to execute.  We have the
following arrangement (GetClientRect() returns the region of the
CommandBarsFrame that does not contain any command bars):

XtremeCommandBarsPresenter>>#clientExtent

| vertices |
vertices := self commandBars getClientRect.
^Rectangle
        left: (vertices at: 1)
        top: (vertices at: 2)
        right: (vertices at: 3)
        bottom: (vertices at: 4)

where XtremeCommandBarsPresenter>>#commandBars is defined as

^self view controlDispatch

(Actually, it's defined as ^xtremeCommandBarsControl, a variable that
holds a reference to self view controlDispatch).

When I step through with the debugger, I can see that the call to
getClientRect in the auto-generated interface class fails with a
"primitive failure" specifically at the invocation statement, and we get
back nil(s).

Dolphin generated the following:

XtremeCommandBars_DCommandBars>>#getClientRect

        "Invoke the GetClientRect() method of the COM object."

        | answer |
        answer := (Array new: 4)
                                basicAt: 1 put: VARIANT new;
                                basicAt: 2 put: VARIANT new;
                                basicAt: 3 put: VARIANT new;
                                basicAt: 4 put: VARIANT new;
                                yourself.
        (self invokeId: 8 withArguments:
                        ((Array new: 4)
                                basicAt: 1 put: (answer basicAt: 1);
                                basicAt: 2 put: (answer basicAt: 2);
                                basicAt: 3 put: (answer basicAt: 3);
                                basicAt: 4 put: (answer basicAt: 4);
                                yourself)).
        ^(answer collect: [:each | each asObject])

We were careful to establish proper context (or so we think).  We
instantiate the XtremeCommandBarsPresenter on a particular model (the
one we've been using to test all of the other features), and then send
various messages to it to create menus, command bars, change the visual
theme, etc.  Everything seems to be working well, and now we've moved on
to testing #getClientRect.

Is there something we should know about when dealing with these kinds of
calls?

Cheers,

Eric

"Eric Taylor" <[hidden email]> wrote in message
news:003f01c6902a$c95c66a0$6500a8c0@server...
> Hello Forum,
>
> I've searched the archives for insight into ActiveX calls where the
> arguments are designated as "out" (in other words, the call will return
> values to the addresses of the arguments, but no values are expected as
> inbound.

Generally there should be no problem with this, although it must be said
that the majority of our test cases (and the majority of controls) use dual
interfaces, rather than dispinterfaces, so there are more likely to be
undetected problems with the latter.

>
> In testing GetClientRect() of our XtremeCommandBars ActiveX control, we
> seem to be having trouble getting this method to execute....

Yes, there appears to be a bug in the type library analyzer here. In order
to make it work you will have to modify the
XtremeCommandBarsPresenter>>getClientRect methods as below, not forgetting
to remove it from the '**autogenerated**' category once you have done so.
Since you are modifying it, you might as well go for the second form, which
will be more efficient since you won't need a further wrapper and it
minimises the number of objects created.

Regards

Blair

-----------------
!_DCommandBars methodsFor!

getClientRect
 "Invoke the GetClientRect() method of the COM object."

 | answer |
 answer := (Array new: 4)
    basicAt: 1 put: SDWORD new;
    basicAt: 2 put: SDWORD new;
    basicAt: 3 put: SDWORD new;
    basicAt: 4 put: SDWORD new;
    yourself.
 self invokeId: 8
  withArguments: answer.
 ^answer collect: [:each | each asObject]! !
!_DCommandBars categoriesFor: #getClientRect!methods!public! !

---- or ------

!_DCommandBars methodsFor!

getClientRect
 "Answer a <Rectangle> specifying the client area co-ordinates of the
command bar."

 | left top right bottom |
 left := SDWORD new.
 top := SDWORD new.
 right := SDWORD new.
 bottom := SDWORD new.
 self invokeId: 8
  withArguments: (Array
    with: left
    with: top
    with: right
    with: bottom).
 ^Rectangle
  left: left value
  top: top value
  right: right value
  bottom: bottom value! !
!_DCommandBars categoriesFor: #getClientRect!methods!public! !

Blair,

Brilliant!  That was it.  Since there are several methods in the Xtreme
suite that take this approach, I'll be on the lookout.

Thanks very much.

Cheers,

Eric
return
> > values to the addresses of the arguments, but no values are expected
as
> > inbound.
>
> Generally there should be no problem with this, although it must be
said
> that the majority of our test cases (and the majority of controls) use
> dual
> interfaces, rather than dispinterfaces, so there are more likely to be
> undetected problems with the latter.
>
> >
> > In testing GetClientRect() of our XtremeCommandBars ActiveX control,
we
> > seem to be having trouble getting this method to execute....
>
> Yes, there appears to be a bug in the type library analyzer here. In
order
> to make it work you will have to modify the
> XtremeCommandBarsPresenter>>getClientRect methods as below, not
forgetting
> to remove it from the '**autogenerated**' category once you have done
so.