Walter, in the interest of time and clarity, I'm going to respond to just a selected number of your statements here, and not necessarily in order. (In general, though, I agree with most of your observations about the needed functions).

---------- "Differ" ----------
> Yes, even if only Size is added to Date,
> one needs "Differ"

I see now that what you mean by "differ" is "Different size". I agree that "Differ" is needed. Just as "Different date" is present in the form of Newer and Older, so too is "Different size" needed. (Since we don't need Larger and Smaller, Different will suffice).

---------- "Identical" ----------
> I do NOT(!!!!) think that the date handling
> selection should be overloaded onto the "Identical"
> toggle/prompt -- "Identical" should be treated
> just like Older/Newer/Unique,

Here I'm confused! Certainly you meant "size handling", since "date handling" IS the primary purpose of Identical/Older/Newer, (but NOT Unique). On the assumption you mis-typed, I will continue...

I would agree with your (amended) statement, except that what you seem to overlook here, Walter, is that the Size IS(!!!!) ALREADY(!!!!) "overloaded" into the "Identical" toggle/prompt in the Normal compare! (But not in the B/S/G-Alt-F4-Compare). If you have two files with identical date stamps, but different sizes, they currently WILL NOT be tagged in the Normal-compare, just as they will not be tagged if they have identical sizes and different dates! (By "Normal-compare" I mean Directory-window-Compare, Directory-window-Alt-Compare, and Normal-File-window-Alt-F4-Compare).

There is NO WAY that a file which has a different size but an identical date will EVER be tagged in a Normal-compare, (unless you use Binary, which should NOT be necessary!) This is, in my opinion, a weakness in XTree, which was duplicated by Kim in ZTree.

It was THIS problem ONLY that I was trying to cure by adding the Identical "Size/Date" options. This would serve to simply split-out the two compares CURRENTLY BEING MADE (date and size) when the Normal Identical toggle is "yes", so we could DEFINE what is MEANT by "Identical" (date, size, both, none). This seemed to me to be a reasonable request, and it still does.

---------- Alternate Menu ----------
> As to putting this stuff off to some other
> function/keystroke, one would just have to
> re-implement all of the date/size logic and
> handling anyway at the new keystroke, so
> what's the point???

The reason for moving it would be to provide a place where we could be free to design a new menu, free from the constraints of being compatible with the XTree menus. I would have no problem leaving SOME Binary functions in BOTH places, as long as that compatibility can be maintained without unnecessary complications to the menu.

To understand the complications to which I refer, read the following section.

---------- Menu Design ----------
> Suggestion: Try to write down a "prompt panel"
> with some of the stuff on it and see if you
> can estimate how complicated it is to use it...

Well, I haven't gotten to the point yet of writing down a "prompt panel", but I HAVE identified most of the file characteristics and operations which some folks might want for a compare function:

File: Exists, Unique
Case: Same, No (No Compare)
SFN: Same, Different, No
Write Date: Same, Newer, Older, No
Create Date: Same, Newer, Older, No
Access Date: Same, Newer, Older, No
Size: Same, Different, No
S/H Attributes: Same, Different, No
R/O Attributes: Same, Different, No
Contents: Same, Different, No
Version: Same, Newer, Older, No
Logic: And, Or, Not
Tags: Tag, Untag

As you can see, to provide the above in one easy-to-use menu would, in my opinion, require a MAJOR rewrite of the Compare menus, to the point where I don't think it would be practical to attempt compatibility with the XTree menus.

Such a menu would be better designed around the items. For example, rather than "Identical Newer Older" items, there would be multi-cycle toggles like Date: (Same, Newer, Older, No), and Size: (Same, Differ, No), etc.

A system of applying the desired And/Or/Not logic to each would have to be provided, as well as the ability to specify a tagging or untagging operation.

---------- Summary Recommendations ----------
Since designing, coding and debugging a new compare feature is WAY BEYOND what I think Kim might be able to achieve in the short run, I would be satisfied, FOR NOW, to add the Date and Size options to the Normal-compare Identical toggle, and an F4 option to the B/S/G-Compare menu, as I originally suggested.

I WOULD, however, like to see "Differ" added, at least to the Normal-compare. Right now there is NO WAY to tag files which have DIFFERENT sizes or contents. (Only SAME sizes and contents can be tagged). To achieve this easily in the menu space available, I suggest changing the Binary toggle to "Binary (no, same, differ)". If "differ" is selected, then only those files with the same names and different contents, (including of course different sizes), would be tagged, regardless of the file dates. This one item would be EXTREMELY helpful!

Finally, I don't believe there is any way to tag just the files which have identical dates but different contents, (or sizes), or conversely, just the files which have identical contents but different dates, (even using separate tagging passes). Both of these capabilities would be very helpful to most of us. Maybe I'm missing something, but I do not see a way to do either of these.

To achieve these VERY useful combinations of "same-dates-different-contents", and "different-dates-same-contents", I suggest making a relatively simple change to how Binary works in conjunction with the other toggles. Presently, if Binary is "yes", the Identical, Newer and Older toggles are ignored. (Unique files are ALSO tagged if Unique is "yes").

Instead, have ZTree use "AND" logic with Identical, Newer and Older. That way "Binary (same) and Newer (yes)" would tag ONLY those files which had identical contents AND newer dates. We should KEEP the present "OR" logic with Unique, so that we could get "Binarily different OR Unique" in one pass, (and since "AND" logic with Unique would make no sense).

To be sure, other useful combinations would not yet be possible in one pass, such as Binarily different OR Newer, but these could be achieved in two passes, (e.g. first tag Binary (differ) then tag Newer (yes)). In other words, virtually ALL useful combinations could now be done.

Examples of useful one-pass capabilities:
(All toggles not shown are set to "no")

Setting: Binary (same), Newer (yes), Older (yes)
Result: Tags only those files which have both the same contents and have different dates.

Setting: Binary (differ), Identical (date)
Result: Tags only those files which have both different contents and have the same dates.
Note: If we don't add "date" to Identical, this won't work.

Setting: Binary (differ), Identical (size)
Result: Tags only those files which are the same size and have different contents.
Note: If we don't add "size" to Identical, this won't work.

Setting: Binary (differ), Unique (yes)
Result: Tags all files which have either different contents or are unique.

All the above can be achieved with the three relatively simple changes to the Normal-compare I've suggested, with very little menu change, no additional key assignments, and while maintaining total compatibility with XTree!

- John