Dual Pane - Formal Proposal Thread

[admin]

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".

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]

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]

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?

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

[Mesh]

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]

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.

You mean it still does not work? Which scenario does not work?

[Mesh]

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.

[Muroph]

i did some tests with v416.
the tree is updated correctly if you extract to a watched folder or any of it's child folders.
doesn't seem to work on other paths, and logchange doesn't print any messages.

also, that problem with folders deleted by winrar sometimes not disappearing from the list is still here.
i couldn't spot any pattern for this, tho.

[admin]

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.

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.

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. 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]

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.

My statement was that Build 416 behaved identically to Build 415 in regards to the test procedure - and that is, indeed, the case. In the test procedure I outlined, there is zero difference in the results between the two builds. I'm not saying you didn't add something - I'm just saying that it wasn't anything that affected this particular issue.

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.

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?

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.

Ah, but XY is supposed to be superior to Explorer!

Okay, well if Windows doesn't know something happened, I guess there's not much you can do about it on your end. Ai!

Well, thank you for trying!

[admin]

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?

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]

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...

[admin]

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...

Sure thing.

BTW, I added DP to the Tour and version 8.00 is soon to be published...
http://www.xyplorer.com/tour/index.php?page=dp
Jimmy Page, have mercy!

[mikes16]

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.

Thanks for such an excellent product.

[admin]

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.

This could be solved more general. Off my head I see these ways:

(1) somehow enhance the general location syntax to allow for definining 2 locations in one string

(2) somehow enhance the general location syntax to allow stating the target pane (1/2, or active/inactive)

(3) add a parameter to the goto command stating the pane (1/2, or active/inactive)

Of course, you can already solve this now via scripting. The tree will move, and it only works if both panes are visibile, but apart from that it's ok:

Code: Select all

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

[mikes16]

Thanks for the scripting tip and any potential future consideration of a possible enhancement!