I know this may be expanding HashTools a bit past its original design parameters, but I figured I'd suggest it all the same. One functionality I'd love to see in HashTools is the ability to read and create .sfv (and with the ability to read .sfv files, I would think the ability to read .md5 files also would be relatively simple as they are identical save for using the md5 checksum instead of crc32) files. The format is as follows:

filename.file hash
file2name.file hash
file3name.file hash

so

region1.dll 927dc263
region2.dll 59e7587f
serial.txt b21cb3ec

would be valid contents for an .sfv file, which once clicked would cause HashTools to verify all 3 of those files.

Thanks for hearing me out.

Excellent! Works perfectly. I like that you didn't add a second line to the context menu about verifying sfv files - in a few other tools I've seen

Verify File
Read SFV

which is obviously pointless unless someone were to provide you with an .sfv of your .sfv... I'd say you got this one right.

Thank you, this just became an extremely useful tool for me.

However, if you think I'm going to leave you alone now...

e5eb362da8dc2d67cffb39a47ec6c0f5 *file.extension
1e277e77e385705d926a2d16012da50c *other file.extension
dfeb1407e3b9f2902912e3916b707a37 *more file.extension
a20978cf728ccb39077e80f77ebfb4a3 *one_last_file.extension

That would be the contents of an .md5 file. Works exactly the same as the .sfv, except uses the md5 hash... I'll just leave this here... *hint hint*

Last one, I promise. Really. (Actually, to the best of my knowledge .md5 and .sfv are the only two "standard" verification type files. I could be wrong on that, but I don't think any of the other hashing algorithms have adopted a standard for batch verification.)

Not sure if this was intended or not, but if you highlight multiple files and use the right-click "Hash with HashTools" interface, it opens a separate instance of HashTools for each file highlighted. It might be better if all of the files were to be opened in the same instance. (Just my thoughts, but if someone were to be opening multiple files at once I'd think they'd be planning to use the same process/hashing algorithm on all of them - possibly for the purposes of .sfv creation - so all the files in one instance would make more sense than each file in its own instance of the tool.)

Also, I'd like to thank you for being more responsive to my suggestions/requests for a free tool than any other developer of any program I've paid for has ever been. I know first-hand how time consuming these things can be.

EDIT: I do realize that clicking the background of a folder with multiple files in it will allow you to hash the entire folder, but with the above change that would be unnecessary and I would recommend removing that feature to keep the right-click menu clear. It would seem to be more efficient that way to me, just my opinion though.

EDIT2: Just noticed that when you go to save a .sfv file it asks you the folder location you would like to save in. Since the .sfv will not work unless it is in the same folder as the files that were used to create it I would suggest automatically placing it in that folder UNLESS the files used to create it come from multiple locations, then give the option.

An alternative method would be to still give the option even if all the files were from the same folder, but have the Explorer window that opens open to the folder with the files being verified instead of you having to navigate there. Actually, I think I like this option best.

A shame, but personally I think it would be worth the trade-off. With the amount of I/O hashing takes I don't see very many people attempting to run multiple jobs at once outside of batch processing jobs, which HashTools can already handle.

Definitely a step in the right direction, although I don't seem to be having much luck with it myself. What method did you use to get the files to all appear in the same instance? When I select multiple files, right click and "Hash with HashTools" only the specific file I right-clicked on is added while the others are ignored entirely.

EDIT: Alright, just did some testing and was treated to some... strange results.

Right-clicking on a single file and selecting "Hash with HashTools" - SUCCESSFUL

Selecting 5 or fewer files, right-clicking, and selecting "Hash with HashTools" - NEVER* RARELY SUCCESSFUL - Only file right-clicked will appear. *One instance of success observed.

Selecting 6-15, right-clicking, and selecting "Hash with HashTools" - RARELY SUCCESSFUL / RANDOM RESULTS - Generally either just the file I right-clicked, that file I right clicked and one other (random) from the pool I selected, or the file I right-clicked and two others (random) from the pool I selected appear. Far less often any other number appears up to and including all of the files selected (14/15 selected, 6/9 selected, 4/15, 4/6 selected, etc. etc. were all observed from the same pool).

Selecting 16 or more files, right... never mind... - NEVER SUCCESSFUL - The "Hash with HashTools" context menu option no longer appears when 16 or more files are selected.

In all cases the hashes calculated from the files that I was able to select were correct.

Thank you for update the Jon, this is a vast improvement. When selecting multiple files HashTools now seems to be fully reliable given a few moments to load them all in. A few things I did notice however:

-File loading is very slow (about 1 second per file), with files OFTEN BUT NOT ALWAYS being loaded in "batches" of 4-5 at a time until all files are loaded - the size of the file makes no difference nor does the medium the file is stored on. +-1.00Gb .mkv files on an external USB drive load just as quickly as +-500Kb .jpg files stored on an SSD.
-If HashTools is closed while files are still loading (145,000 generated and used for test) a new instance will open and HashTools will continue the operation
-Files are loaded in order, except for the actual file you clicked on, which will be loaded first:
--EXAMPLE: If I highlight files "1", "2", "3", "4", "5" and "6", then right-click on file "4" and select "Hash with HashTools" the load order will be "4", "1", "2", "3", "5", "6"
---Perhaps an easy fix for this one would be to allow the sorting of files by alphabetical order when clicking on the "File" bar?

Also, I am curious as to 15 file limitation being fixed with the registry change. If you have the time, could you explain further the reasons for this and why the limitation would be in place? My understanding was that this value was used to limit the operation of functions that you possibly would not want applied to many files, such as "print" - but that would certainly not be the case with HashTools. I would have assumed that there would be a method of working around this, as functions like "copy" and "paste" still work on any (reasonable) number of files selected. It may also be of interest to you to take a look at a tool like 7-Zip or WinRAR also, as both of those seem capable of selecting any desired number of files from the context menu (tested to 38 without a change to this value. Is there a difference in the operation of the tools that causes need for the registry change, or have they just come up with an alternative method?

Thank you for your continued work on this tool, it is very much appreciated.