--- In [email protected], "brucexs" <[EMAIL PROTECTED]> wrote: > > > > But I should include an interface to any service that returns a > result. > > > > Do you mean should _not_ include...? I don't understand what the > following list is supposed to represent. > > Specifically, functions that should be included would be stuff like > IsRolled etc (since window handles are global).
> But should not be included would be alloctemp (since it returns > address).. But neither is on attached list, so I am not sure what it > is. Anyway, why would anyone in another process want access to allocated memory in PP process that would never know when to deallocate itself? > > I'm left with at least > > GetStaticVarAddr > > GetVarAddr I'd use those simply to tell if a variable exists; would not return address, just 0/1. > > SetStaticVar What's problem there? Same argument as SetVar below? > > GetVarSize Or there? Not very interesting though. > Above involve addresses so I agree would not work without some kind > of extra help. > Actually, you could still return the address as a 32 bit value, but > then to set something at the address, you'd have to call a service in > the plugin running in the powerpro space (through copydata) and pass > this address. Good idea. > You could do alloctemp that way too, I think. Ditto > > SetVar > says it returns lpstr but I don't think it does return anything? > Since it sets by name, it should be ok. > > > GetCurrentDir > > > > > MatchCaption > > returns bool so should work > > > FindMatchingWindow > > returns windows handles (which SendMessage call could return) so > should work. > > > EvalExpr > > > > Any I've missed? > > > > I'll either provide a pipe and require a listening pipe in using > > process, or send WM_COPYDATA messages back and forth. > > NOt quite sure how you synch these so that asker gets response after > asking the question .. a fun challenge. I guess multithreading? Probably. If I do WM_COPYDATA messages, I guess receiving window proc in external process probably has gotta be on it's own thread. > BTW, note that getwindowtext works across process boundaries, > although I think returned text is at most 80 chars. PowerPro Context > menus actually use this hack to send data to explorer process (by > setting window caption of main powerpro window -- not the bar, the > main, hidden window!). Interesting. Though I expect most services I'm looking at that copy text need to be able to send unlimited-ish amounts. > Also, I've always wondered whether handles returned by globalalloc > are really system global (since they are used for clipboard etc). > (If they were, sendmessage could return globalhandle to allocced > memory with result). Hmm. Interesting. Will look into it. Probably more efficient that WM_COPYDATAing largish amounts of data.
