Quicksearch size selector comparisons

Things you’d like to miss in the future...
Forum rules
:warnred20: :warnred20: :warnred20: :warnred20: :warnred20: READ THIS AND DO IT!!! :warnred20: :warnred20: :warnred20: :warnred20: :warnred20:

:info: Please include the following information:
1) Your XYplorer Version (e.g., v28.00.0801)
2) Your Windows Version (e.g., Win 11)
3) Your Screen Scaling Percentage (e.g., 125%).

:info: We recommend adding your Windows Version and Screen Scaling Percentage to the Location field in your Profile or to your Signature. That way, you only have to type them once.

:info: When attaching an Image, please use the Attachment tab at the bottom of your post and click "Add files".

:warnred20: :warnred20: :warnred20: :warnred20: :warnred20: READ THIS AND DO IT!!! :warnred20: :warnred20: :warnred20: :warnred20: :warnred20:
Post Reply
jupe
Posts: 3292
Joined: 20 Oct 2017 21:14
Location: Win10 22H2 120dpi

Quicksearch size selector comparisons

Post by jupe »

This issue seems to affect both bitnesses, and AFAICT has been around for years. I am getting some confusing returns when using the quicksearch size: selector with comparisons.

I wrote up a quick repro, as an example when I run the repro, < has no return, and <= AND >= both contain the colored folder .ico's you supply (among other bogus results). :veryconfused:

Code: Select all

$r=; foreach($c, '<|<=|>|>=') { $r .= "#### $c<crlf>". quicksearch("size: $c 1MB /fn", <xypath>,, n) .<crlf 2>; } text $r;

Actually after I made up the repro, I've now discovered the issue is maybe only the "1MB" unit, eg. if use KB results seem to be as expected. :eh:

admin
Site Admin
Posts: 65075
Joined: 22 May 2004 16:48
Location: Win8.1, Win10, Win11, all @100%
Contact:

Re: Quicksearch size selector comparisons

Post by admin »

Code: Select all

$r=;
Shocking right from the start...

admin
Site Admin
Posts: 65075
Joined: 22 May 2004 16:48
Location: Win8.1, Win10, Win11, all @100%
Contact:

Re: Quicksearch size selector comparisons

Post by admin »

Okay, if you use a unit like MB in the search term, then the sizes of the files are converted to that unit* and they are rounded up* (unless you use a fractional number like "1.2MB"). This explains what you see.
* I remember that there was a good reason for this, but I don't remember the reason out of my head right now, and no time to look it up. :cup:

Unfortunately I cannot change this now since it's been like this for many years.

However, I could add something to force converting the size given in the search term to raw bytes *before* passing it to the comparison routine. That way you would get the results you (and admittedly me) expected.


Well, thought about it again, and the results are so strikingly rubbish, that it can only be called a bug. So I'm just going to fix it.

Post Reply