XYplorer Beta Club

Mesh wrote:

admin wrote:
Uaah, another mystery. Come on, this must be a WinRAR 3.80 bug (I did not try it with this version). First of all, XYplorer does not care about blanks in filenames of course. Nevertheless, I tried it with WinZIP, IZArc, 7-zip, and WinRAR 3.00 -- all perfect. I noted that WinRAR and IZArc cannot handle a hardspace (Alt+0160) in filenames.

It's not a bug with WinRAR. First of all, it doesn't make sense, as the files extract perfectly. And second - the exact same issue occurs when using WinZip as well.


*However*, I did further testing, and as it turns out, I was mistaken. It's not directories with spaces that cause problems.

As far as I'm able to see, this bug occurs in *every* directory, EXCEPT directories named "Test".

admin wrote:
Oh, you wanted it to work in other directories as well? I hardcoded the fix to C:\Test.

Seriously, this is probably because your other pane points to Test and watches it.

If you extract a Zip to an unwatched tree folder and do not drag'n'drop to point to the extraction target then indeed the tree will not refresh and never did in the lifetime of XY.

Mesh wrote:

admin wrote:
Oh, you wanted it to work in other directories as well? I hardcoded the fix to C:\Test.

Seriously, this is probably because your other pane points to Test and watches it.

If you extract a Zip to an unwatched tree folder and do not drag'n'drop to point to the extraction target then indeed the tree will not refresh and never did in the lifetime of XY.

You're right, it was linked to what the other pane was pointing to.

Okay, but with the acknowledgement that XY doesn't normally refresh the tree under circumstances like this, I think it should. It's a natural extension of Auto Refresh - either the tree is keeping up with changes the system makes, or it's not.


Is there any reason why XY can't be made to auto refresh the tree as expected?

admin wrote:
Reason: I did not know how to do it.
Good news: I learned how to do it. Works in next version!

Mesh wrote:

admin wrote:
Reason: I did not know how to do it.
Good news: I learned how to do it. Works in next version!

Gotcha!

Unfortunately, Build 416 works the same way 415 did.

admin wrote:
You mean it still does not work? Which scenario does not work?

Mesh wrote:

admin wrote:
You mean it still does not work? Which scenario does not work?

Build 416 is behaving in exactly the same way as Build 415. If you're extracting into a directory that the other pane is watching, then the tree auto refreshes perfectly. But in any other directory, and it's the same issue - the tree does not reflect the change in any way. Not even if there are already subdirectories in the target folder, and it's expanded before you begin the extraction.

admin wrote:
No, 416 is better than 415 since a completely new event case is watched and reacted to: You can now extract an archive inside an unwatched folder and the tree will correctly refresh if the archive contained any folders.

admin wrote:
However, there is indeed a way to trick out the tree, namely extracting an archive to another folder (than the archive's location) if this other folder is not watched.

admin wrote:
But, trying the same thing in Explorer, also Explorer fails! And this is independent of the extracting software used. No notification is sent whatsoever! A strong hint that this particular case is a bug in the Windows notification system.

Mesh wrote:I don't understand - if you're not talking about extracting an archive to a different folder, than you're talking about extracting it to the same folder - which means you're already in there, and wouldn't that mean that it *is* a watched folder? If you're working in a folder, by definition, it's being watched, is it not?

admin wrote:
I was using Explorer (!) to do the extraction. If the extraction was to "here" then XYplorer noted it in any folder (watched or not). If the extraction was to some other folder, then XYplorer did not note it, nor did Explorer himself.

If there is no message, then I cannot react.

Mesh wrote:

admin wrote:
I was using Explorer (!) to do the extraction. If the extraction was to "here" then XYplorer noted it in any folder (watched or not). If the extraction was to some other folder, then XYplorer did not note it, nor did Explorer himself.

If there is no message, then I cannot react.

Now I understand. I guess once Microsoft moves over to an open source linux core, you'll be able to edit the source code and fix issues like this...

mikes16 wrote:Will the catalog in a future version have the ability to open two specific panes in the Dual Pane mode? I often move/copy/compare specific sets of directories and it would be nice to click on a catalog item and have XYPlorer open them both for me.

focus p1; goto "c:\"; focus p2; goto "d:\";