Another Bug: FILE SIZES – as reflected in the Anytxt programme itself – are not Exported Correctly to Excel.
The screenshot is an image compilation from Anytxt (on the left) and Excel (on the right) showing typical error examples (from the one set of text-search Results).
The Anytxt programme shows the LARGEST file size match for the search-text entered as 211.54 MB.
However, when those same results were exported to Excel, then sorted by ‘SIZE’ (Z-A), the LARGEST is listed as 990.34 KB. (which is, approximately, only 1 MB).
Also, files with <i>SMALLER </i>sizes, having as their unit, KB, are listed (still Z-A) as being LARGER than others further down the list, despite those others having as their unit, MB.
Clearly, the current Export-to-Excel set-up is wrong in terms of file sizes.
Whereas within the Anytxt programme itself, sorting files by SIZE yields results, sorted, correctly, by their ACTUAL SIZE, the current Export-to-Excel process incorrectly attributes file SIZE only to the NUMBERS, ignoring the UNITS (KB vs MB).
SUGGESTION 11: Fix the Export-to-Excel code to ensure that FILE SIZES are exportable, and then readily sortable, in terms of their ACTUAL SIZE. Perhaps applying just ONE SIZE UNIT to ALL files may be worth considering (e.g. all in MB). If that were to be done, the SIZE of all files could be reflected as just numbers, but associated Column/Field header text MUST then reflect the (correct) unit, e.g.: ‘SIZE (MB)’. (As a bonus(?), data in the SIZE fields, in both Anytxt and Excel, being then able to be presented as unitless numbers, would be less visually cluttered).