--- In [email protected], "Sheri" <sheri...@...> wrote: > > > (a) Something fancier, essentially taking same type_spec argument > > as the _typed servicies, could be done, easily, but not sure it > > would have any point: it would only be relevant for a particular > > invoke, so it gets clumsy 'cause you'd have to call it over and > > over for every different metod/put/get. > > > > (b) I wonder if in the nest for info 9one can extract about an > > IDispatch there isn't something that tells you the type of each > > parameter of a function (pTypeInfo->GetNames gets names of those > > parameters, so far haven't found if their types are published). > > (b) sounds nice, the others I wouldn't bother with.
Doable. See comPlugin0.72_091202.zip in http://tech.groups.yahoo.com/group/power-pro/files/0_TEMP_/AlansPluginProvisional/ run comPluginDemoScriptFileSysObjDotSyntaxForEach.powerpro Notice function descriptuions. Each parameter of known type. So, I can determine the type of every parameter from ITypeInfo (got it here: http://spec.winprog.org/typeinf2/) So, all the _type services are now unnecessary. Stay tuned, will take a while to sort out, among other things what to do with trailing VARIANT parameters. > Another idea might be something along of the lines of optional tagged > arguments, where the tag is a typespec prefixed and suffixed by some obscure > control characters. e.g., > > appRef.Search("\x05sv\x05"++mysearch,"\x05bv\x05"++wholeword, ;;+ > "\x05bv\x05"++casesensitive, "\x05sv\x05"++myreplace) > > If an argument doesn't start with the control character, do what is done now, > "guess" at the type. Hopefully stuff exposted by FUNCDESC structs will do the job. > > Don't know why that's so. contents is defintely supposed to > > return a BSTR? > > win.debug(myselect.contents, "***"++com_type++"***") > > shows that com_type is "string" Okay. How about comPluginDemoScriptFileSysObjDotSyntaxForEach.powerpro. Working? > myselect.contents continues to debug as ANSI despite enabling unicode > returns, and any high characters show as question marks. Still? > > > > > Although Powerpro auto-localcopy does work when sending a com > > > > > handle to another Powerpro function, what I really want is to > > > > > return a local handle via quit(handle). Using > > > > > v=com.localcopy(appRef), if I quit v, it is the string "OK". If I > > > > > quit(appRef), when I try to use it on the other end I get ERROR: > > > > > com.method: Object handle, isn't. Can just avoid locals. > > > > > > > > Sounds like another error in localcopy. Will check later. > > > > What happens if you use > > > > Function xxx(appRef) > > (no call to localcopy) > > .... > > quit(appRef) > > > > comPlugin0.72_091201.zip: fixed localcopy (if it was broken: > > comPluginDemoScriptFileSysObjDotSyntaxForEach.powerpro has a > > Function testLocalCopy, which seems to work okay, and did work > > okay, so dunno what was happening there) > > Will play with that later, but sounds strange to call xxx with appRef when > xxx is going to create appRef using com.create_object. Yeah, misunderstood. But try this; local xvec = funcTest() win.debug(xVec[0], "length: ", xVec.length, "exists: ", xVec.exists) quit Function funcTest() local bVec = vec.create(50) bVec[0] = "23" quit(bVec) Same problem, yeah? If so, take it up with Bruce: he may be able to prevent locals from getting deleated if they're mentioned in a quit statement.
