If you're happy with how you pass arguments to those utilities now (such as using their shell-extensions or your own user-commands) and don't want to change, then stop reading now.
If you don't have peripheral awareness of your whole x2 working environment, stop reading now (I'm not kidding).
If, as the Americans say, you're not smarter than a 5th grader, please stop reading now.
If you don't know what a paradigmatic utility might be, continue reading (cautiously, with guns drawn...).
Still here? Ok, let's go...
Download: CompareHandler (Version 3.5.0.1, updated 16-Mar-2014)
As utilities go, this is my bête noire, my Trafalgar. I've probably re-written it from scratch at least six times over the last few years, and this is the current (and most robust) incarnation. What sounds simple in design turns out to be infuriatingly complex in execution. Essentially it launches (in a single-click) a 3rd-party comparison utility with selection-arguments based on the current x2 cross-pane-environment you're using, deriving those arguments from a fixed set of rules.
The primary logic sequence is simple:
- a) If no objects are selected (in either pane) the pane-paths themselves are compared
b) If any 2 items are selected in any active pane (including the miniscrap), they are compared to each other
c) If 1 item is selected in the active pane, and 1 item in the inactive pane, they are compared
d) If a single item is selected in one pane and it is a folder (or folder-type such as an archive), and nothing is selected in the opposite pane, the selected folder will be compared to the opposite pane's path
* Left/Right orientation is always preserved between x2 and the comparison utility (this is half the benefit), irrespective of active pane or pane-type, or selection-position
While the utility is actually designed to be predominantly used without its built-in menu, holding <Ctrl> when launching (or using the /Menu option) will popup a menu which allows the user to toggle various options before the arguments are committed - such as preventing common user-errors like accidentally comparing mis-matched object-types, or not supplying enough arguments - to reversing the order of arguments, or dismissing superfluous selections and enabling 3-way comparisons (assuming the comparer you use can support that ability).
The states of these toggled-options are not remembered between sessions (this is by design), so if you don't like the defaults as presented, you may need to use command-line parameters when creating the user-command:
Most of these are self-explanatory, and indeed, suggest how this utility is meant to behave, or even launched in the first place. Which brings us to the syntax of the user-command itself, which at its most basic will always be:
> CompareHandler.EXE /Run="{Path to Comparison Utility}" "$L" "$R" $A
Any other options may be added to the line as desired, but these 4 elements must always be present - in particular the last three literal tokens (first two in quotes, last one without) directly in that order. If you accidentally do not supply them all, or mess with the syntax, you are guaranteed to break the expected functioning.
Obviously, the /Run command expects a full path to your 3rd-party comparer's binary, wherever you have it installed, for example:
/Run="C:\Program Files (x86)\Beyond Compare 4\BCompare.exe"
Other commands, such as /3Way and /NoSeclude go towards how actual selections are handled between panes and/or the mini-scrap panel in particular. By default the mini-scrap is "secluded", meaning (unlike normal panes) at least two selections must be made for comparison and nothing outside of the mini-scrap is considered. However, by not "secluding" it, if the mini-scrap has focus and only one item is selected, and one (or more) items are selected in the Left/Right panes, the mini-scrap selection will be compared to the other selection(s). This can take a bit of getting used to as a paradigm, which is why it's switched off by default, always secuding the mini-scrap. By the same token, any selections over the first two are usually ignored (it's rather rare to need 3-way merge), so the "third item" (if selected) is not sent to the comparer, preventing odd conflicts. However, should the user require it (and the comparer be able to handle it) selecting 3-Way merge support is available, just disabled by default.
CompareHandler itself has three caveats which apply, and all three are equally important: 1) The user must use the correct "bit"-type for his x2-version, in other words x64 with x64 or x86 with x86. 2) The user must not have the "Hide extensions of known filetypes" option ticked in Windows Explorer. 3) The "Name" column must be configured to be first in the details column listing.
In case anyone is wondering why the "bit-type" is important, it's because I'm using an extreme method of deriving the selections directly from the listviews in x2. The reason this is needed is it allows me to keep the pane-order intact (regardless of "active" status) and completely avoids x2's habit of "sometimes" considering "focused" objects as "selected" even when they expressly are not. This way what the users actually selects and de-selects is axiomatic, and not to be confused (as often happens when using x2 tokens in user-commands) with any mystical "third-state" which only exists in Nikos' head.
One aspect of x2 integration which scripters tend not to make much use of is x2's built-in Filetype definitions, which are most often used when filtering and (frankly) not used for much else beyond that. In this case, I've tapped into them for automatically determining the filetype-extension matching rules - they are read directly from the registry (or use /INI if necessary), so the user doesn't need to do any special management once everything is up and running - any edits within x2 will be reflected by CompareHandler directly.
For example, when the user is comparing two or more files (as opposed to folders) if the types are in the same "group" (even if the extensions are different) they will be considered as an ok match and no error will occur. Simillarly, if two extensions are the same (even if they belong to none of the groups) they will also be considered acceptable. However, if two types from differing groups are compared, an error occurs. This is to prevent the user from doing something silly like trying to compare a JPG to an AVI. Mistakes like this can happen, and just end up with the user launching multiple failed compare-sessions which serve no purpose and waste time. The more advanced 3rd-party comparers (such as Beyond Compare) can handle such things as all types of photographs (on a pictoral level, not just as binary objects) and can even compare .reg files to the live registry before you merge them, so a certain flexibility is built in when passing filetypes in general.
The same idea applies to folders - CompareHandler will consider any attempt to compare a folder to a file as an error (obviously) unless that file is a "folder-type", such as a known archive-type. Obviously not all comparers are able to breakdown archives automatically, but most should be able to handle the usual archive types of: *.rar, *.zip, *.7z, *.chm, *.gz, *.bz?, *.jar, *.cab. These will all be considered as permissible de-facto folders when selected against a folder path. If that list does not include an archive-type which you want to force to be recognised, just create a new group called "archives" within x2 and add your extensions. The ones listed here are already defined within CompareHandler so you don't need to worry about them.
If, however, you don't like this sort of policing, and want to be free to make your own silly mistakes, you can always switch filetype matching off (or even prevent any error reporting at all) by using the menu/CLI options /NoError and /NoExt. Personally I find it handy to have such things monitored, and only ever need to override a mis-match error very rarely (once all the filetypes used regularly within x2 are registered).
I think that about covers it - in case anyone looks at the source-code and is flabberghasted to discover that enforcing four simple rules and adding a few options somehow requires 850 lines of code, they should note that there are about a hundred intermixed If/Then conditionals (based on active-pane, location of selections, etc) which all need to be handled correctly and in the correct order. Hence the reason this is my bête noire - it's such a simple thing, but the task has proven greater than the protagonist each time, and I regularly (admittedly, five times now) have fallen to my knees weeping at the pallid attempt my imagination allowed. Perhaps this time I will have gotten it "right" - I can but beg forgiveness if I have not.
As usual, questions, comments, critiques, requests - all are welcome. I would like the thank the forum member Snakebyte for introducing me to Beyond Compare a few years ago, it rather quickly become my most oft-used programme after x2, firing up multiple times a day thus inspiring this utility. If curses could be considered a gratitude, I am Caliban to Snakebyte's Prospero, and needs-must I forever curse thee most loud.