Something about UB and filesystem
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 22/05/2007 at 15:13, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R10
Platform: Windows ; Mac OSX ;
Language(s) : C++ ;---------
Is there something that someone needs to tell me about why the R10 UB plugins have difficulty with folder/file access?So far I've found that thumbnails loaded from resources sometimes don't - not always don't, just here and there and this usually occurs at the end of the list. A refresh of my plugin's thumbnail list usually resolves it - but this assuredly isn't my code (it hasn't changed in forever in a way that would cause this odd behavior). BrowseFiles looks to be something at which to point a finger.
Further and proclaiming more of my innocence, some MacOS UB users are not getting folders/files filled into their trees when unfolding the master folders - which would be directly related to BrowseFiles again. This makes no sense and I cannot replicate this behavior, yet it has been raised by several users - screenshots and all.
Although this is indeterminate, seems to be related to Mac R10 only. I'm thinking either there is a bug in C4D SDK file access code or that Xcode is creating bad code in this respect (which could be related to almost anything - a framework, the compiler/linker, some dylib, who knows). It definitely looks like BrowseFiles is requesting items in a folder and it is failing either completely or partially.
Just letting you know and hoping that someone can explain why this might be happening.
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 22/05/2007 at 17:45, xxxxxxxx wrote:
Just to add - in R10 there is a change in the BrowseFiles->Init(). What exact does BROWSEFILES_SUPPRESSCACHING do? Could this be implicit to the problem?
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/09/2007 at 17:53, xxxxxxxx wrote:
Resurrecting this topic since there are still MacOS users of R10 having difficulty with file paths on ocassion. This is still related to a tree which reflects a real folder/file structure and why concatenated paths (class Filename) don't result in proper filling of the folders when using BrowseFiles.
It is difficult to determine a cause when I cannot recreate this problem - same type of system Intel Mac. I will continue to investigate but it would be nice if support could chime in here.
Thanks,
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 28/09/2007 at 09:40, xxxxxxxx wrote:
Hmm, I don´t have experience with Treeviews and BrowseFiles but I never had problems so far with BrowseFiles in R10 (I am using it for my preset system), neither on MAC nor on PC.
Can you post a code snippet of the area of interest? Although there cannot be much to it. Here is my allocation part:
> _ BrowseFiles *bf = BrowseFiles::Alloc();
> if(bf)
> {
> bf->Init(libdir,FALSE);
> BaseContainer cycle = des->GetContainer(DESC_CYCLE);
> LONG counter=1; //This is the index of the preset file
> while (bf->GetNext()) //always get the next file
> {
> Filename subfile = libdir+Filename(bf->GetFilename());
>
> if(subfile.CheckSuffix("fsh"))
> {
> Filename fn = subfile.GetFile();
> [...]
> }
> }
>
> BrowseFiles::Free(bf);_ -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 28/09/2007 at 11:40, xxxxxxxx wrote:
Ah, there is your mistake young padawan!
My code builds an entire folder/file structure so that when it encounters another folder it has to create the tree entry for the folder and then start a new BrowseFiles traversal (and so on down into the folder heirarchy). This is done in the RuntimeItem class - see below - which can represent three things: runtime, folder, or file. The BrowseFiles is never reused - and AutoAlloc<BrowseFiles> bf is used for automatic cleanup.
Additionally, the TreeView needs a root which points to tree nodes. The cinema4dsdk example is a bit circular as it doesn't show an independent use of the TreeView - just how the 'tree view' in the Object Manager can be mirrored in the TreeView. When not using such a basic approach, one must create their own classes to perform these functions. In my case, the TreeRoot class retains the head-tail of the upper level tree objects and other info. The RuntimeItem class represents the hierarchical nodes which must have connections to the parent, child, previous and next nodal objects (for a complete tree structure).
But that isn't the problem I suspect. The problem seems to have something to do with MacOS X and the R10 UB change over to '/' with //Volumes/', if you haven't seen it yet, BrowseVolumes, and more than likely Xcode. The same user who had blank main folders in R10 UB had no trouble in R9.6 classic (CodeWarrior) because this new path specification isn't involved in PPC plugins. This problem only seems to arise in the UB versions and is completely unknown in the Windows and PPC versions.
Since I'm dealing with thousands (or tens of thousands) of folders and files, it is not recommended to store the entire path to each node - the memory difference between an on-demand path concatenation and entire path storage can be astounding at these counts. My code does have strategies to only fill in selected or open folders (again on-demand which is frightful enough to manage) but if the user so desired, he/she could unfold all folders exposing every folder and file (10,000 * 128 (average characters) = 1.28MB just for the path strings). That's conservative. One of my Poser Runtimes has 2000+ folders and 31750+ files (divided by two as the thumbnail file doesn't count here)!
To make a long story short (too late?), it always seems to get the Runtime path (since it is a full path by its nature) but then fails in concatenation as the user attempts to traverse the folder hierarchy. As noted, this problem isn't replicable. I and others have no problems but some do. Interestingly, a new build of the plugin was enough to resolve the issue for the user - which doesn't make me feel comfortable at all. If Xcode is flaky in ways like this - how can I guarantee anything and how can I resolve problems like this? It is starting to look like Xcode couldn't build the code the same way twice.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/09/2007 at 12:36, xxxxxxxx wrote:
LOL.
I make the story short: XCode sucks! 
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/09/2007 at 12:57, xxxxxxxx wrote:
Amen, brother!