XYplorer Beta Club

I have noticed that when using SC report with itemlist flag 1 or 0, that the date fields don't return NTFS time resolution even down to ms, eg if I select a file and run: e report("{Modified fff}", 1); I get all 0's, but if I enable milliseconds in the visible List column then it returns them, but no further, ie it doesn't go down to 100ns if I include the extra resolution. (unless use SC msecs)

If I supply full paths instead, then it returns full resolution, is that a known requirement?

Additionally it seems that reporting on Custom Columns doesn't work when using 1/0 as itemlist flags either, eg

1) That's as intended. If itemlist is not set to a specific path, you will get the information that's currently present in the list. It's a report on the list, rather than on the items.

2) It seems to work here. What exactly do you mean by "doesn't work"?

1) Yeah I thought that was the case, but didn't think it applied to the date columns.

2) So if you go into a fresh instance and run both those commands as 1 script, you get a return for both? I only get a return for the first one, even if I've added Custom Column 1 to the list.

Yes, but only if images are listed. {Custom 1} by default is Dimensions.

Yes I realize that, but I don't get a return. eg.

Weird! I perfectly recreated your situation and it works fine here.

Maybe it is Win10 only? Another user coincidentally reported something similar here afterwards, that I think is because of the same cause.

viewtopic.php?t=28499

I'll check tomorrow. Although it does not look like something where the OS version plays a role.

I wouldn't have thought so either, I'm just very surprised it works for you, and that was one thing we didn't have in common, initially I thought it might have something to do with "Skip Custom Columns".

I just noticed, (for me) if I duplicate CC1 into CC11 it works, but not in CC#1-10.

I could now see it on Win8.1 as well, so as expected it's not dependent on the OS. (I don't know why I didn't see it yesterday. ) However, once I show the Custom Column in the list the report is done correctly. This is expected because Custom Columns are only filled when visible (for performance). So, IMO, it's not a bug because again: If itemlist is not set to a specific path, you will get the information that's currently present in the list. It's a report on the list, rather than on the items.

Yeah I am still mystified how you didn't see it yesterday either. It seems to matter how the column is originally added to the list, if done via Show Column it works for me too, if done via Add Column, it fails for me, so that's possibly the difference between us, I think I have demoed this discrepancy in the script below. Although what you said in your last post doesn't make sense to me because in the GIF I previously posted, it clearly shows that I have the column visible so the info IS present in the list, but like I mentioned in my last post, the issue only happens in CC#1>10.

Anyway I will try again to show you the issue(s), it requires minimal effort, in a fresh instance all you need to do is goto a folder that has audio files in it and run this script.
If there is no bug, and assuming you get output the same as me (risky...), can you explain why the results are different between the top and bottom sections? Just for a visual, below is a screenshot of what I get, so as well as itemlist 0 not working on CC#1>10, notice that Custom 11 which should be "Channels" is returning the values of Custom 10 instead somehow.


Crazier still, if I add Custom 16 to the list, then Custom 11 gets reported correctly, but only when it should be reporting on Custom 16! eg.

Okay, that was a deeply rooted bug. Took me 4 hours to get down to it and fix it. Try the next beta.

All looks good in .0103 so far, nice work.

I have now noticed an issue, you can't Add custom columns #1>10 anymore via GUI, to repro,

Add Column
RClick and Select Custom Column
Column Disappears

also, historically this worked setcolumns(":d-1", 8);