XYplorer Beta Club

I have noticed an issue with LF when using the Length: prop selector, if I use a LF such as Length: 01:00:00 it works, but if I add the Length shell column to the list pane it stops working, furthermore if I use the new context menu on the shell column the LF that gets added to the LF box is :n-27: 01:00:00 or using the XY special property column :s-audio.length: 01:00:00 or even a CC :d-Length: 01:00:00 which all obviously don't work. Of course I still have a working workaround of using the full prop selector string which does work even with any of the Length columns showing.

The above LF selector issue applies to all other shell/special/custom columns I tried (and obviously QuickSearch context menu selectors too), I was just using "Length" as an example above because of the extra issue of it working until the column is shown.

Currently using v22.50.0108.

Both confirmed.

1) If there are two columns with the same name, the parser has no way of knowing which to compare the pattern with. The first (left-most) column with a matching name will be taken.
FYI, if you change the positions of the columns you will need a tab switch (or a restart) to actually change what's seen as the left-most column internally.

2) Fixed in next beta.

Now using the XY special property column context menu, it inserts the Length in 00:00.000 format which doesn't produce results, converting to normal format manually does but only exact matches not comparisons, it can get confusing, previously it used to insert in the normal format which would make it always work, but I guess it was comparing it to the wrong column then though.

Actually on further testing if you add Length columns/remove them but only have 1 active the filtering keeps start stop working, sometimes it works for exact matches, but comparisons don't work, its hard to narrow down the exact scenario but something doesn't quite seem right, tab switch doesn't always fix it (could "LF off" provide a reset instead?), comparisons don't seem to work regularly especially when the shell column is showing.

I guess when you say "change column positions" that includes just adding a column to the list, it is real easy currently to have filtering not working though.

Comparison seems to work here: As I said before, when you have two columns with the same name the parser will have to guess which one you meant.

PS: Oha, looks like comparisons work with Special Property but not with Property columns.

Yep, there was something murky. The format "##:##:##" was interpreted as a "date" (because it looks like a time) at one point. Fixed in next beta.

BTW, if you have two columns with the same name: just rename one of them. Problem solved.

I realize about having 2 columns with the same name visible simultaneously, I never was trying that when reporting, anyway it looks a lot better now, but still seeing issues with the Special Property column, I think you may not have seen it because you only tried using short mp3's, when the digits get longer comparisons don't work, eg "##:##:##.###", also the sorting looks incorrect.

With the files in the below screenshot you'll see that if I use the live filter, "##:##.###" it doesn't show the longer files that require the extra 3 chars, and vice versa when I add the extra chars it still shows the shorter files. (as pictured)


If this looks like it could be a can of worms, its not something I will encounter in my use, I'm just providing feedback from testing.

I fixed the comparisons, but left the sorting as it is for now.

Don, I noticed that search by Label index only works when extended pattern matching is enabled, is that correct?

eg Label:"#1"

This applies to VF, LF, QS.

Also when using softlabels, Catalog Click and Search: Labels, doesn't work when you OR the filter (or just use the checkbox) because the terms are unquoted, not sure if you think it should.

Additionally, toolbar Find by Label still searches by caption not index, so searches fail if using softlabels, it seems to also double up the query too when softlabels have been used, ie. it uses the lbl caption as query & location. (instead of ThisPC)

jupe wrote: ↑03 Jan 2024 02:02 Don, I noticed that search by Label index only works when extended pattern matching is enabled, is that correct?

eg Label:"#1"

This applies to VF, LF, QS.

Indeed. I would have been less surprised if you'd said "only works when extended pattern matching is disabled".

jupe wrote: ↑03 Jan 2024 02:02 Also when using softlabels, Catalog Click and Search: Labels, doesn't work when you OR the filter (or just use the checkbox) because the terms are unquoted, not sure if you think it should.

Additionally, toolbar Find by Label still searches by caption not index, so searches fail if using softlabels, it seems to also double up the query too when softlabels have been used, ie. it uses the lbl caption as query & location. (instead of ThisPC)

Both should be fixed in the next beta.

admin wrote: ↑05 Jan 2024 09:48 Indeed. I would have been less surprised if you'd said "only works when extended pattern matching is disabled".

Strange, for me it was the opposite, worked only when it was enabled, anyway both work now.

One other thing I noticed, was that the cell context menu uses the literal string for Label column even when soft-labelled, unsure if you want to leave that as is.

jupe wrote: ↑05 Jan 2024 23:48

admin wrote: ↑05 Jan 2024 09:48 Indeed. I would have been less surprised if you'd said "only works when extended pattern matching is disabled".

Strange, for me it was the opposite, worked only when it was enabled, anyway both work now.

For me, too, I was just surprised that it wasn't the other way around.

jupe wrote: ↑05 Jan 2024 23:48 One other thing I noticed, was that the cell context menu uses the literal string for Label column even when soft-labelled, unsure if you want to leave that as is.

Yes, I was not sure how to do it myself. I had to make a decision and this is what I did. (Well, I could offer both... maybe later...)

Don, not sure if this is locale specific, but when using cell ctx menu on date column the date is entered in ISO8601, which works for exact matches, but I find to get comparisons to work I have to swap the hyphen for /, is this by design?