--- In [email protected], "entropyreduction"
<alancampbelllists+ya...@...> wrote:
>
> --- In [email protected], "Sheri" <sherip99@> wrote:
> >
> > >
> > > But what about
> > >
> > > local appRef = com.create_object("Excel.Application")
> > > local hCell = appRef.ActiveWorkbook.Worksheets(1).Cells(1, 1).value
>
> > If those arguments are all in the typelib as "VARIANT" then I'm
> > sure it would also work if you were sending them all as integers,
> > for noguess.
>
> The point is: the hypothetical but possible case where they are
> all VT_VARIANT, and one at least of the parameters is poorly
> handled and must be something besides a VT_I8 or VT_I4.
>
> In that case, multiple type_specs are required; a single
> type_spec without persistence will die after being used for
> worksheets(1), and if persistent will be appropriate for
> worksheets(1) but not for Cells(1, 1).
Was there an actual test failing test involving worksheets/cell (can't
remember) ?
local appRef = com.create_object("Excel.Application")
appRef.workbooks.Add
appRef.ActiveWorkbook.Worksheets(1).Cells(1, 1)="Hello Alan"
local hCell = appRef.ActiveWorkbook.Worksheets(1).Cells(1, 1).value
win.debug(hCell)
appRef.quit
com.release_all
com.unload
quit
Above actually works quite nicely now. However, if you remove the
appRef.workbooks.Add (and no workbooks are open) you see that we've lost the
error trapping that appRef.Activebook failed. In early test versions that
crashed, then you caught it and reported an error, and now it just ignores the
error.
>
> Another situation where multiple type_specs would be handy:
>
> ;assume all parameters to com services are declared VT_VARIANT
>
> com.set_arg_types("i s ", "s i ", 1)
>
> for (;;)
> aServer.methodB(1, 2) ;; only works if supplied with VT_I4, VT_BSTR
> aServer.methodA(1, 2) ;; only works if supplied with VT_BSTR, VT_I4
> ; etc
> endfor
>
I would suggest:
for (;;)
aServer.methodB(1, unicode.new(2)) ;; only works if supplied with VT_I4,
VT_BSTR
aServer.methodA(unicode.new(1), 2) ;; only works if supplied with VT_BSTR,
VT_I4
; etc
endfor
> com.set_arg_types() ;; turn off persistent type_specs
>
> Try it now.
>
> Try COMplugin0.72_100208.zip
>
> This one guesses all VT_VARIANT parameter types first (usual caveats, accept
> unicode, com, real handles as what they are, no guessig if type_spec in force)
>
> If invoke fails with guessed params, and reason is a parameter type error,
> and parameter type in question was guessed, retries with the offending
> parameter a string. Continues until all guessed parameters converted back to
> strings
>
> set_arg_types("guess"/"noguess") no longer there; instead
> set_arg_types("retry"/"noretry") no longer there; retry is default, trun off
> above described
>
> So if you don't want all the retrying to happen, you can turn it off.
>
> Can turn off from config ini file as well, see docs (rtf only).
>
> I can't find a case in any of my servers where a number doesn;t
> work, but guessing provides one. Could you try your
> Search(333,...) method again please? And it you can find a
> similar service that I can run so I can step the retry code,
> would be helpful.
With retry enabled, it doesn't make it "work" per se, but now it gives a
comprehenible error message related to the correct parameter. This is miles
better than an undifferentiated "com exception" or forcing the error to migrate
to the wrong parameter as happened in some of the previous test versions.
I currently have VS6 available. Is there is any single stepping I could do for
you with Search method, and collect results?
Regards,
Sheri
