The attached demo project below shows how to duplicate the textual contents of another ListView control, even if it's from another process (32-bit processes only).
EDIT
Here's the updated version from Post #4:
Printable View
The attached demo project below shows how to duplicate the textual contents of another ListView control, even if it's from another process (32-bit processes only).
EDIT
Here's the updated version from Post #4:
Nice. I finally figured out that you need to hold F12 down while moving the mouse over another LV.
Works fine with explorer's LV.
I added
If hWndLV = ListView1.hWnd Then Exit Sub
to the CloneListView routine to keep it from reloading when you move the cursor over the form's LV.
Thanks!Quote:
Originally Posted by VBClassicRocks
The F12 key can be replaced with any other key by changing the GetAsyncKeyState(vbKeyF12) line.Quote:
Originally Posted by VBClassicRocks
I've just tested it with Explorer's windows in Win 7 and unfortunately, it could not retrieve any text. Although, the Desktop items can be enumerated. I've yet to fully investigate this issue.Quote:
Originally Posted by VBClassicRocks
Yeah, I forgot that. Thanks!Quote:
Originally Posted by VBClassicRocks
I'll most likely be updating this again when I have managed to figure out how to retrieve the header control's captions and maybe the icons as well.
As promised, attached here is the updated version. I, however, have decided not to copy the items' icons anymore because it turned out to be more complicated than I thought.
After a bit more testing, I found out that the List View control used in Win 7's Explorer windows had the classname "DirectUIHWND". It does not seem to respond as expected to some of the List View messages I've sent to it.Quote:
Originally Posted by Bonnie West
Windows Vista's Explorer windows, on the other hand, still uses the old List View classname, as can be seen in the screenshot below:
You know. Some reason this doesn't work on 64bit OS
Is the target process 64-bit? If so, it really won't work because pointers in VB6 are just 32 bits wide. That code dim's a few pointers that points to some allocated memory on the target process. There's nothing I can do about it, I'm afraid. If the target process however, is 32-bits, at which line does that code fail?Quote:
Originally Posted by brandoncampbell
It's Windows property for security groups listview.Quote:
Originally Posted by Bonnie West
That code is probably being denied access because the dialog box where the ListView is located was likely created by an elevated process. Try running that code as administrator. If you still encounter additional issues, please provide more details next time.
your post #4 is similar to what I am trying to do. It will not pick up whats in the list on Windows 7 64bit
As I've already explained, pointers in 32-bit and 64-bit processes have different sizes. That code uses a few pointers and it won't be able to access any memory address beyond 4 GB. Sorry, but I don't think there's anything I can do about it.Quote:
Originally Posted by brandoncampbell
Bummer.. I needed this again today and decided to revisit it. It's funny because it builds the list columns without the text and even enters the amount of list entries without the text. So I guess it is reading the listview fine.. just not the text that's there.Quote:
Originally Posted by Bonnie West
Unfortunately, that's just the way it is; 32-bit and 64-bit processes don't play well together especially when pointers and memory addresses are involved.Quote:
Originally Posted by brandoncampbell