XYplorer Beta Club

I tried this search:and I got only the rating=3. Then I realized I put an additional space character between the "or" and "4". Then I tried to insert more space here and there, and I could realize, that boolean search doesn't tolerate the unnecessary space characters. Is it by design?? Because I don't like this behaviour...

EDIT: Ah, I could almost figure out by myself. Using this works:space characters don't matter.

I think the numbers aren't handled as numbers (but strings) in the search. So my "rating:3 or 4" above probably was handled asand there is no rating with <space>4.

Yep, correct.

Especially now that all sorts of data are allowed in all extra tag columns it makes sense that the searched data are always treated as strings. The user might have intended to look for " 4".

admin wrote:Yep, correct.

Especially now that all sorts of data are allowed in all extra tag columns it makes sense that the searched data are always treated as strings. The user might have intended to look for " 4".

I am not entirely sure. It is rather misleading. I have just created a search by custom column Pages (property 148). ?Pages:1 should mean documents with exactly 1 page. Numeric column, numeric literal, there is no point in treating like a string *1*. (And the outcome of ?Pages:1 also doesn't have any sense.) That's why I feel your example with Rating column and " 4" is also a bit odd.

EDIT: I have this custom column Pages in the Document folder. I wanted to collect all 1 page documents. I did the search. I got the result, but I couldn't check because Find view didn't contain the Pages column. The file sizes made me suspicious that I got wrong list. I had to add Pages manually, then remove it, because I didn't want Pages to stick in the Find view.

LittleBiG wrote:

admin wrote:Yep, correct.

Especially now that all sorts of data are allowed in all extra tag columns it makes sense that the searched data are always treated as strings. The user might have intended to look for " 4".

I am not entirely sure. It is rather misleading. I have just created a search by custom column Pages (property 148). ?Pages:1 should mean documents with exactly 1 page. Numeric column, numeric literal, there is no point in treating like a string *1*. (And the outcome of ?Pages:1 also doesn't have any sense.) That's why I feel your example with Rating column and " 4" is also a bit odd.

EDIT: I have this custom column Pages in the Document folder. I wanted to collect all 1 page documents. I did the search. I got the result, but I couldn't check because Find view didn't contain the Pages column. The file sizes made me suspicious that I got wrong list. I had to add Pages manually, then remove it, because I didn't want Pages to stick in the Find view.

1. Hmm, not sure. Needs refined thinking...

2. Yes, dito. Maybe I need something like throw-away columns. Phase 2...

As this works now, later you should put into the help file that "1" is necessary to get the desired result, because I think significant amount of newbies will fall into this "trap". I mean if you ask an average XY user without background knowledge about the storing of cc, that what is the expected result of ?Pages:1, I am sure that almost nobody would say, that the result is all files whose number of pages contains the digit "1". So you could save time for them. This didn't cause real problem in case of ratings, because a rating is only 1 digit, so ?Ratings:1 and ?Ratings:"1" mean the same thing. However, what a difference with the Pages property!

Ok, I stop nagging you with this, I am sure you can clearly see the downside by now. And probably you didn't plan CC only for geeks.

I finished my refined thinking. Result: You are right.

Changes coming...

Wow, thanks. I feel it natural, no trap any more.

Ah, one little flaw. "?Pages: > 40" gives back the 5 too. Natural numeric sort order would be good here too.

Yep, fix comes.