XYplorer Beta Club

OS: Vista x64 SP2
XYplorer version: 8.00.12 beta

Problem description:
When another program creates a subfolder in a folder displayed by XYplorer in an inactive tab, the Tree does not reflect this change: the new folder is not visible in the tree. This happens with Auto-Refresh on and not suspended.

Steps to reproduce:
1. Open XYplorer
2. Display the full Tree
3. Open two tabs
4. Select a folder in tab 2
5. Switch to tab 1
6. Select a different folder in tab 1 from tab 2
6. Let another program (e.g. WinRAR) create a subfolder in the folder displayed in tab 2
7. Switch to tab 2.

Result:
The newly created subfolder in tab 2 is not shown in the Tree until the Tree is refreshed.

Expected result:
The newly created subfolder should be reflected in the Tree.

I just wanted to post and say "Thank you" for the way in which you presented these issues today...If everyone was as nice and thorough, it would likely make it much easier for Don to find/fit it...realizing, however, that many issues aren't as easy to describe or document but still giving as much detail as available helps out.

You might call this behavior a bug, but IIRC it has never been different in the last 12 years. XY only watches the current tab, resp. tabs since we have dual pane. One might discuss whether this is good or bad, but it is surely established and nobody ever had any complaints.

My work flow may be peculiar. By way of background: multiple partitions, at least one tab per partition.

1. Double-clicking a Zip file containing folders in one tab (data partition) to extract it to the windows partition (separate tab)
2. Checking the output, put in separate folders, of a program working in the background after working in another tab. This is the scenario under which this limitation bothers me most.

Just to be clear: the main issue to me, is one of inconsistency between the Tree and the List: the List does show the new folders while the Tree doesn't. I wonder whether a workaround would be to refresh the Tree when activating a different tab?

I wouldn't call this a show stopper and I do appreciate the background information that this is not an insidious bug. Should more people (more than one would probably be the minimum ) see this as something worth improving, I'd be very glad to see it improved. I do appreciate that only-one-affected-user bugs don't make it to the top of your to-do list. Thank you anyway.

nas8e9 wrote:Just to be clear: the main issue to me, is one of inconsistency between the Tree and the List: the List does show the new folders while the Tree doesn't. I wonder whether a workaround would be to refresh the Tree when activating a different tab?

I just saw that I experimentally implemented this on 20090605 (yep, before your wish!), but then did not like it and disabled the code right away. Unfortunately I did not leave a note why I did not like it.

Personally, I'd be happy for it to be a tweak to automatically trigger the F4 (Refresh Tree) (rather than Ctrl+Shift+F4 (Rebuild Entire Tree)) functionality. It would have the same performance as a manual Refresh Tree.

nas8e9 wrote:Personally, I'd be happy for it to be a tweak to automatically trigger the F4 (Refresh Tree) (rather than Ctrl+Shift+F4 (Rebuild Entire Tree)) functionality. It would have the same performance as a manual Refresh Tree.

Bump me next year please.

Will do. Thank you for considering it.

admin wrote:

nas8e9 wrote:Personally, I'd be happy for it to be a tweak to automatically trigger the F4 (Refresh Tree) (rather than Ctrl+Shift+F4 (Rebuild Entire Tree)) functionality. It would have the same performance as a manual Refresh Tree.

Bump me next year please.

Bump as requested.

I follow nas8e9's request.
Working with many partitions request a little bit more attention when dealing with XYplorer. The feature I miss the most is a second tree to work with - being a PowerDesk user for 7 years, I'm trying to get XY my default file manager. Problem is that I lost several files/folders just by being confused with the use of just one tree, or put files the wrong place for the same reason. Tested its version 5 and simply gone mad, now I see we have CTRL+Z to work with (not on the fly, but I see hope for that) so the moving/copying part is not a big deal anymore.
-"On the fly CTRL+Z" - why I can't rename a file while I'm renaming it (selection box still opened), having to end a rename and THEN applying UNDO? New users may be confused by that... It may SEEM to then that XYplorer does not have undo anyway, leading then to steer away from the software because of that (I'm having SoHo users in mind, the wider audience out there that deserves knowing a program like this).

Bump: too early.

Ctrl+Z: cool, i did not even know that WE could do that...

admin wrote:Bump: too early.

Sorry to hear. New ETA (for bumping, that is)?

nas8e9 wrote:

admin wrote:Bump: too early.

Sorry to hear. New ETA (for bumping, that is)?

After the next 5 points on the roadmap are done.

admin wrote:

nas8e9 wrote:

admin wrote:Bump: too early.

Sorry to hear. New ETA (for bumping, that is)?

After the next 5 points on the roadmap are done.

I'll take that as not anytime soon, presumably also because of the amount of work you reckon it is.

Just to be sure we're talking about the same thing, the tweak I requested wasn't for the Tree to always be in sync across all tabs (performance problem, possible rewrite) but for an event-based thing: when selecting a different tab, automatically execute a Refresh Tree (F4). That seems to me to be fairly trivial to implement, but then I'm not a programmer .

nas8e9 wrote:

admin wrote:

nas8e9 wrote:

admin wrote:Bump: too early.

Sorry to hear. New ETA (for bumping, that is)?

After the next 5 points on the roadmap are done.

I'll take that as not anytime soon, presumably also because of the amount of work you reckon it is.

Just to be sure we're talking about the same thing, the tweak I requested wasn't for the Tree to always be in sync across all tabs (performance problem, possible rewrite) but for an event-based thing: when selecting a different tab, automatically execute a Refresh Tree (F4). That seems to me to be fairly trivial to implement, but then I'm not a programmer .

Aha, good you made that clear again. I have so many threads going on here (and in my head ) that I just cannot take the time to always reread the whole thread very thoroughly in case I'm not sure anymore what's being talked about between all those ping-pong-postings...

Now your wish would indeed be simple to implement but I'm not sure if I like it. There seems to be little logical connection between the two things you want to connect.