--- In [email protected], "Sheri" <sheri...@...> wrote: > > --- In [email protected], "entropyreduction" > <alancampbelllists+yahoo@> wrote: > > > > Sorry to here ill. Get well soon. > > Thanks, its been a rough few days but I do feel better today.
Good. > I played with set_arg_types a bit and liked it. Using it persistent before > looping that Search method in the InDesign script allows the InDesign Search > function (using dot syntax) to work fine with ANSI arguments (including where > some vector values happen to be digits that need to be sent as string to > VARIANT in-arguments). Also good. I haven't tested "t" == optional yet. > I think the most objectionable thing about getting com exceptions is that > there is generally no clue of what's gone wrong. If I deliberately send a > number to the VARIANT argument using vbscript I get an error message from > InDesign: > --------------------------- > Windows Script Host > --------------------------- > Script: C:\Documents and Settings\Sheri\My > Documents\TestCC206\PowerProData\scripts\TestIndesign.vbs > Line: 11 > Char: 1 > Error: Invalid value for parameter 'For' of event 'Search'. Expected > String, but received 123. > Code: 800A770D > Source: C:\Program Files\Adobe\Adobe InDesign CS2\InDesign.exe > > --------------------------- > OK > --------------------------- > > I've noticed other erroneous things gracefully handled in vbscript that done > with PP/com script either crash Powerpro or give exceptions. Crashes obviously something I've done wrong -- probably forgotton to release some of the zillions of structures that should be released before getting rid of an IDispatch. > Some research reveals suggests the possibility to query for an error object > when invokes return. Have a look at IErrorInfo both at msdn and > <http://www.devguy.com/fp/Tips/COM/> and see if of any value. Invoke on an IDispatch looks like HRESULT Invoke( DISPID dispIdMember, REFIID riid, LCID lcid, WORD wFlags, DISPPARAMS FAR* pDispParams, VARIANT FAR* pVarResult, EXCEPINFO FAR* pExcepInfo, unsigned int FAR* puArgErr) I send in both &ExcepInfo and &uArgErr, but they never seen to come back with anything but NULL. > > I found what might have caused a false error message in previous > > version. Will compile change when I get home next week (snow > > permitting). > We had uncommonly much deep snow here in December. Another light dusting this > week. You're DC area, yes? Not normally snowed on? We got six-eight inches in Brighton, which is plenty to stop the buses and leaves road more or less unusable. Thaw coming in a few days. > I guess it remains to be seen if the addition VT_VARIANT|VT_BYREF will be > useful or not. I've though of a reason why using VT_VARIANT|VT_BYREFs might lead to the kind of crashes you were describing. I need to find out what happens when you VariantClear a VARIANT containing a pointer (which any VARIANT with vt including VT_BYREF wound). If VariantClear takes it upon itself to free the thing pointed to, my code as is will probably crash. [five min later] http://msdn.microsoft.com/en-us/library/ms221165.aspx No, doesn't free. Back to drawing board. ------------------------------------ Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/power-pro/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/power-pro/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
