The 'File' tab was not showing automatically when using drag and drop. Now it does.
On Linux and OSX, the program will now automatically use default system wide SQLite libraries. Thios should reduce the risk of the program failing to load due to an SQLite file not being where it is expected to be.
Reverted the "hash matches expected hash" or "hash does not match expected hash" back to how it was before v.3.0.3. Users complained that it was more confusing in v3.0.3 than previous versions. So now it is back to the normal OK dialog and it just tells you if it it matches or not.
v3.0.3 (Jan 2019)
The 'Load Hashlist' functionality in the 'FileS' tab would accept all values but then compare them against computer uppercase hashes strings, meaning any lowercase imported values were not matched.
@@ -15,8 +23,7 @@ The filehandles were not always being released properly, even if hashing complet
The 'FileS' tab was computing file hashes of zero bytes returning the default initialisation hash for the chosen algorithm. I thought I had corrected that a long time ago but I may only have done
so for the 'File' tab according to the release notes. That was fixed returning instead 'ZERO BYTE FILE'.
A feature request was made asking for a clearer message when computed hashes do not match expected hash values input
by the user. So a new message dialog is now shown that tries to make it very clear the hashes do, or do not, match for
clear the hashes do, or do not, match for
single file hashing in the 'File' tab or when using 'drag and drop' feature.
The exe version has been updated to the correct numbering for the version (forgot to update in the project file last time).
@@ -38,11 +45,11 @@ The "List JUST sub-directories" and "List JUST sub-directories and files" had be
The "Make UPPER" and "Make Lower" buttons in Text tab didnt work properly on OSX (as in the has was not auto-recomputed for the new cases text). That was fixed.
The "Switch case" tick box was made wider to avoid truncation.
v3.0.1 (Feb 2018)
The "Select File" in File tab generated an unnecessary error if the user cancelled the selection. Now it just cancels as expected
If QuickHash cannot get a handle to a file because it is open without share permissions by the OS, QuickHash should now silently proceed and simply report that the file could not be accessed in the hash column
The SQLite database is now located in the systems temporary directory and deleted afterwards rather than appearing in the root of the launch path.
In the FileS tab, if the user aborted a scan using Stop button and selected a new folder, nothing would happen because a boolean flag was not being reset properly. That was fixed. Date formatting also adjusted to YY/MM/DD (e.g. 18/01/31)
v3.0.1 (Feb 2018)
The "Select File" in File tab generated an unnecessary error if the user cancelled the selection. Now it just cancels as expected
If QuickHash cannot get a handle to a file because it is open without share permissions by the OS, QuickHash should now silently proceed and simply report that the file could not be accessed in the hash column
The SQLite database is now located in the systems temporary directory and deleted afterwards rather than appearing in the root of the launch path.
In the FileS tab, if the user aborted a scan using Stop button and selected a new folder, nothing would happen because a boolean flag was not being reset properly. That was fixed. Date formatting also adjusted to YY/MM/DD (e.g. 18/01/31)
In the Disks tab, if the user had removable drive bays, often they would get error : "Could not convert variant of type (Null) into type Int64". That should now be fixed.
In the disks tab, dates were being shown as dd/mm/yy. Changed to YY/MM/DD in line with the rest of QuickHash
In the disks tab, logical volumes were being shown with their API prefix (e.g. \\?\F:). It still will on initial selection but thereafter (once the hashing has started) it is converted to "F:"
0 comments on commit
80aaab2