- Feb 14, 2005--- In firstname.lastname@example.org, "Dennis K. Paulsen"
> In the latest CVS builds of Win32::GuiTest/GuiTest.xs, the windows
> hook (WH_CALLWNDPROC) is *part* of the puzzle we use, so that we
> interface with various 32bit custom controls, marshall data backDennis,
> from these controls, etc...
> For example, with a ListView32 control we can't simply just issue a
> call to ListView_GetItemText() to read an item's text, because of
> the process boundary limiation, you'll normally end up getting an
> access violation because your accessing data outside of the
> processes address space...
If I understand you correctly, hooking solution (in Win32::GuiTest)
works as follows:
For each control related operation (like getting ListView32 contents)
a hook is set, so the actual list processing is run in address space
of the process which hosts this control.
This solution is correct (it is used by Richter in his book) but I
think it brings some maintainability problems. Expanding
Win32::GuiTest for handling new controls would reguire changes in .xs
file and recompilation.
I believe I have found more flexible solution. Have a look:
http://www.mathimagics.com/TechNote001.html, "Cross-process buffers"
section. The full example with the code can be found here:
In short, instead of hooking, the solution uses VirtualAllocEx
function. This function allocates memory is other process's address
space. So what you do is this: you allocate memory in address space
of a process, which hosts a control. You get pointer to this memory.
Then, you call Send/PostMessage passing this pointer. Control will
respond writting to proper address space.
If we manage to create a consistent interface to this functionality,
we will deliver a mechanism to handle new controls without writing
any new C code.
PS: What is WM_LV_GETTEXT, WM_LV_SELBYTEXT and so on in HookProc?
Both google and MSDN did not return anything.
- << Previous post in topic Next post in topic >>