Aciivex problem passing double*

I am trying to call a method on an IDispatch subclass which is defined as
follows:

getRecDouble: nRecord fIx: fIx pdVal: pdVal
        "Answer the <VARIANT_BOOL> result of invoking the COM Object's
GetRecDouble() method."

        ^(self invokeId: 27 withArguments:
                        ((Array new: 3)
                                basicAt: 1 put: nRecord;
                                basicAt: 2 put: fIx;
                                basicAt: 3 put: pdVal;
                                yourself))

this is defined in the control as:

bool GetRecDouble(RECIX r, FLDIX f, double* pv) const;

parm1 and 2 are integers. My call is:

answer := VARIANT new.
self getRecDouble: 0 fIx: 1 pdVal: answer


This results in a message: HRESULT Error: Type mismatch.

Am I specifying the answer parameter correctly?

"ar" <[hidden email]> wrote in message
news:[hidden email]...
No. Try:

answer := DOUBLE new.
...etc...

BTW: If the control supports a vtable-based (or dual) interface as well as
the dispinterface, then I recommend you use it since:
1) It will be much more efficient (perhaps an order of magnitude faster).
2) Dolphin will generate better wrapper methods that make it easier to use.
This is especially so if the IDL from which the type library was generated
(assuming it was generated from IDL) was well written, sadly not always the
case.

Regards

Blair

Blair,

Thank you, changing to DOUBLE worked.

I'm doing a lot of timing tests now based on your BTW and that is generating
some questions.

1. is there a sampling profiler for Dolphin available?

2. it appears that this control doesnt support dual. (I opened an
AXTypeLibraryAnalyzer on it and #dualInterfaces returned empty).
But assuming it did how would I choose it over disp? Eg, how would I use the
vtable call on Excel which appears to support dual interface?

3. my Excel cell updates are a real dog:

cellAt: colInt at: rowInt put: aValue
        | loc |
        loc := self xlAddress: colInt row: rowInt .
        (self app range: addr cell2: addr )  "app is the xl application control"
                value: aValue asVariant

xlAddress: aCol row: aRow
        ^(self convertColumn: aCol) asString , aRow  printString

convertColumn: anInteger
        "this would break for column 'AA' etc.."
                ^'ABCDEFGHIJKLMNOPQRSTUVWXYZ' at: anInteger

I think in VB you can just say something like Cell(x,y) = aValue . Is there
any way to avoid building the range, and the (x,y) to 'A1' conversion?
Something with properties? I think there must be a way to use integer
coordinates.

On Thu, 17 Jan 2002 19:38:15 GMT, ar <[hidden email]> wrote:

correction

>cellAt: colInt at: rowInt put: aValue
> | loc |
> loc := self xlAddress: colInt row: rowInt .
> (self app range: addr cell2: addr )  "app is the xl application control"
> value: aValue asVariant

should have been

cellAt: colInt at: rowInt put: aValue
        | loc |
        loc := self xlAddress: colInt row: rowInt .
        (self app range: loc cell2: loc )  
                value: aValue asVariant

thats what i get for editing code for posting without testing it.

> 1. is there a sampling profiler for Dolphin available?

There's a free goodie available on my web site that provides a sampling
profiler for Dolphin. It could do with a bit of a tidy up and some
enhancements e.g. the minimum sampling interval is 1 millisecond which is a
bit too long for current processors, but it works reasonably well.

http://www.iandb.org.uk

If you feel like a bit (lot?) of work then, as far as I know, David Jones'
"Svengali" profiling tools are still available. These were the original
profiling and monitoring tools for Dolphin (David was part of the original
development team) but they weren't actively maintained after Dolphin Version
1. I did update them a couple of times but gave up after Dolphin 3 when the
differences became a bit too much to handle with any confidence.  There are
links to them from the OA web site (and in the documentation for my
profiler) so if you want to update/rewrite them I wouldn't think David would
complain too much - you should obviously check with him first.

Regards
    Ian