12-01-2015 02:33 AM
In our company we have a library module to handle message logging, which is part of almost every LV project. It is implemented using the Actor Framework.
Right now I am working on a project, which needs to have quite a long directory path inside our SVN structure as well as on my hard drive. The build destination should also be in some deep path.
This made me run into an error while building the application: Some of the destination paths for files of the AF messages would turn out to be more than 260 characters and that breaks the build.
The reason for this is that we used some quite long VI names to generate messages from.
So there are equally long directory names with long class names inside as well as long "Send XYZ.vi" names.
Renaming the directories was simple and helped a little bit, but it wasn't enough,
Now I would like to rename the message classes, which seems to be impossible ("Save As..." is grayed out for these classes).
It would be ideal to rename the VI along with it's class and Send VI in one big step, but since I doubt there is any way to do this, I would be thankfull if someone could show me a way to do this manually.
I am using LV 2014SP1, in case that matters.
BTW: Why is it possible that in 2015 we still suffer from this arbitrary MAX_PATHLEN setting introduced several decades ago?
12-01-2015 12:18 PM
I am using LV 2013. Tried "right click" on the class and then "rename". worked with my classes and msgs.
regards
12-03-2015 07:56 AM
silmaril wrote:
BTW: Why is it possible that in 2015 we still suffer from this arbitrary MAX_PATHLEN setting introduced several decades ago?
at least now we get a descriptive error, it used to be a generic error 6 before.
It is ugly, but what we have resorted to is to have our source code for our projects in C:\<project name>\
If you have a separate build server, you could keep your current working directory structure you have and just use the C: structure at the build server.
12-03-2015 09:27 AM
silmaril wrote:
BTW: Why is it possible that in 2015 we still suffer from this arbitrary MAX_PATHLEN setting introduced several decades ago?
Because MS Windows still has that limit on many of their underlying APIs.
We refactored the Path data type years ago to be able to handle longer paths, but we have to limit it often when the paths are actually used in various places.