--- In [email protected], "Sheri" <sheri...@...> wrote: > > > Yes, no guessing if VT_VARIANT in typelib: or if you supply a > > typespec code for param. > I don't understand. I think you mean no guessing if typelib has specific > types instead of VARIANT.
All parameters sent with COM methiods/accessors (and results returned by them) are packaged as VARIANTs. A VARIANT is a structure, one of which is vt, an enum VARTYPE, what the variant contains. Saying a parameter is a VARIANT is shorthand for "a VARIANT of type VT_VARIANT", which means the recipient is entering into a contract to accept any type of data. Obvious many servers don't fulfill that contract. > > > > > Strings might be tricky <http://www.devguy.com/fp/Tips/COM/#BSTR> > > > > > > > > I use I use ::SysAllocString(L""): CComBStr(L"foo") would destroy > > > > itself too soon. > > > > > > Maybe that is because you had failed to copy it into a VARIANT using > > > CComBStr.CopyTo ! > > > > In which case might as well just use SysAllocString. > My reading of the docs is, they warn against doing that very thing. My reading is that there's no problem, as long as I clean up with SysFreeString or a VariantClear. Send me links that say otherwise. CComBSTR is an ATL wrapper around BSTR. I'm not using ATL, unless I have to; just adds a layer of complexity. Make sure the docs you're ready are dealing with COM API level code, not ATL code. One can get in trouble mixing the two. > > > Then when the BStr goes out of scope it will destroy itself, but > > > the cargo for the VT_BSTR will survive. > When a VARIANT with VT_BSTR no longer needs the length-prefixed-wide-string > it sees as its cargo when the BStr has been properly created using CComBStr > and properly planted in a VARIANT using CComBStr.CopyTo, the BStr cargo is > automatically destroyed when the VARIANT is released. VariantClear automatically releases anything contained within it, including BSTRs. > > COMplugin0.72_100121.zip: not much tested, but you can play. > > > > added > > com.set_arg_types("guess") > > com.set_arg_types("noguess") > > config ini key guessArgTypes=1 (default 1) > > > > If guessing on, on failure does the one-param-at-a-time thing if > > Invoke fails with DISP_E_PARAMNOTFOUND or DISP_E_TYPEMISMATCH, > > guesses at all that need it if its DISP_E_EXCEPTION. > > InDesign script is totally broken and now abysmally slow regardless of > whether guessing is on or off. > > This line should certainly work: > appRef.Select(appRef.ActiveDocument.TextFrames.Item(5)) > > with "guess", gets this error: > > 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". > > with "noguess", gets this error: > > ERRORS: com.method: Invoke failed > Error 770b: > from: C:\Program Files\Adobe\Adobe InDesign CS2\InDesign.exe > The requested member of the collection does not exist. > > The first invoke needs to be smarter. Is it sending VT_something for VARIANT > arguments? Or is it not bothering with CComVariant? Can't diagnose something I can't run. Find some examples in Excel/Word/FSO or some such. > Also, we've recently lost this error trapping, now its just letting it fly: > ;referring to Excel ActiveSheet w no Workbooks open > local mysheet=xlapp.ActiveSheet > Jan 15 version com_status is ERRORS: com.method: Invoke failed > Jan 18 version com_status is ERRORS: com.method: Invoke failed (sys code 1: > "Incorrect function.") > Jan 20 version com_status is "OK" > Jan 21 version com_status is "OK" Will look into it next week.
