--- In [email protected], "Sheri" <sheri...@...> wrote: > > Ugh, that's a shame. I was working on more demos that demostrate there is > still a problem with "t " for skipping. > > Using Excel from Office 2003 and COMplugin0.72_100114 shows there is still an > issue. > ' VB Script: TestSkipOptional.vbs
....(snip)..... > When the plugin runs the CheckSpelling method and one of the optional > parameters is specified (and not typespec'ed as "t ") in CheckSpelling > method, it works properly. But if the objective is to skip that argument, it > doesn't work. A typespec of "t " is clearing out the correponding property > value instead of using and retaining the prior existing value. So my question > is, how exactly are you processing what should be a skipped optional > parameter? Are you sending one of those special VT_Error Variants as > described here: <http://support.microsoft.com/kb/238981> ? Yes, but what I'm not doing is fetching the default value, if there is one. Time to reinstate that I think. My guess is that's exactly what happens if you omit a trailing argument, i.e. provide fewer arguments than are possible (wihtout benefit of typesepc). What happens when you do that? > Here is the Powerpro version of above scriptlet. Maybe you can try it on > another box with a later version of Excel? No, sorry. Wouldn't be any use, cause to fix problem I've got to have by compiler and debugger available. You'll have to find another COM server we can both run. > Something else I tried (which further demonstrated that it wasn't using the > existing default dictionary) was adding HAX to SLP_PPROTest.dic. Even when > not ignoring all caps, that should cause a True result when spellchecking > "HAX" with skipped CustomDictionary. True in VBScript, False in Powerpro. > Yes, I had thought of trying to mimic the Indesign type problem with digits > for the dictionary name string. I even try making the typespec send "i " or > "l " for it and sending 1111. Currently no error gets generated for that. > Interrogating the XLApp.SpellingOptions.UserDict afterwards even returns the > digits. Yeah, I found that too..but at least I can watch it in debugger and see whether it does the guessing sequence correctly.
