Replacement for compoundFile.RootStorage.VisitEntries in 3.0.0 #304
-
|
I am looking at replacing the use of compoundFile.RootStorage.VisitEntries in existing code. While CompoundFile no longer exists, and RootStorage does not have a VisitEntries method, I have seen that it is possible to get an enumeration of EntryInfo as: and if the entry is a Stream, it should be able to be opened by EntryInfo name. If it is a Storage be opened as a new root to access a sub hierachy? In such case a recursive method would work to visit each entry as VisitEntries did - unless there is some other easier way that I am missing? Edit: Opening streams by EntryInfo name works fine, but opening a storage entry as a root does not. It seems you need to OpenStorage as in: I will test if this works the way I'm hoping. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
I did a few tries, including using entry.Type == EntryType.Storage to try to only find storage objects, but unfortunately I did not manage to get this to work. We decided to move away from a VisitEntries type of solution in the end, so I'm afraid I won't be testing this any further. However, if someone else needs a replacement for VisitEntries, hopefully some of this will point them in the right direction. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like a reasonable task for an LLM to generate an extension/utility method for you (I'd recommend specifying a stack-based approach rather than recursion since v3 supports arbitrarily large files/trees). So, I don't think there's anything in the new API that would prevent this, but storages and streams no longer have a common base class (and it wouldn't really make sense or even be possible to do that in v3). |
Beta Was this translation helpful? Give feedback.
Sounds like a reasonable task for an LLM to generate an extension/utility method for you (I'd recommend specifying a stack-based approach rather than recursion since v3 supports arbitrarily large files/trees). So, I don't think there's anything in the new API that would prevent this, but storages and streams no longer have a common base class (and it wouldn't really make sense or even be possible to do that in v3).