ActiveX interface bug

When I generated the IDispatch subclasses for VS FlexGrid I found some
problems with some of the methods which were generated.

Heres an example of what was automatically generated:
VSFlex7LIVSFlexGrid>>cell: setting row1: row1 col1: col1 row2: row2 col2:
col2 pVal: pVal

"Set the 'Cell' property of the receiver to the <variant> value of the
argument. Helpstring: 'Returns or sets cell properties for an arbitrary
range.'"

self
  put_Cell: setting
  Row1: VARIANT new
  Col1: VARIANT new
  Row2: VARIANT new
  Col2: VARIANT new
  pVal: pVal asVariant

whereas what was needed was:

 self
  put_Cell: setting
  Row1: row1 asVariant
  Col1: col1 asVariant
  Row2: row2  asVariant
  Col2: col2  asVariant
  pVal: pVal asVariant



Looking at the IDL



  [id(0x0000009e), propget, helpstring("Returns or sets cell properties for
an arbitrary range."), helpcontext(0x000027d9)]
  HRESULT __stdcall Cell(
   CellPropertySettings Setting,
   [optional] VARIANT Row1,
   [optional] VARIANT Col1,
   [optional] VARIANT Row2,
   [optional] VARIANT Col2,
   [out, retval] VARIANT* pVal);
  [id(0x0000009e), propput, helpstring("Returns or sets cell properties for
an arbitrary range."), helpcontext(0x000027d9)]
  HRESULT __stdcall Cell(
   CellPropertySettings Setting,
   [optional] VARIANT Row1,
   [optional] VARIANT Col1,
   [optional] VARIANT Row2,
   [optional] VARIANT Col2,
   [in] VARIANT pVal);
  [id(0x0000009e), propputref, helpstring("Returns or sets cell properties
for an arbitrary range."), helpcontext(0x000027d9)]
  HRESULT __stdcall Cell(
   CellPropertySettings Setting,
   [optional] VARIANT Row1,
   [optional] VARIANT Col1,
   [optional] VARIANT Row2,
   [optional] VARIANT Col2,
   [in] VARIANT pVal);

 ---The same problem shows in some other commands as well.  Its easy enough
to fix manually, but would be worthwhile fixing for the next release.

--Regards
   Gary Overgard

Gary

You wrote in message news:a1sp6d$7ih$[hidden email]...
> When I generated the IDispatch subclasses for VS FlexGrid I found some
> problems with some of the methods which were generated.

Thanks for your report.

>
> Heres an example of what was automatically generated:
> VSFlex7LIVSFlexGrid>>cell: setting row1: row1 col1: col1 row2: row2 col2:
> col2 pVal: pVal
> ....

Hmmm, it seems to be because some of the parameters are not marked as either
in or out. The reverse engineered IDL (by Dolphin, OLEView goes into an
infinite loop on this component's typelib) is:

HRESULT __stdcall Cell(
    CellPropertySettings Setting,
    [optional] VARIANT Row1,
    [optional] VARIANT Row2,
    ...
    [out, retval] VARIANT* pVal);

I don't recall ever having come across this before in testing, and it is not
handled
correctly by the type-library analyzer. It seems that it means "Whether the
parameter passes or receives information is unspecified." I'm not sure
whether, in general, such parameters should be treated as in only, or
in-out, or whether one is supposed to somehow deduce this from the type of
the parameter (!). In this case they are clearly intended to be input
parameters. Anyway the attached should get you going, and we'll review it
further for 5.0.

Regards

Blair

--------------------------
!PARAMDESC methodsFor!

isIn
 "Answer whether the receiver is describing an input argument.
 Note that it is possible for the direction not to be specified, in which
case one
 must assume both."

 | flags |
 flags := self wParamFlags bitAnd: ##(PARAMFLAG_FIN|PARAMFLAG_FOUT).
 ^flags == PARAMFLAG_FNONE or: [flags anyMask: PARAMFLAG_FIN]

! !
!PARAMDESC categoriesFor: #isIn!public!testing! !