Grabbing Listview

[trids]

Hi Devs

Just wondering what the official status is on interacting with Listviews?

According to this thread, it seems like Jon and Larry support it, and Larry has even provided a link there that, while it is a bit beyond my comprehension, seems to promise the solution.

I don't want to sound like I'm nagging, cos i'm not; but I would similarly hate to create the impression that there is no interest in this area.

I wish I could provide some resources myself, but all I have to offer is encouragement and some eager testing.

[Jon]

Hi Devs

Just wondering what the official status is on interacting with Listviews?

According to this thread, it seems like Jon and Larry support it, and Larry has even provided a link there that, while it is a bit beyond my comprehension, seems to promise the solution.

I don't want to sound like I'm nagging, cos i'm not; but I would similarly hate to create the impression that there is no interest in this area.

I wish I could provide some resources myself, but all I have to offer is encouragement and some eager testing.

I'll have a go as my next "thing" after the OnExit stuff. What is a good program to test with, and what sort of functionality should I aim for?

[Jon]

This is actually looking fairly straightforward. The hard part will be shoehorning it into the ControlCommand function I think I can use some commands starting LV... or TV... to make it easier for me to split up the ControlCommand code (which is massive...)

[trids]

Cool - thanks Jon!!!

Apps

My own use of it is mostly for scripted testing of apps written for my customer in VB6, which use the listviews (and treeviews) in MSCOMCTL.OCX or COMCTL32.OCX ( ):

In these apps, the controls appear as follows under AutoItSpy..

MSCOMCTL.OCX

• ListView = ListView20WndClass1
• TreeView = TreeView20WndClass1

COMCTL32.OCX

• ListView = ListViewWndClass1
• TreeView = TreeViewWndClass1

Another place is in the McAffee VirusScan Console, where AutoItSpy sees listviews as SysListView321. And MS Outlook uses a SysTreeView321

Functionality

Personally, I would like to first of all be able to get back the text of the currently selected node/listitem. And it would be a very close second to be able to select a predefined node/listitem, based on a text value that I provide. And as for Listviews, it would be just awesome to be able to read the subitems of a given listitem (they appears as "columns").

Others may have further ideas though

[Jon]

Hmm, that may have just thrown a spanner in the works. The code and messages I've got are for the standard SysListView32 SysTreeView32 controls. It's entirely possible (and likely) that once I've done all that it won't work for the other controls you mentioned - for all we know they may have different internals and respond to different messages...

I'll see if I can get some text back from a listview and then you can test it out.

[trids]

Oops - let me take my spanner back then .. Whatever works for the greater good: From what I've seen, most folks have to deal with the SysListView. So anything more than that would be a bonus.

[Jon]

I've got new ControlCommand options LV_GetItemCount and LV_GetItem working for SysListView32 so far.

GetItem has two params, item and subitem. So i've managed to read things like the filename and filesize in the "details" view in explorer.

Edited August 23, 2004 by Jon

[trids]

Awesome ... and you might like to play with Regedit.exe too, I see it also uses SysListView and SysTreeView.

I was thinking, to activate a treeview node, perhaps we can specify the node hierarchy like this (notice how we can specify the node delimiter)...

$sNodeTarget = "HKEY_CURRENT_USER\Software\VB and VBA Program Settings\EZFormat,\"

ControlCommand($sTitle, "", "SysListView321", "SelectNode", $sNodeTarget)

[Jon]

I'll concentrate on the listview for now.

I've got the following working in ControlCommand (I'll post a snapshot tonight when I get home):

LV_GetItemCount (get the number of list items)

LV_GetSubItemCount (get the number of sub items/columns)

LV_GetItem (Gets the text of a item/subitem based on an index value)

LV_GetSelectedCount (Gets the number of items that are selected)

Happy so far?

Now, it gets tricky from here. I can easily work out the items that are selected, but how to return the information? An array of indexes, or text, or both? Hmm, a 2D array of indexes and text seems to give everything we need

What about selecting, how to specify mulitple items?

I've added an additional parameter to ControlCommand so there is room for extra parameters to acheive the above.

I think this will be a nice "starter" for listview interaction and once it's up and running I'm sure lots of requests for additions will be made.

Edited August 23, 2004 by Jon

[trids]

Sounds very very good!

What about selecting, how to specify mulitple items? 

<{POST_SNAPBACK}>

.. well, from VB, you can get/set a boolean property of the ListView called .MultiSelect. When this is TRUE, then every time you set a listitem's .Selected property to TRUE, it doesn't unselect any other listitems.

As I understand it, the MSCOMCTL etc "controls" are actually wrappers (or subclasses?) for the SysListView32 and SysTreeView32 .. so maybe it also has a .MultiSelect that you can exploit?

[trids]

Hmmm .. I wonder if I can explain that another way :">

If the app that hosts the SysListView has switched ON the .MultiSelect property, then several consecutive item-selects would accumulate a bunch of selected items. This analogises to a CTRL-Click in Windows Explorer.

But if the host app has switched OFF the .MultisSelect property, then each item-select is automatically accompanied by a de-select of any previously selected items.

I believe this is a feature of the control, and how the host app sets its .MultiSelect property. So it should not affect your interfacing with the SysListView, as you can simply let the control itself take care of multi-selects depending on what its .MuliSelct setting is.

Hope that makes more sense?

[Jon]

Hope that makes more sense?

I don't think I've any problem with writing the code to do this, what I meant was how does the autoit user specify what items they want to select?

Say they wanted to selected items 1,2,3 and 7

Control...... "selectclear"
Control...... "select", 1
Control...... "select", 2
Control...... "select", 3
Control...... "select", 7

or

Control...... "selectclear"
Control...... "select", 1, 3
Control...... "select", 7

or

Dim $sel[4]
sel[0] = 1
sel[1] = 2
sel[2] = 3
sel[3] = 7
Control...... "select", $sel

or

Control...... "selectclear"
Control...... "select", "1,2,3,7"

or

Control...... "selectclear"
Control...... "select", "1-3,7"

And so on...

Edited August 24, 2004 by Jon

[trids]

.. ok, i see what you mean.

Well, here's my vote (( .. in order of preference )):

Control...... "selectclear"
Control...... "select", 1
Control...... "select", 2
Control...... "select", 3
Control...... "select", 7

<{POST_SNAPBACK}>

I like this one by far the most: "less is more", "simplicity is key" etc etc. But if pushed for further options, I would choose delimited strings over arrays ..

Control...... "selectclear"
Control...... "select", "1,2,3,7"

or

Control...... "selectclear"
Control...... "select", "1-3,7"

<{POST_SNAPBACK}>

[Jon]

Hmm, ok. The reason I had other suggestions was that because the control commands have window title and text and controlid in each one that would be a massive overhead. Say if you wanted to select 200 items it would incur 200 window and control searches. That may take a few seconds.

Maybe i'll add another command that just sets up the control to use and then create a ControlCommand2() function that is the same as ControlCommand except it works on the last specified control and lacks the window/control parameters so that if you are working with a control lots of times in succession you would avoid the overhead of searching each time.

[trids]

.. You mean like getting the hWnd for the control, and then using that in all subsequent interaction for it? Sounds like a neat idea!

[Valik]

Jon, wouldn't it make more sense to let the scripter have access to the control's HWND, then modify ControlCommand() to accept an HWND (This mode could be grandfathered into "WinTitleMatchMode" 4 so that the user also has no excuse not to provide the HWND for the target window, as well).

Edit: Errr, I meant modify all Control-related functions to take also take a control's HWND.

Edited August 24, 2004 by Valik

[Jon]

Jon, wouldn't it make more sense to let the scripter have access to the control's HWND, then modify ControlCommand() to accept an HWND (This mode could be grandfathered into "WinTitleMatchMode" 4 so that the user also has no excuse not to provide the HWND for the target window, as well).

Edit: Errr, I meant modify all Control-related functions to take also take a control's HWND.

I was thinking about it but I thought it was still a bit cumbersome with the whole "handle=" thing going on.

I've had another idea, that now that I can add another datatype to the variant class I could easily add a HWND type and then modify the window/control commands to check if a window title/control is given as a handle and if so use it directly (rather than looking for a "handle=0xblah" string). The problem that gives me is that AutoItX can't cope with it and I'd have to still implement the handle= version

So many choices

[Jon]

I've got HWND handles working pretty well I must say:

$handle = WinGetHandle()

WinClose($handle)
or
WinClose("handle=" & $handle); in mode 4

Same with control:

$handle = ControlGetHandle("title", text", "control")
ControlSend("", "", $handle, "blah")
or
ControlSend("", "", "handle=" & $handle, "blah")  ; in mode 4

So that gives great handle handling in autoit (no longer need to use the handle= syntax) and an OK workaround for AutoItX.

When you use a control handle it doesn't bother reading the window title/text it just gets the parent window of the control (used internally in control functions)

Edit: In effect the GetHandle() functions return proper HWND handles (rather than strings as they did previously). I've just made it so if you try and use the handle as a string (for output or use in handle=) that it converts it to a string on the fly. Neat, eh? Glad I rewrote the variant class now. Should be able to do similar for date/binary/whatever types

Edited August 25, 2004 by Jon

[Valik]

Very cool changes, Jon.

[bigred]

I wanted to show my continued interest in this feature. My current project needs to interact with a "SysListView32#".

The things I need to do with them are, copy all the items in the list, select items based on a string, or the list item based on its number(position) in the list.

Also I'd need to get the number of items, as well as the ability to add an item to the list.

Also from my point of view, this one make the most sense. As Trids said, less is more.

Control...... "selectclear"
Control...... "select", "1,2,3,7"

I was also thinking that the ability to state only the items you don't want to select could be useful.

Control...... "selectclear"
Control...... "unselect", "3,12"