crash on activex call

I am getting a crash following a call to XL_Worksheet>>usedRange: if the a
cell in the spreadsheet is being edited.  Instead of crashing, the operation
should raise the exception 'HRESULT Error: Call was rejected by callee.'. It
seems to be crashing while handling this exception.

The error log is attached. There are 2 entries. The 1st one is from a previous
operation and is the normal result (call was rejected) of an operation on a
range while the spreadsheet is being edited (I think this is during an inspect
of a range).

The 2nd entry is the one which is being written at the time of the crash. It
only gets as far as logging:

3:28:25 PM, Sunday, February 24, 2002: Unhandled exception - a HRESULTError

The next thing to be written would have been
('HRESULT Error: Call was rejected by callee. (FACILITY_RPC)')...

Here is a test case to reproduce it:

excel := XL_Application new .
excel visible: 0 rhs: true .
"Now in Excel:
- click new worksheet
- type xyz (xyz is entered into A1. dont press enter)
- now continue evaluating "
sheet := XL_Worksheet newPointer .
excel get_ActiveSheet: sheet .
sheet := sheet downCast.
range := sheet usedRange: 0

This crashes D4 also.


--------------------------------------------------------------------------------

3:26:59 PM, Sunday, February 24, 2002: Unhandled exception - a
HRESULTError('HRESULT Error: Call was rejected by callee. (FACILITY_RPC)')

XLRange(ExternalStructure)>>hresultError:
XLRange(IDispatch)>>invokeId:flags:parms:retVal:
XLRange(IDispatch)>>invokeId:flags:parms:
XLRange(IDispatch)>>getPropertyId:
XLRange>>parent
XLRange>>{unbound}doIt
CompiledExpression>>value:
SmalltalkWorkspace>>evaluateRange:ifFail:debug:
SmalltalkWorkspace>>evaluateRange:ifFail:
SmalltalkWorkspace>>displayIt
Symbol>>forwardTo:
[] in Command>>value
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Command>>value
FlipperInspector(Shell)>>performCommand:
CommandQuery>>perform
DelegatingCommandPolicy(CommandPolicy)>>route:
[] in ShellView(View)>>onCommand:
BlockClosure>>ifCurtailed:
----------------------------------------------------------------------------------------------------

3:28:25 PM, Sunday, February 24, 2002: Unhandled exception - a HRESULTError

Alan

You wrote in message news:0155PJpSyhjQUvIHno+t3s=[hidden email]...
> I am getting a crash following a call to XL_Worksheet>>usedRange: if the a
> cell in the spreadsheet is being edited.  Instead of crashing, the
operation
> should raise the exception 'HRESULT Error: Call was rejected by callee.'.
It
It is crashing because you are creating an invalid interface pointer, and
you are then calling through a vtbl which does not match the object's. The
ActiveSheet property is defined as returning an IDispatch. You shouldn't
therefore be retrieving it into an Xl_Worksheet interface pointer.

You may think the #downCast would fix this, but #downCast is designed for
casting down from IDispatch to the derived interface. It asks the object for
type information (through IDispatch), and _if_ it gets any attempts to cast
down to the more specific interface _if_ it finds a match in Dolphin. If
there is no typeinfo, or no matching interface, #downCast answers 'self', as
if to say "Sorry, but this is the most specific interface". #downCast is
working on the assumption that the interface you send it to is of the right
class in the first place. Since it isn't in your code, you still end up with
the wrong type of interface pointing at the object, and therefore when you
attempt to call through it it blows up.

Replace the last steps of your test with:

sheet := excel activeSheet.     "Note that the result is an IDispatch, as
specified in the type library"
sheet := sheet downCast.     "Note that the result is still an IDispatch"
sheet typeInfo.                "You'll get a 'no type information available'
walkback"
range := sheet usedRange: 0.    "You will get the HRESULTError you expect"

Alternatively:

sheet := excel activeSheet queryInterface: Xl_Worksheet.
range := sheet usedRange: 0.

I don't know why the IDispatch value of the ActiveSheet property refuses to
supply type info, but because it does #downCast is unable to do anything,
therefore it is necessary to manually query off the desired interface.

In summary, this is not a bug in Dolphin, but in your code. I don't want to
discourage people from reporting bugs, but please do try to be reasonably
sure before reporting bugs here that it really is a bug in Dolphin and not
in your application.

Regards

Blair

Blair,

I'm sorry, I had assumed it was the type of error that could be trapped
instead of taking down the task. The code I posted works fine when the
spreadsheet is not being edited so I just assumed it was correct.

Thanks for the solution.

Regards,
Alan

On Mon, 25 Feb 2002 10:56:07 -0000, "Blair McGlashan" <[hidden email]>
wrote:

ps, actually I wrote that code to get the active sheet a while ago. I think I
was trying to coerce it to a worksheet instead of an IDispatch because some
other calls on the worksheet were failing going thru DNU on the IDispatch. So
your 2nd alternative works best.

an interesting peculiarity is that

sheet := excel activeSheet queryInterface: XL_Worksheet.
sheet usedRange:0

raises the exception but with

sheet := excel activeSheet queryInterface: XL_Worksheet.
range := sheet usedRange: 0.
range address

the exception is not raised until the #address method.

regards,
Alan

ps and fyi,  I just found out that inspecting an XL_Worksheet would make a
very good unit test for the 'flipper chirps'/ #646 problem :)

lets try that again

On Mon, 25 Feb 2002 14:31:26 -0500, Alan Reider
<[hidden email]> wrote:

>ps, actually I wrote that code to get the active sheet a while ago. I think I
>was trying to coerce it to a worksheet instead of an IDispatch because some
>other calls on the worksheet were failing going thru DNU on the IDispatch. So
>your 2nd alternative works best.
>
>an interesting peculiarity is that
>
>sheet := excel activeSheet queryInterface: XL_Worksheet.
should have read:

sheet := excel activeSheet.

"Alan Reider" <[hidden email]> wrote in message
news:[hidden email]...
That might be to do with the way you are evaluating the code? If you use
"Display-It", as opposed to "Evaluate-It", then the printing code might be
causing the exception.

Regards

Blair