--- In [email protected], "entropyreduction"
<alancampbelllists+ya...@...> wrote:
>
> --- In [email protected], "Sheri" <sherip99@> wrote:
>
> > com.set_arg_types("iv",1)
> > local myselect=appRef.ActiveDocument.TextFrames.Item(5)
>
> local myselect=appRef.ActiveDocument.TextFrames.Item(5)
> and
> local myselect=appRef.ActiveDocument.TextFrames(5)
>
> May or may not be designed to work in version you have at the
> moment. I believe way I had it was that "iv" was meant to apply
> to _every_ method/accessor that followed, and that would include
>
> appRef.ActiveDocument
>
> which of course would fail
>
> Ok, I guess I can relax rules about set_arg_types so it's ignored
> for any following method/accessor that has no arguments, if if
> non-persistent only dies after the first method/accessor with
> args.
Good. Evidenced by example at the bottom of this message.
>
> 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.
>
> (I'm impressed with Bruce's parsing: the last works).
local myselect=appRef.ActiveDocument.TextFrames.Item(5)
works in previous release versions of the plugin.
The only reason it needs a typespec now is to avoid sending it as a string. You
have no control over what happens in the black-hole of the remote procedure
call. In this case, when sent as a string, IT TAKES 30 SECONDS ! before it
comes back and says "no such item". Aside from the interminable delay, there IS
such an item. 5 was intended as the index, not the name of the desired Item.
Here's the help sring for Item property: Returns the TextFrame with the
specified index or name as Long or String
>
> Okay, looks like I gotta go one more step, and allow
> set_arg_types to have multiple type_specs.
>
> The last arg, if
> present and 1/0 is persistence flags, all the rest are
> type_specs. type_specs consumed in order, one for each
> method/accessor with arguments. If persistence in force, when
> last type_spec consumed, go back and start over with first.
>
> Very easy to screw up in a script, and very hard for me to error
> check (I have no way of telling, for instance, whether a
> particular method/accessor and its args are in a chain or stand
> on their own).
>
> ?
>
That sounds awful. It would be far more productive to improve the recognition
of what the user intended instead of asking the user to take over the job of
typesetting. We have (or it at least had) a solution for the rare situations
where the user wants a number treated like a string: put it in a unicode
handle. That recently stopped working btw, but I think it is due to getting
re-guessed at some point since there are multiple VARIANT args in that service.
Following gave me a good laugh but concerned me. r.count is the culprit.
ERRORS: com.method: Alan is an idiot and made a programing error
makeVarParamOpt: m_vtParamType should be VT_EMPTY
Error occurred near line 205 Repl_for_Indesign:
logfile.writeline(" "++r.count++" Replacements Processed "++
formattime("hh:mm:ss", time))
"makeVarParamOpt" suggests it is for an optional parameter. None intended or
even possible for count, but the error was somehow triggered because a
persistent typespec was in effect.
Also your doc file refers to VT_EMPTY for optionals. Optional parameters are
supposed to be VT_ERROR (10) with special Scode, not VT_EMPTY (0).
<http://www.marin.clara.net/COM/variant_type_definitions.htm>
Regards,
Sheri
