Copies paths incorrectly when on tree view, having been in list view

[GoogleCodeExporter]

Steps to reproduce the problem:
1. Select a folder in the tree view (eg C:\Program Files)
2. Tab into list view and select a folder (eg StExBar within C:\Program Files)
3. Tab back to tree view and invoke Copy Paths (eg C:\Program Files again)

Expected output would place "C:\Program Files" in the clipboard, rather
than "C:\Program Files\StExBar"!

Using v1.6.1 in WIndows XP SP3

Original issue reported on code.google.com by mprice....@gmail.com on 13 May 2009 at 9:46

[GoogleCodeExporter]

At least on Vista, tabbing to the tree view still leaves the selection in the 
list
view intact (and the list view itself too), even if you change the selected 
tree item
(with the cursor keys).
Only pressing enter will change the selection.

Also, there's no way (at least I haven't found one) to find out whether the 
tree view
has focus or not.

Original comment by tortoisesvn on 14 May 2009 at 6:11

[GoogleCodeExporter]

On WinXP too, tabbing to the tree view leaves the selection in the list view 
intact
(but typically greyed rather than highlighted), but actions like double-click 
and
right-click will operate on the folder rather than the file(s) and/or folder(s) 
in
the list view.  I think if you change the selection in the tree view and
pause/hesitate for a fraction of a second the new folder is displayed - the 
Enter key
does not need to be pressed (distinct difference from WinVista).

I'll have a bit of a poke myself, but I can see the sort of problem you face. 
Interestingly enough in AutoHotkey, I can tell which control (the tree or list 
view)
currently has the focus, but I'm not sure I can reliably get the path (as users 
don't
have to turn on the "full path in caption" or "full path in address bar" 
options.

My underlying reason is that I'm trying to use TortoiseProc (the whole 
TortoiseSVN
product is great by the way) by keyboard from WinExplorer.  I grew up using a
keyboard rather than a mouse...!  All too often I've been working on a few 
files and
then want to "step back" and consider the status of the whole folder or want to 
start
committing all changes in that folder.  Maybe the real solution is for 
TortoiseSVN to
provide configurable accelerators naturally rather than trying to bolt them on 
(by
StExBar or AutoHotkey)...

Original comment by mprice....@gmail.com on 15 May 2009 at 5:03

[GoogleCodeExporter]

My problem is that the shell interfaces don't reveal where the focus is or that 
the
tree control has the focus. I can't even see a way to get the info from the 
tree view.

You can check the code here:
http://code.google.com/p/stexbar/source/browse/trunk/StExBar/src/ExPaths.cpp
None of these interfaces have a method I could use (I tried even IOleWindow and
comparing the HWND handles).

If you have any ideas, please tell me!

Original comment by tortoisesvn on 15 May 2009 at 7:43

[GoogleCodeExporter]

Matthijs Hollemans's article on CodeProject
(http://www.codeproject.com/KB/shell/wildcardselect.aspx) may offer a clue (I'm 
not
up for C++ changes at this time).

In his source code, wildcardselect.zip\CtxMenu.cpp\QueryContextMenu() method, he
calls ::GetFocus() and then calls ::GetClassName(wnd, wndClass, MAX_WNDCLASS) 
and
compares the wndClass result to see if it's SysListView32 or not, but I suspect 
that
it could be compared with SysTreeView32 - I know it's not very "interface", but 
it
might give the correct answer...

Original comment by mprice....@gmail.com on 26 May 2009 at 9:56