08-14-2013 11:00 AM
I've just stumbled across a small hassle: using a config file to store a path causes some headaches down the road. When a Windows or Mac path is stored, it uses Linux encoding. When reading the path back in, it stays in Linux encoding. Attempting to use the strip path primitive results in the entire path being passed as the name output and "." being passed as the stripped path. This makes it difficult to use build/strip path when dealing with config file key paths and system constant or dialog paths.
System:
Attached is a demo that shows the correct and mixed separators cases.
Is the intended operation of Read Key (path polymorph) to leave the path in Linux encoding? Most other path-input primitives seem OK with Linux encoding.
08-14-2013 11:17 AM
How are you reading the config file? The Key Read VI converts it back just fine.
08-14-2013 12:00 PM
This is really strange: now I can't reproduce the origin of the bug. Probing the output from all of the associated read keys shows the path being correctly converted. I'm not sure how I could have gotten the string value instead of the path and converted it to a path object--without deliberately doing so.
08-14-2013 12:55 PM
@Cranky wrote:
This is really strange: now I can't reproduce the origin of the bug. Probing the output from all of the associated read keys shows the path being correctly converted. I'm not sure how I could have gotten the string value instead of the path and converted it to a path object--without deliberately doing so.
you probably crossed the 8.6 - 2009 boundry at some point and got a depreciated 8.6 write to the config file at some point.
(Do not mix 8.6 or earlier and 2009 and later config file functions)