XYplorer Beta Club

dgw wrote:If I understand this correctly, its exactly what I came here looking for.

I have a dozen of so shortcuts that open network folders. With win explorer, the folder is the top of the tree in the tree view, there is no tree expansion going on.

The address bar displays something like this:
\\fileshare01\folder1\folder2\folder3\folder4
and folder4 is the top entry in the tree view.

The shortcut command looks like this:
%windir%\explorer.exe /e,/root,"\\fileshare01\folder1\folder2\folder3\folder4"
Have you decided to include this in an upcomming version?
Note also that fileshare01 is not a mapped drive.

You can try out the effect of AST by using this script (simply paste into the Address Bar and press Enter):
::autosynctree 0
This will turn off the Tree and make browsing to those network folders very fast.

However, it might not be what you are looking for...

Cool!
If that is something I should have been able to find in the Help, then sorry I didn't find it myself.

Now, I can put the network path in a category and it works except of course the tree view doesnt change. With hundreds of servers on the network this is lots better for me.

Is there a way to run a shortcut command like this
%windir%\explorer.exe /e,/root,"\\fileshare01\folder1\folder2\"

using XYplorer instead of explorer? The above command opens a new explorer window with folder2 at the top of the tree.

Hi dgw,

there was another thread about setting the root of the tree (not possible yet in XY). Maybe this one answers some more questions you might have about the tree:

http://www.xyplorer.com/xyfc/viewtopic.php?t=1500

Thanks for the reference. ryanagler is talking about the same thing i am doing.
I personally like a second instance of explorer because I do some stuff in the folder or sub folders, maybe copy files between the two instances, and then close the second one. I have all the shortcuts on a Toolbar so they are easy to get at when I need them because I might go to them multiple times per day.

In any case, the autosynctree script helps, but I would also vote for the 'make root' concept mentioned in that other thread.

I need to examine the boxed branch feature as well, I haven't looked at that yet. I haven't looked at scripts either.

dgw wrote:Cool!
If that is something I should have been able to find in the Help, then sorry I didn't find it myself.

Now, I can put the network path in a category and it works except of course the tree view doesnt change. With hundreds of servers on the network this is lots better for me.

Is there a way to run a shortcut command like this
%windir%\explorer.exe /e,/root,"\\fileshare01\folder1\folder2"

using XYplorer instead of explorer? The above command opens a new explorer window with folder2 at the top of the tree.

This "feature" is not documented anywhere so you could not find it. I still want to collect some user feedback before I raise it to a more available level. So, thanks for your feedback!

Nevertheless, it works well and it is saved between sessions just like XYplorer's official settings are.

For your situation there's the following solution:
- have a 2nd XYplorer "installation" (= a 2nd XYplorer.exe in another folder)
- configure it to: hide nav panel ( F8 ), and turn off the tree (::autosynctree 0)
- call it with the startpath as command line parameter, e.g.: C:\XYplorer2\XYplorer.exe "\\fileshare01\folder1\folder2"
- (you can easily have these call commands as UDCs or Catalog entries in your main XYplorer setup)

Now you can do your drag+drop jobs from/to a wide file list only pane, and close it again.

I just wanted to say I really like using this feature in my scripts because it makes them run 'cleaner' (for lack of a better word). Thanks!!!!

autosynctree 0;
autosynctree 1;

eurytos wrote:I just wanted to say I really like using this feature in my scripts because it makes them run 'cleaner' (for lack of a better word). Thanks!!!!

Good to know!

Well, especially now that it's "completely official" I'd like to point out a few things that, I believe, should be adjusted :

* For starter, instead of a command of its own (autosyntree) I think this should be implemented as a new argument for command setting, so that whena script uses it the user setting might be restored, instead of forcing him to either sync or not the Tree.

* I also think we may have a problem with a few features/commands that rely on the Tree's focused item, and not the current location. For examples, those :
- Toggle Favorite Folder
- Toggle Highlighted Folder (or command highlight)
- Toggle Boxed Branch (or command box)

jacky wrote:Well, especially now that it's "completely official" I'd like to point out a few things that, I believe, should be adjusted :

* For starter, instead of a command of its own (autosyntree) I think this should be implemented as a new argument for command setting, so that whena script uses it the user setting might be restored, instead of forcing him to either sync or not the Tree.

* I also think we may have a problem with a few features/commands that rely on the Tree's focused item, and not to the current location. For examples, those :
- Toggle Favorite Folder
- Toggle Highlighted Folder (or command highlight)
- Toggle Boxed Branch (or command box)

setting: yes, makes sense.

Okay, those are tree related functions and they apply to the Tree's focused item (if no item is selected). As long as this is clear, there should be no problem. Rewriting them to apply to the current location would not make much sense IMO -- if a user is interested in highlighting the tree, then he should use the tree. A touch better would be to disable them while the tree is off. But I don't know... A user that works with tree turned off should be able to handle this without pampers.

admin wrote:Okay, those are tree related functions and they apply to the Tree's focused item (if no item is selected). As long as this is clear, there should be no problem. Rewriting them to apply to the current location would not make much sense IMO

Okay, sure.

But then, I would ask if highlight & box (the script commands) could support an optional extra parameter <folder> so that one could set a folder's highlight/boxed branch without to go there with Tree's sync.

jacky wrote:

admin wrote:Okay, those are tree related functions and they apply to the Tree's focused item (if no item is selected). As long as this is clear, there should be no problem. Rewriting them to apply to the current location would not make much sense IMO

Okay, sure.

But then, I would ask if highlight & box (the script commands) could support an optional extra parameter <folder> so that one could set a folder's highlight/boxed branch without to go there with Tree's sync.

Is on my list anyway...

admin wrote:

jacky wrote:

admin wrote:Okay, those are tree related functions and they apply to the Tree's focused item (if no item is selected). As long as this is clear, there should be no problem. Rewriting them to apply to the current location would not make much sense IMO

Okay, sure.

But then, I would ask if highlight & box (the script commands) could support an optional extra parameter <folder> so that one could set a folder's highlight/boxed branch without to go there with Tree's sync.

Is on my list anyway...

Done! See next version...

admin wrote:Done! See next version...

Excellent! Thanks, will have to update a few scripts that will now run even faster!

BTW I still haven't had time to check the latest version, but I see some new statusbar messages, which reminds me: recently you changed to use the green "checked" sign instead of the blue arrow. I think this was a mistake in some cases, where the message is actually a "progress indication", not a completion one.

Of course I can't remember any example now, but it happens... Oh yeah, CFS might be the case! I think it shouldn't be the green icon while XY is actually working, and calculating folder sizes should be like running a search : working, so blue arrow.

It's not much, but it's confusing/odd to see a sign that visually states "ok, done" while the message is "please wait, I'm working" (At least it is to me.)

(Also, for the sake of it, a new param on status command to tell which icon to use might be nice, too.)

jacky wrote:

admin wrote:Done! See next version...

Excellent! Thanks, will have to update a few scripts that will now run even faster!

BTW I still haven't had time to check the latest version, but I see some new statusbar messages, which reminds me: recently you changed to use the green "checked" sign instead of the blue arrow. I think this was a mistake in some cases, where the message is actually a "progress indication", not a completion one.

Of course I can't remember any example now, but it happens... Oh yeah, CFS might be the case! I think it shouldn't be the green icon while XY is actually working, and calculating folder sizes should be like running a search : working, so blue arrow.

It's not much, but it's confusing/odd to see a sign that visually states "ok, done" while the message is "please wait, I'm working" (At least it is to me.)

(Also, for the sake of it, a new param on status command to tell which icon to use might be nice, too.)

Yep, correct. I improved the icon situation a bit.

Param for icon: nice idea.