Add column for "row number" within results list?

[andymbody]

I've tried to find a way to add a column to the results-list that would show the row number/index of each item in the list. Basically a 'list-index'. Much like you see in Excel on the far left of the table. I have been unsuccessful at finding such a 'column' within the list of possible columns that we can add. I have tried searching the forum as well. Maybe it would be called something different?

Is this 'row number/index' or 'list index' an available option?

Thanks!
Andy

[meteorquake]

I'm actually intrigued by the case use for this if it's not for an exported list (which is easy to add if it is)! - d

[andymbody]

I'm actually intrigued by the case use for this if it's not for an exported list (which is easy to add if it is)! - d

Currently it is to keep track of the details of the list from an external script I am writing... using the row index sort of like a key. This will help detect whether the list was resorted, changed, etc... since EverythingApp doesn't have any type of api, etc. It would also allow much quicker access to the data on the fly (as long as the list doesn't change) by using the index as a reference to specific data within the list. That and I like the reference while viewing the data (personal choice). I don't expect this to be added, just wondered if it is currently available. There are other ways that I can accomplish the task, but will probably perform much slower, and require more coding.

Andy

[void]

I'll have a row property in the next alpha update to show the current row number (1-based)

Thank you for the suggestion.

[andymbody]

I'll have a row property in the next alpha update to show the current row number (1-based)

oh Wow! Thank you!

[void]

Everything 1.5.0.1331a adds a row property.

This is the 1-based index of the file/folder result.

Sorting by row doesn't make much sense, so Everything is just sorting by name for now.
Searching for the row index with row: doesn't make any sense either, so it also does nothing for now.

[andymbody]

WOW!! I was editing my last post because I saw that you had posted this update a little while ago... You are amazing!! Thank you sir!

I will simply post my question within a new reply...

I am currently using the portable version of 1330a... Everything is in the middle of an index operation (for 2 days now). I have a couple questions regarding switching to the latest portable ver 1331a...

If I were to...
1. Pause the current index with 1330a
2. Exit ET
3. Copy v1331a to same folder as v1330a
4. Run v1331a...

Q1. Would v1331a be able to use all the support files within the directory without an issue?
Q2. Would v1331a resume the index where v1330a left off (with no issue)?

My assumption is that the answer to both questions is Yes, but I want to make sure.

OR... should I just wait till the current index operation completes (maybe 24 more hours)

Thanks!
Andy

[void]

Q1. Would v1331a be able to use all the support files within the directory without an issue?

Yes.

Q2. Would v1331a resume the index where v1330a left off (with no issue)?

Yes.

Some alpha updates will require a database rebuild.
I make sure I have a bold note in the change log to indicate these required rebuilds.

[andymbody]

You're too quick for me! lol

Sorting by row doesn't make much sense, so Everything is just sorting by name for now.
Searching for the row index with row: doesn't make any sense either, so it also does nothing for now.

Yes, I see your point... and I agree for the most part... the use that I had was for an external script I am writing... I am able to access the results-list and it's column headers via api/dll calls and process the data there (I hope you have no objections to this 'hack'). An alternative would be to automate an export for processing but I have a need to process on the fly quickly, rather than involving disk storage. Please let me know if you object to this type of thing...

The other use for the row index would be for marking locations within the list as requested here...Jump in the file list.

If the Row property were searchable, it could be used to mark locations within the list very easily. I had planned to update the external script that I wrote for this purpose, which would then be able to keep track of "marks" within the list. Currently I'm using the filename for this purpose but obviously duplicate file names would cause an issue. So the row index becomes a unique key. Of course, once you introduce the FIND feature in the future, an external solution would be unnecessary.

Andy