Is it correct to say that Opus does not offer a way of creating an enumeration set of specific items based on a list of filenames?
When the result of a search is a list of filenames and paths, I can do the following:
Run a select command on each one, get the item object, and add it to, say, a vector
I could do an AddFile() or AddFiles() to add them to a Func.command object - but not to add them to a vector (so maybe I can "abuse" the command object as an alternative vector?)
Alternatively, if the files are in the same folder structure, I can run FSUtil.ReadDir() giving it the root path where to start, which will enumerate them all (too bad if there are thousands of them). I can't give a "Select PATTERN" kind of filter to ReadDir(). But I can, according to the documentation, increase its performance by passing my own vector object to FolderEnum.Next().
In other words: There is no straightforward way to turn my list of filepath/name strings into a collection of items without effectively selecting each item first? (And then restore the original selected file, because my script needs that).
Maybe I'm (once again) simply missing out because I never studied the entire manual - I usually query the forum and the manual, but I couldn't find a way how to do this.
It is the result of a" Select PATTERN" query in my case. The problem is I do not really want those files selected, because I then need to restore my original selection. The workaround works, but sometimes it doesn't (I need to add "Select THIS" to get real focus again on the original, etc.). It works most of the time, but it feels a lot like I'm doing workarounds. I was just curious if there's something else to get to an enumerated list of wanted items, with messing around with unneeded selects.
Okay, so I'll stick with my workaround. I compensate for lack of enumarators in multiple scripts already, and in different ways. Just an example to illustrate the dilemma - in this case with foldernames (same issue as with files of course).
if (boolAlternatePath) {
//Todo: obtain a 'dirs' object that is a collection?
var dirs = DOpus.FSUtil.ReadDir(startpath);//Unfortunately not a collection
while (!dirs.complete) {
var item=dirs.next();if (!item.is_dir) continue; //Skip files
StoreDirs(item, type, countix);
countix++;
}
} else {
var dirs = tab.dirs; //This is a collection
for (var eDirs = new Enumerator(dirs); !eDirs.atEnd(); eDirs.moveNext()) StoreDirs(eDirs.item(), type);
}
It was indeed a bad example for my case (older code that I didn't yet adapt). The real point is that I would still need to loop through all 2055 items that result from this FolderEnum in order to get 5 items or so, because it doesn't accept a regex pattern (according to documentation). But it will of course work.
An "AddFile()" based on my list of path/files would of course be more convenient, but I can still select them one by one to get to my item objects. Or I should adapt my entire logic. Imagine you gather files (and their paths) in a listview. At the end you want to do an analysis for which you need the item objects. Solution is probably to keep those items in a vector - or map - in parallel to my listview (and delete them in parallell too, when I remove one from the listview). In the end every problem is one "of our own making" of course. I can't expect Opus to have RegEx, and ways to turn paths into items, wherever I need it.
I agree that being able to add some wildcard pattern to ReadFile would be convenient.
In the end, it should probably not be very different performance wise than doing it yourself by enumerating all the files and folders, since that has to be done somewhere.
I think the only thing that would prevent you from this is what you mentioned in the first post:
Store currently selected files (or do not modify the command object in scriptCmdData.func which already has them in command.files)
Execute a command to Select what you need,
Get the selected files from the active tab object and store them
Restore initial selection if you really need them selected, or just use scriptCmdData.func.command.files if you need to act upon these files (or the scriptCmdData.func.command to run what you need if you only need to act).
Note that this method allows for smarter selections than just wildcard, as it opens up the ability to use filters.
As I am writing this, I wonder if using a Find command (ran from your script) to select files and put them in a collection dedicated to your script could also be a solution.
You execute your Find command (with the option to clear up the collection before finding) and then use ReadDir to read the collection (to be tested ... FSUtil.ReadDir("coll://myScriptCollection");).
Yeah, @PassThePeas , those are all valid points. But, as I said, it would require me to rebuild an entire application, where I gather file data in a listview, often in several moves. So I should start keeping a map of objects in parallell and treat them in parallel. It's just too much work, so I think I have to stick with doing all those separate select statements, for now - and they sometimes don't work (probably because of loss of focus, or they are in subfolders that are opened in "glyph" mode (or whatever you call it). But most of the time it works.
I'm glad you agree that my reasoning about the ReadFile limits isn't nonsensical.
