FC 900: WinRAR "extract to..." creates folder in DETAILS, but no auto-refresh of TREE

[dsperber]

This is really a continuation of the discussion about what was actually the underlying issue I wrote about in "896: View -> Refresh (also CTRL+R) does not work". At that time I didn't realize there were TWO SEPARATE REFRESH COMMANDS: (1) CTRL+R "Refresh" which which only refreshed either DETAILS pane or TREE pane but not both panes, and (2) SHIFT+CTRL+R which was actually the definition of the button bar icon "Refreshes the contents of all windows", which is automatically placed there by a new default install of FCXE.

At that time I hadn't realized that was why pushing what I just always thought of as the "general refresh of all four panes" button bar icon (i.e. both TOP and BOTTOM split-screen panels, thus each of which had two panes showing: TREE pane on left and DETAILS pane on the right of each top/bottom panel, for a total of FOUR PANES on the screen) did indeed cause the refresh of all four panes. I didn't realize I was actually doing a REFRESH ALL, or SHIFT+CTRL+R, and that this was intentionally a different function from just CTRL+R (i.e. only refresh one pane).

In that other thread it was explained to me that there actually were two separate "refresh" commands, and that was why there were two separate intentionally designed behaviors, so there actually was nothing wrong with CTRL+R simply refreshing either TREE-left or DETAILS-right panes of a given top/bottom panel,whichever of the four panes had the focus. I protested that this was very confusing and of little value, when the actual originating cause of the mismatch of the TREE and DETAILS panes was that WinRAR "extract to..." created a folder in the DETAILS pane but for some reason did not trigger an automatic refresh of the TREE pane to correspond.

I saw that the release notes for the just released FC 900 Donor made some mention of revisions relating to CTRL+R. On the off-chance this might have had some effect on the subject I had talked about in that other thread I've now just given a re-test to the experiment I wrote about in my earlier thread. Unfortunately, there is no change... to any of the matters I brought up then, or now.

So, I am now more clearly re-making my report of FC behavior which I feel to be "flawed", and in need of correction or improvement however you describe it:

(1) If we are talking about just CTRL+R, I again see little to no value for applying the "refresh" function to just the DETAILS-right pane (of whichever top/bottom split-screen panel has the focus) if the DETAILS-right that has the focus in that panel, and not also doing an auto-refresh of the corresponding TREE-left pane of that same panel. It makes no sense. Yes, of course I only want just that one PANEL (TREE+DETAILS) both refreshed, and not the other panel of the split screen. But I feel that CTRL+R should apply to BOTH PANES OF A PANEL (i.e. both TREE and DETAILS in the top/bottom of the split-screen) rather than just to a SINGLE PANE (i.e. either TREE or DETAILS, but not both).

In fact, even the "Goes up one level (BkSp)" button function (or double-clicking on the ".." parent folder item shown at the top of the DETAILS pane folder/file list) automatically refreshes BOTH TREE AND DETAILS panes to show the next higher folder structure... IN BOTH PANES! Again, this is as it should be, and good. In my opinion the TREE and DETAILS panes SHOULD ALWAYS BE IN SYNC as far as the folders shown in both panes.

In my opinion it NEVER MAKES SENSE to show a TREE-left pane that does not match the folder structure presented in the DETAILS-right pane. They should never be out-of-sync in the presentation of folders, which they currently do exhibit because of the REAL PROBLEM described next in (2) below. In other words the real difference between CTRL+R and SHIFT+CTRL+R should simply be the refresh of (a) both TREE and DETAILS panes in JUST ONE/only PANEL of a split/full-screen, or (b) all four panes, i.e. both TREE and DETAILS panes in both panels of a split-screen. But in all cases, TREE and DETAILS panes should ALWAYS BE IN SYNC AS FAR AS THE FOLDERS SHOWN! It really shouldn't be necessary to use CTRL+R ever, as the two TREE and DETAILS panes should never be out of sync.

(2) BUT... the real underlying cause of the story is that when I use WinRAR and right-click on a ZIP file in a DETAILS PANE to get a right-click popup menu and then select "extract to..." in order to expand that ZIP file into a new folder inside of the folder (currently shown as the DETAILS pane) where the ZIP file lives, it is only the DETAILS pane which gets updated to show the just newly created folder from the WinRAR "extract to..." operation. THAT IS THE REAL PROBLEM, that the TREE PANE IS NOT ALSO REFRESHED AUTOMATICALLY TO SHOW THE NEW FOLDER WHEN WINRAR ("extract to...") IS THE FOLDER CREATOR!!!


Here's my argument (for why both TREE and DETAILS should always BOTH BE AUTO-REFRESHED TOGETHER AND SIMULTANEOUSLY so that the folders shown in TREE and DETAILS should always be in sync). And in fact this already currently occurs universally exactly as it should as long as it is FC which is used to manually create or delete folders with focus either in the TREE or DETAILS pane. The problem of out-of-sync TREE and DETAILS arises specifically only when using WinRAR to "extract to..." as the method of creating a new folder, and then only if it is the DETAILS pane which has the focus where the ZIP file is selected. Turns out if it is the TREE pane that has the focus when Winrar's "extract to..." is used, well now that folder creation using the TREE pane DOES in fact trigger an automatic refresh of the DETAILS pane. THIS IS THE ONE PROBLEM SITUATION!

So...to review...

(a) If I have focus in the DETAILS pane, and I "create a NEW FOLDER" using any of the multiple ways that can be used (i.e. right-click in the DETAILS pane and then select NEW, or use "create new folder (F7)" button, or Menu bar -> Folder -> New), this will trigger an automatic refresh of the TREE pane to show the newly created folder that was just created through the DETAILS pane. Newly created folder shows in both panes. This is as it should be, and is good. Both TREE and DETAILS panes were automatically refreshed together and are in sync as far as folders shown in both panes, as they always should be.

(b) If instead I have focus in the TREE pane and I have a particular folder selected (so that it shows up expanded in the DETAILS pane) I can again "create a NEW FOLDER" through several methods (i.e. use "create new folder (F7)" button, or Menu bar -> Folder -> New). And once again, just as in (a), the new folder will be created and appear in the TREE pane, and this will trigger an automatic refresh of the DETAILS pane to show the same newly created folder that was will simultaneously appear in BOTH the DETAILS and TREE panes. Newly created folder shows in both panes. Once again, this is as it should be, and is good. Again, both TREE and DETAILS panes were automatically refreshed together and are in sync as far as folders shown in both panes, as they always should be.

(c) If I have focus in either DETAILS or TREE pane (doesn't matter which of the two panes has the focus for this scenario, results are the same and are good) and I have a folder selected in that pane (again, doesn't matter which of the two panes I've selected that folder in), and then I DELETE THAT SELECTED FOLDER (using any of the multiple available methods to delete that selected folder in that pane), then BOTH PANES GET AUTOMATICALLY REFRESHED to reflect the disappearance of that folder which was just deleted. The folder selected for deletion is now truly gone from both panes, whereas right before the deletion that folder was visible in both panes. Once again, this is as it should be, and is good. Again, both TREE and DETAILS were automatically refreshed together and are in sync as far as folders shown in both panes, as they always should be.

(d) NOW... if I instead use WinRAR and its "extract to..." function on a selected ZIP file to expand the ZIP file and create a new folder that way, well now THERE IS NOT A SIMULTANEOUS AUTOMATIC REFRESH OF BOTH TREE AND DETAILS PANES TO KEEP THEM IN SYNC:

(d1) if the TREE pane has the focus and I've selected the "parent folder" under which there is a ZIP file present, and while the parent file is selected I right-click on that ZIP file (shown as an explicit WinRAR folder item in the TREE pane) to get the popup menu and then invoke the "extract to..." function to create the expanded folder



then the newly created folder from the ZIP file extraction ONLY SHOWS UP IN THE DETAILS PANE, but NOT IN THE TREE PANE!!

==> TREE AND DETAILS PANES ARE NOT IN SYNC!. I maintain they should always be shown in sync, and thus both TREE and DETAILS panes should always both be automatically refreshed together when something changes in one pane or the other, and that CTRL+R should always refresh BOTH PANES OF A TOP/BOTTOM OR LEFT/RIGHT SPLIT-SCREEN PANEL



(d2) if the TREE pane has the focus and I've selected the ZIP file itself (rather than selecting the "parent folder" in which the ZIP file lives), and again right-click on that ZIP file to get the popup menu and then invoke the "extract to..." function to create the expanded folder, the results are identical as in (d1). Once again, the newly created folder only appears in the DETAILS pane and the TREE pane is NOT AUTOMATICALLY REFRESHED. So once again TREE AND DETAILS PANES ARE NOT IN SYNC!

(d3) if instead the DETAILS pane has the focus and I right-click on the ZIP files shown in the DETAILS pane to get the popup menu and then invoke the "extract to..." function to create the expanded folder



then once again the newly created folder from the ZIP file extraction ONLY SHOWS UP IN THE DETAILS PANE, but NOT IN THE TREE PANE!!



==> So once again, TREE AND DETAILS PANES ARE NOT IN SYNC!


I contend that FC should automatically refresh both TREE and DETAILS panes (of a panel, either top/bottom or left/right of a split-screen) when WinRAR "extract to..." is used to create a new folder. Currently only DETAILS pane is updated.

Also, I feel that both TREE and DETAILS panes should always BOTH BE REFRESHED when REFRESH (CTRL+R) is used. TREE and DETAILS panes should never be out of sync with each other as far as the folders shown in both panes. So CTRL+R is for refreshing both TREE and DETAILS panes of just one panel of a split-screen, whichever panel has the focus. But it should always refresh BOTH TREE AND DETAILS. And SHIRT+CTRL+R is to refesh both panels of a splt-screen, i.e. all four panes of a split screen.

==> TREE AND DETAILS PANES SHOULD ALWAYS BE IN SYNC AS FAR AS FOLDERS SHOWN.

(quite frankly, I don't see the point of having two different refresh commands, if the TREE and DETAILS panes of any given panel are never out of sync with each other. All you really need is a "refresh all" to refresh the "other panel" which didn't have the focus at the moment. The panel with the focus should ALWAYS BE IN SYNC ALREADY.

[dsperber]

Just in passing (and to submit additional evidence for my position that both TREE and DETAILS panes should ALWAYS BE KEPT IN SYNC, including when WinRAR "extract to..." creates a new folder), I decided to see if Windows File Explorer would in fact automatically refresh the Windows TREE pane when WinRAR created a new folder in the Windows DETAILS pane, so as to always keep the two Windows Explorer panes in sync.

And the answer is YES.

(1) Initial state, with ZIP file placed in DETAILS pane, about to perform "extract to..." to create a new folder in DETAILS pane:



(2) After performing "extract to...", new folder created in DETAILS pane. And also, the TREE pane has been automatically refreshed to reflect the just created new folder in DETAILS pane. Both panes are IN SYNC, as they always should be.




==> I believe FCXE behavior should match that of Windows File Explorer. Both TREE and DETAILS panes should always be kept in sync. Creation of a new folder in DETAILS (e.g. by WinRAR etc., or by FCXE itself) should always trigger an automatic refresh of TREE pane as well.

==> I also feel that consistent with the above, that Refresh (CTRL+R) function should always refresh BOTH TREE AND DETAILS PANES for the panel that currently has the focus in a split-screen view, or simply for both panes in a normal full-screen view. Again, TREE and DETAILS panes should quite simply always be presented in sync. They should never be out of sync. There is no justification for that..

[dsperber]

One new observation on TREE vs. DETAILS, again what appears to be an issue with what is shown in TREE differing from what is shown in DETAILS. Bug? Defect? Oversight? Intentional? Only Marek knows for sure what the intent was and whether or not the design/implementation matches the intent. But nevertheless I will still observe and comment.

I am continuing to pursue this subject of file/folder sort sequence, and whether or not it is presented as what I feel is "correct". It was when working with another program (ACDSee) browsing images that I stumbled into THEIR DESIGN DECISION to implement a "sort by filename" result that (a) only matches what File Explorer does, but also (b) ONLY WHAT PURE VIRGIN FILE EXPLORER DOES. In other words as has been mentioned before, there is a well known Registry hack that can cause Explorer to NOT SORT FILENAMES "NUMERICALLY", but rather to sort "non-numerically" which is actually not truly "alphabetical" in the FCXE sense. Both of these options are (theoretically) supported by FCXE via Settings while ACDSee only behaves (theoretically) the way Explorer behaves... but in fact only the way Explorer behaves in pure unhacked Windows form. In other words even if the Registry hack is applied so that Explorer sorts alphabetically, ACDSee uses its own built-in sorting logic to still sort "numerically" (i.e., so that that 0FF will appear before 001, same as unhacked default Explorer does).

And the perfect simple demonstration for what is working and how is to look at how two files named 001 and 0FF (or similar) appear, from any program that presents files in a list that is supposedly "sorted" by filename.

And that brings us back to FCXE, and this thread which asks for TREE to also be ALWAYS automatically refreshed whenever DETAILS gets updated/refreshed for any reason in the world, be it because FCXE updated/refreshed DETAILS or because any program (e.g. WinRAR) updated DETAILS and FCXE detected it so that a refresh was effectuated. My point was that I feel TREE and DETAILS should ALWAYS BE IN SYNC. There is simply no reason for them not to be in sync.

Well now I've discovered another FCXE anomaly, namely that the Settings -> SORTING option in Settings ONLY AFFECTS THE DETAILS PANE! It has NO EFFECT ON THE TREE PANE, which in fact will always be populated by Explorer. So as it turns out, whatever is the mode of sort that Explorer uses (either numeric or alphabetic, depending on the Registry hack being absent or present, respectively), the TREE pane of FCXE will ALWAYS MATCH EXPLORER, But at the same time, the DETAILS pane of FCXE will ALWAYS BEHAVE PER the "file/folder list" SETTINGS OPTION.

So once again, it is another case where TREE does not match DETAILS in FCXE. But in this case it's not because a refresh of TREE was not done when it should have been. It's because TREE seems to always drawn by Explorer, whereas DETAILS is apparently always drawn by FCXE.

Here's a demonstration of the above. To make things very much easier to follow, I created several new file name pairs that contain 001 and 0FF withihn their short file names that are therefore easy to intuit which YOU PERSONALLY would want to appear first or second in a filename list. I personally will not understand how/why 0FF can ever be sorted in front of 001 no matter "numeric" (whatever that means to MS and Explorer) or "alphabetical". But nevertheless it does make it very easy to see different behaviors with these two file partial names where the rest of the two filenames is otherwise identical.

==> Once again observe that File Explorer ALWAYS KEEPS TREE AND DETAILS IN SYNC, no matter whether the Registry hack is applied or not. Both panes are always identical as far as folders shown in both panes. In contrast, FCXE not only does not automatically refresh TREE when WinRAR updates DETAILS (as this thread is about). But because TREE is always drawn by Explorer while DETAILS is always drawn by FCXE, once again the two panes can mismatch. Specifically, if FCXE sorting is set to "alphabetical" and the Registry hack is not installed, TREE will be in "numeric" order and DETAILS will be in "alphabetical" order. Conversely, if FCXE sorting is set to "natural as Explorer", i.e. numeric and the Registry hack is installed, TREE will be in "alphabetical" order and DETAILS will be in "numeric" order.

See screenshots below for "proof". NOTE THAT ONLY WHEN EXPLORER IS UNHACKED AND FCXE SORT IS "NATURAL EXPLORER" DOES TREE MATCH DETAILS!

NOTE: because of the completely incomprehensible "numeric" sort that is implemented by File Explorer, it turns out that even when the Registry hack is applied to disable "numeric" sorting and presumably enable "alphabetical" sorting, this actually does not match what FCXE is doing with its own "alphabetical - string sort". Clearly Explorer's "non-numeric" sort isn't purely "alpyhabetical character string" like FCXE's is. So even when you'd think they should match, the TREE and DETAILS shown in FCXE in fact do not match, in a complicated numeric and alphabetic character ambiguous sense. See my *** notes on the following screenshots for examples.


(1) Pure untouched unhacked Windows Registry, so absolutely pure default MS Explore filename sort sequence is obtained. Images below show (a) the Registry (to prove it is not hacked), (b) output of Explorer, (c) output of FCXE with sort set to "natural sorting (as Explorer)", and (d) output of FCXE with sort set to "alphbetical - string sort".

(a) Registry

(b) Explorer output

(c) FCXE "natural Explorer" sort. This is the only situation with 100% exact match, TREE to DETAILS.

(d) FCXE "alphabetical" sort. *** NOTE the FCXE "alphabetical" sort operates on ALL FILENAMES, and does this correctly in my opinion. In contrast Explorer will produce a somewhat different result when it is hacked to "non-numeric" sorting (see second FCXE images in (2) below).


(2) Windows Registry hack installed (so as to disable numeric sorting).

(a) Registry

(b) Explorer output

(c) FCXE "natural Explorer" sort *** NOTE see that Explorer "non-numeric" agrees with FCXE "natural Explorer" for some names but not for others. This situation is caused by the fact that TREE is drawn by Explorer and DETAILS is drawn by FCXE.

(d) FCXE "alphabetical" sort *** NOTE see that Explorer "non-numeric" agrees with FCXE "alphabetical" for some names but not for others. For some reason FCXE "alphabetical" sort correctly alphabetized ALL character string filenames whereas Explorer's inscrutable "numeric" sort decided not to on some but to go ahead on others. But again, TREE is drawn by Explorer and DETAILS is drawn by FCXE, each of which has different rules for sorting. In other words, "non-numeric" Explorer is not truly equal to "alphabetical" FCXE.


I once again contend that TREE and DETAILS should simply never be out of sync. There's no reason for it,

Also, I submit that if FCXE is providing a Settings -> View -> folder/file list -> Sorting option, then that option SHOULD BE APPLIED TO BOTH TREE AND DETAILS. Again, TREE and DETAILS should simply always be in sync no matter what the FCXE sorting option is (and no matter how the two panes get drawn).

NOTE: I realize that "user error" calls for me to correct things so that if I do want FCXE to sort in "alphabetical" order I probably should also have applied the Registry hack so that Explorer also displays things the same way. And if I haven't applied the Registry hack so that filename sorts are in Explorer's "numeric" order then I probably shouldn't have set FCXE to sort in "alphabetical" order. But I'm using FCXE, and not Explorer, and they should be two independent products. I use FCXE because it is better. And if FCXE offers me a wonderfully flexible option to display things EITHER WAY... AND ON DEMAND EVEN... then I simply once again think both TREE and DETAILS (drawn by FCXE as far as I, the user, am concerned) should reflect that settings sort option. And if the problem here is that Explorer is being used internally by FCXE to draw TREE independently of the FCXE sorting option, then this surely is a bug. From the user's perspective both panes should simply always be in sync, no matter what, and no matter who draws each. I didn't realize it was Explorer that drew TREE until tonight, as this detail is now clearly involved in this whole story. I honestly think that TREE should be drawn by FCXE like DETAILS is... and always refreshed together so as to always be in sync.

[dsperber]

Totally fixed by 904. Thank you, thank you.

Case closed.