XYplorer Beta Club

I just had an unpleasant experience.

1. Select an item from the Catalog for display in the list. Finish desired task in the list.
2. Invoke the Go To Application Folder command.
3. Invoke the Backup To... UDC.
4. Observe that the XYplorer folder in the tree has focus but is not selected, and therefore the selected Catalog entry gets backed up instead of the desired XYplorer folder.

I think that if a "Go" command is executed, that the selection should automatically follow the focus. Else why would I "Go"?

So is this a bug or a FAD (Functioning As Designed)?

-Jeff

Jeff Bellune wrote:4. Observe that the XYplorer folder in the tree has focus but is not selected, and therefore the selected Catalog entry gets backed up instead of the desired XYplorer folder.

hmm.. I think you got your words mixed up there. The current location/folder is selected on Tree, but the Tree does not have the focus, is what you mean.

Just a reminder, and I'll try to be as clear as possible to avoid any confusion :

You always have one item selected on Tree, whether it is focused or not. There can't be more than one selected item.
Apart for "special cases" (right-click, drag&drop, etc), focus & selection go together.

You can have none, one, or more selected items on List, whether or not it is focused. If the List has the focus, there will always be one (and only one) item focused (unless List is empty), this focused item may or may not be one of the selected items. (See here for more)

The Catalog can have no selected item (I think, when not "full"), although it usually has one item selected all the time (little arrow on the left). There can't be more than one selected item.
Apart for "special cases" (drag&drop, not right-click though here), focus & selection go together.


Ok, and back on topic :

Jeff Bellune wrote:I think that if a "Go" command is executed, that the selection should automatically follow the focus. Else why would I "Go"?

When you Go somewhere, regardless of the way used, I think that the focus stays where it is, which I think is (to me) the expected behavior.

So if the focus was on Catalog, it'll stay there. If it was on Tree, List or Adress Bar it'll stay there as well. The only exceptions I can think of right now are :

- Going to a file will focus the List, as the file gets selected & focused on List

- The very nice INI Trick SetFocusToListAfterCatalog=1 which will set the focus to the List after using a Catalog item (regardless of its action : Go To, Open, etc)

So I'd say this one was a "FAD".

I think you got your words mixed up there. The current location/folder is selected on Tree, but the Tree does not have the focus, is what you mean.

Yes. I see now why that is true, and how the UI is telling me that.

When you Go somewhere, regardless of the way used, I think that the focus stays where it is, which I think is (to me) the expected behavior.

So if the focus was on Catalog, it'll stay there. If it was on Tree, List or Adress Bar it'll stay there as well.

Is this because you give the user an "anchor" so that they don't get lost? If not, how would you use the Go commands in your workflow so that it is better not to shift the focus to the tree (if going to a folder) or the list (if going to a file)?

The very nice INI Trick SetFocusToListAfterCatalog=1 which will set the focus to the List after using a Catalog item (regardless of its action : Go To, Open, etc)

Depending on your answers to my other questions, what do you think of a wish for an INI entry: SetFocusToTreeAfterCatalog?

-Jeff

Jeff Bellune wrote:Is this because you give the user an "anchor" so that they don't get lost? If not, how would you use the Go commands in your workflow so that it is better not to shift the focus to the tree (if going to a folder) or the list (if going to a file)?

Well, I think it may depends on people and how they work. For instance, you seem to want to have the Tree focused, while I personally am all about the List. Even when I go to a folder, I want the List to get focus, because for me the List is that start of it all, where things happen(, most of the time).

Another thing that the focus not being changed can allow is something like this : Hit Ctrl+F and start defining yorr search criteria. Then, you realize you're not in the right place and wishes to go there first. Hit Ctrl+G, enter path, and after enter XY goes there but the focus is still on the field on the panel. Something that some user may find useful...

Jeff Bellune wrote:

The very nice INI Trick SetFocusToListAfterCatalog=1 which will set the focus to the List after using a Catalog item (regardless of its action : Go To, Open, etc)

Depending on your answers to my other questions, what do you think of a wish for an INI entry: SetFocusToTreeAfterCatalog?

Well, if you like it better that way it would sure sound like a fair wish, but let me just remind you that this only affects Catalog, so going to another location using another way, like UDC, Go to (Ctrl+G), Address bar or, as in your first post, Go to App Folder, would NOT be affected, so regarding ths issue in your first post, the focus would not have ben switched to Tree (since you didn't use a Catalog item to go there).

Maybe, there could be another INI trick to define where the focus shoud be sent after a "Go to" command is triggered (regardless of how: Catalog, AB, Goto, UDC, etc). It could be nothing (left where it is, as it does now), Tree, List, Catalog, Address Bar.

But, such a thing could get tricky depending on how the "Go to" is actually used internaly, like when clicking on Tree/dbl-clicking on List (or pressing Enter)

Plus, would you really want to have the focus move to Tree even with all other features life Hotlist, Breadcrumb, Up, etc ? I'm guessing those might be relying on the "Go to" feature as well...

PS: With the new/coming scripting, you'll now be able to define a different UDC that will first focus the Tree (one of the Misc CKS command), and then start your current Backup To UDC, thus ensuring that the focus is always where it's supposed to be ! Isn't that great?

Another thing that the focus not being changed can allow is something like this : Hit Ctrl+F and start defining yorr search criteria. Then, you realize you're not in the right place and wishes to go there first. Hit Ctrl+G, enter path, and after enter XY goes there but the focus is still on the field on the panel.

This is a very good example of why the focus should not switch automatically. Thank you.

PS: With the new/coming scripting, you'll now be able to define a different UDC that will first focus the Tree (one of the Misc CKS command), and then start your current Backup To UDC, thus ensuring that the focus is always where it's supposed to be ! Isn't that great?

Hooray! But I have to file a bug already (right after I finish this post). The Backup To... UDC doesn't work using the numbered script command from the Catalog. When it gets to a working state, I can use the script feature to create a Catalog entry or UDC that does what I need.

BTW, how would you create a scripted UDC? Except for the "Go To" command, I couldn't do it. I tried to put a "Go To" and a "Focus Tree" script-numbered command preceding the folder location in the Backup To location field and it didn't work.

However, a "Go To" command that incorporates the Go To/Focus Tree/Backup To scripted commands *does* work.

-Jeff

Jeff Bellune wrote:BTW, how would you create a scripted UDC? Except for the "Go To" command, I couldn't do it.

I suspect this might be because Scripting is still a work-in-progress, and based on past history, Don sometimes implements things in stages so we can verify it works better and make suggestions that may affect remaining coding.

Jeff Bellune wrote:BTW, how would you create a scripted UDC? Except for the "Go To" command, I couldn't do it. I tried to put a "Go To" and a "Focus Tree" script-numbered command preceding the folder location in the Backup To location field and it didn't work.

Well, I hadn't tried it, and it seems that with UDC for Move/Copy/Backup To it doesn't yet work flawlessly after a focus command, indeed.

But remember that this is still a "beta feature" that isn't fully implemented yet, and still a work in progress. So it might not work today, but Don is working on it and once finished it sure will !

I assumed I was doing something wrong, which is why I asked.