although creating objects with variable case works fine on all plattforms,
what doesn't work is the help patches - at least on windows. for example,
if you look for help from [Line~], you'll get [line~] instead. would it be
possible to correct this to make it more cohese? or is the help search
plattform dependent, and thus impossible to fix?
On 2010-04-25 15:04, Mathieu Bouchard wrote:
On Sun, 25 Apr 2010, Frank Barknecht wrote:
Just a quick note: as operating systems treat upper- and lowercase in filenames differently (Linux is picky and will not load renderDepthSelector.pd for an object called [renderdepthselector], while Windows and OS-X will do), I try to avoid uppercase in abstraction names.
On Windows and OSX, [renderdepthselector] won't create either, though the file will be open. GetProcAddress and dlsym are case-sensitive. Then after that, class_new is case-sensitive too (because selectors are case-sensitive).
all true, but GetProcAddress will never be called for a file called "renderDepthSelector.pd".
anyhow, i (personally) don't think that CamelCase objectnames are bad. just make sure that you really use them throughout, both on the filesystem level and on the patching level. (or even better: switch to a case sensitive filesystem in the first place :-))
Or you go with operating system features: On *nix systems you could use a symbolic link like "ln -s renderDepthSelector.pd rds.pd".
Only on filesystems that support it. I say that because FAT is becoming *more* common on those operating systems; so when you transmit the file using flash-memory formatted the default way, you have to tar it or zip
it.i didn't know that zip would handle symbolic links. (never tried though) thanks for the idea.
fgmasdr IOhannes