--- In [email protected], "Sheri" <sheri...@...> wrote:
>
> plugin services should not be affected by set_arg_types. Currently
> get_object_description no longer works if preceded by a set_arg_types
>
> e.g.
>
> com.set_arg_types("lv",1)
> win.debug(appRef.ActiveDocument.TextFrames.get_object_description("fdnpt",
> "Item"))
>
> Error dialog shows......<snip>......
I can't replicate. Using comPlugin0.72_100126.zip
Try comPluginDemoExcelSheri.powerpro
......<snip>......
; not needed, Cells arguments are variants, but guessing works in
; this case com.set_arg_types("i i ")
objSheet.Cells(i, 2) = "Number "++ i ;; .Value
......<snip>......
>
> FYI without the set_arg_types this:
>
> win.debug(appRef.ActiveDocument.TextFrames.get_object_description("fdnpt",
> "Item"))
>
> Debugs:
> TextFrames
> Text Frames
> get property: IDispatch* = Item(IN VARIANT index) (DEFAULT)
I'll see if I can find something equivalent using some server I got access to.
> Following works in COMplugin0.72_100121
>
> local myselect= ;;+
> appRef.ActiveDocument.TextFrames.get_property_typed("Item", ;;+
> "iv", 5)
> win.debug("i", com_status, com_type)
>
> Also works with "lv" instead of "iv", btw.
>
> Same expectation for dot syntax fails:
> com.set_arg_types("iv",1)
> local myselect=appRef.ActiveDocument.TextFrames.Item(5)
Sure: l is long, i is 2 byte signed int. Both will work for small numbers.
>
> com_status is nonetheless "OK". Per the itypeinfo shown it should be
> returning an object, IDispatch*:
>
> get property: IDispatch* = Item(IN VARIANT index) (DEFAULT)
>
> When using get_property_typed, the com_type is Text Frame. In dot format, no
> com_type is returned.
Think I fixed lack of error message when method fails.
> Regarding guessing, ...
>
> Some methods with VARIANT input can accept either a string or number, but if
> its a number, needs to be treated as a number. So should not be guessing
> string for a number. A handle to an object also should not be guessed to be a
> string.
Yeah, I cover that. Handles to anything (real numbers, unicode strings, com
objects) are made into the appropriate COM equivalent, erro reported if there's
available typeinfo or type_spec that contradicts.
> This error shows that the com plugin handle is being sent as a string when
> guessing is in effect:
Hopefully fixed that. Can;t test, obviously.
> ERRORS: com.method: Invoke failed
> Error 770d:
> from: C:\Program Files\Adobe\Adobe InDesign CS2\InDesign.exe
> Invalid value for parameter 'SelectableItems' of event 'Select'. Expected
> Object, Array of Objects, idNothingEnum enumerator or idSelectAll enumerator,
> but received "c_3005".
>
> When guessing is turned on, and you invoke a method with no arguments
> specified, no VARIANTs should be sent for any optional parameters. I think if
> there is a persistant set_arg_types in effect, it may now be sending VARIANT
> formatting empty strings.
Nope, that's not the way it works. You provide a type_spec with four args,
four args will be expected, and they better be convertable to tpyes indicated
in spec.
If there's a mismatch between number or args and type_spec arg count, it's an
error, or should be.
> IMO there should be one good guess if there is no typespec in effect. If
> typeinfo for the method or property is specific, the specific type.
> Otherwise, the guess should be driven by the content of the arguments. We
> should have a way to designate booleans, maybe "~TRUE~" and "~FALSE~".
> Numbers are numbers. Objects are objects. Unicode handles are strings. If
> none of the above, string. If multiple guessing is enabled, there should only
> be multiple invokes if you know which parameter is in error. Do not
> arbitrarily send all strings.
Sorry, makes sense to send all strings. A properly written server should cope.
And it's what I got available, and guessing is error prone (e.g. your Search
method with a "333" argument).
Speed is an issue at the moment for methods
with lots of VARIANT parameters that don't eat strings but which return
per-paramter error info. Probably no big issue for a single call, but repeat
calls could be a problem. I can, eventually, speed things up by cacheing stuff
discovered abut params, so if you call the same method on smae object again (in
a loop, typically), won't have to rediscover all that stuff. If you want fast,
use a type_spec.
I'm speculating that lots of servers only get tested with languages that have a
native number vs a native string type, so coders forget to use the standard
variant conversion routines.
