Ok, I hope I can explain this one, it seems a bit tricky.
I have a display of hundreds of files that I need to remove from a Vault directory. I don't know any intelligent way to do it, so I set out to it the monkey way (I mean, have the human -- me -- do the monkey work of peering at one screen and typing what it says into another screen).
I alt-tab back and forth between the two screens, the one with the list of files I need to delete, and the other being the Vault GUI.
But, I ran into this problem -- repeatedly, because I kept thinking that I must be miskeying somehow.
In Vault GUI, I click the first one to delete, then shift down arrow 3 times, which gives me the first four selected, which are the first four to delete.
Then I alt-tab to the list, see the next two, alt-tab back, and see that the next two are the next two adjacent to my highlighted list. So I shift-down twice more. *BUT* now it loses the four I had selected before
As mentioned, I did this several times, thinking that I must be clicking the wrong thing somewhere, but it happens every time, so now I think it is the software, not me?
I think there is a workaround involving the mouse, but it will probably be tedious (I say that because anything repetitive that requires the user to use the mouse is usually painful, at least in my experience). I'm not quite sure yet.
Client Information
Vault Client Version: 3.1.8.3771
.Net Framework Version: 1.1.4322.2032
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
shift-down bug after alt-tab
Moderator: SourceGear
workaround and a feature request (complaint)
Yeah, there is a workaround with the mouse -- tedious, but not as bad as I expected:
You have to shift click each item, and you have to keep resisting the temptation to shift-down of course, as that will ruin all your work.
Feature request (complaint): In the list of files deleted, I keep using keyboard to select the ones as I get them entered into the Vault selection (shift-down works in that application). It shows me the running total. But the Vault GUI doesn't show me how many are selected, so I cannot sanity check using that number.
You have to shift click each item, and you have to keep resisting the temptation to shift-down of course, as that will ruin all your work.
Feature request (complaint): In the list of files deleted, I keep using keyboard to select the ones as I get them entered into the Vault selection (shift-down works in that application). It shows me the running total. But the Vault GUI doesn't show me how many are selected, so I cannot sanity check using that number.
workaround fails!
Darn! I was wrong -- shift-mouse-click also loses the selection list
But, ctrl-shift-mouse-click and ctrl-mouse-click work correctly.
So you MUST avoid shift-mouse-click (it will throw away everything), and use ctrl-shift-mouse-click and ctrl-mouse-click.
But, ctrl-shift-mouse-click and ctrl-mouse-click work correctly.
So you MUST avoid shift-mouse-click (it will throw away everything), and use ctrl-shift-mouse-click and ctrl-mouse-click.
It seems when Vault is losing / gaining focus the last highlighted item switches to the first highlighted item.
For example, click the third item in a group of files. While holding down shift, click the fifth item. Items 3, 4, and 5 are now selected. Next lose focus / gain focus on the Vault client. While holding shift, click the 8th item. Now 5, 6, 7, and 8 are selected.
While this is not standard Windows behavior, I believe Vault is letting the .Net framework handle these events.
In any case, I'll log the report.
Thanks.
For example, click the third item in a group of files. While holding down shift, click the fifth item. Items 3, 4, and 5 are now selected. Next lose focus / gain focus on the Vault client. While holding shift, click the 8th item. Now 5, 6, 7, and 8 are selected.
While this is not standard Windows behavior, I believe Vault is letting the .Net framework handle these events.
In any case, I'll log the report.
Thanks.
Jeff Clausius
SourceGear
SourceGear
Another way to handle this would be set the option to not automatically commit operations, then delete the files one at a time, which will put them in your pending change set instead of immediately committing each one.
Once you have deleted all the files, commit them from the pending change set, and they will all be deleted in a single operation on the server.
Once you have deleted all the files, commit them from the pending change set, and they will all be deleted in a single operation on the server.
Yes, jclausius described the bug exactly
> It seems when Vault is losing / gaining focus the last highlighted item switches to the first highlighted item.
Yes, that is exactly the bug.
I use multiselect listview & listbox so much that I know the behavior by instinct, and have trouble thinking how to describe it. This is exactly the bug!
This whole thing is worsened by the other bug I reported, that Vault GUI acts like its dead when you alt-tab back to it.
Yes, that is exactly the bug.
I use multiselect listview & listbox so much that I know the behavior by instinct, and have trouble thinking how to describe it. This is exactly the bug!
This whole thing is worsened by the other bug I reported, that Vault GUI acts like its dead when you alt-tab back to it.
re: workaround [I think this conflicts with another outstand
re: workaround
There used to be a bug in Vault -- that I've been assuming is still present -- that if you mark some files for delete, then you alt-tab away to find some more, then come back and mark them, and if you have already hit the delete before you alt-tabbed away, so that the ones already picked are in the pending list, then if you accidentally pick any of the same ones again, that (a) there is no visual cue in the select tree to guide you as to which ones are already pending for delete and (b) if you do pick any of them it will fail -- and then it is really easy to lose everything after the failure, I think, due to this exact bug that this thread is about.
There used to be a bug in Vault -- that I've been assuming is still present -- that if you mark some files for delete, then you alt-tab away to find some more, then come back and mark them, and if you have already hit the delete before you alt-tabbed away, so that the ones already picked are in the pending list, then if you accidentally pick any of the same ones again, that (a) there is no visual cue in the select tree to guide you as to which ones are already pending for delete and (b) if you do pick any of them it will fail -- and then it is really easy to lose everything after the failure, I think, due to this exact bug that this thread is about.