09-18-2019 10:26 AM - edited 09-18-2019 10:35 AM
Hi,
Background :
Description :
09-18-2019 07:17 PM
I can't offer you an idea for solving the problem, but I wonder why you need it to be stored on the network? If you store it there for:
Then I would suggest you look into using some sort of source code control, which will allow you to do all of this and has other advantages too. And it would prevent this crash because at edit-time the files would be loaded locally.
09-19-2019 07:49 AM
09-19-2019 08:00 AM
@JB wrote:
...
- If the XControl subdirectory is on the network but not set to Auto-populating in the project, LV doesn't crash either.
All my gratitude in advance for any indication that will allow me to solve this strange and blocking problem.
I do not use Auto-populating folders, so I can not share the joy but...
Could there be an issue with the path length when the XControl is located on the shared drive?
Ben
09-19-2019 10:10 AM
Is there a permissions issue with accessing the network drive?
09-20-2019 03:09 AM
@Ben and Mark_Yedinak : unfortunately not. This would be too easy to solve.
Thank you !
09-20-2019 03:27 AM
I do not use Auto-populating folders, so I can not share the joy but...
Ben
09-20-2019 07:29 AM
@JB wrote:
...:
- The problem only appears on this computer but for all projects using the XControl.
...
Tools >>> Advanced >>> Clear Compiled Object Cache... ?
Ben
09-20-2019 07:45 AM
@JB wrote:
I do not use Auto-populating folders, so I can not share the joy but...
Ben
Out of curiosity, why do you not use Auto-populating folders ?
I use Libraries (see here) whenever I get a chance.
At one point Auto-populating folders, when used with large project was killing performance since LV was preoccupied with mucking about looking for files to add to the project.
Additionally I can compose architectures as deep as I want without pushing the file paths lengths.
Using Auto-populate with libraries would include VIs that I did not want. Say I did a quick test VI to test an idea and I saved it in a folder and then forgot about it and then latter that test VI broke. Come build time LV would start complaining about a VI that I had never intended to include.
My Libraries have public and private virtual folders. The VI intended to be used (by other developers working the same project) are in the public and the one not intended to be used outside the library are in the private folder. If I discover that I wanted to expose a VI that was first in the private folder, would then have to be moved to different folder if using auto-populate.
Then there was an issue in early versions of LVOOP where I read AQ write that LV would be happier if the folder structure was flat.... but that was a long time ago.
I will stop with the diatribe and end with an analogy.
Presenting an application in both a disk folder view and a unique Project view is like looking at a soda can from the end or from the side.
Having two views of the same thing lets us see we are not looking at a sphere or a rectangle but rather a cylinder.
Take care,
Ben
09-20-2019 10:16 AM - edited 09-20-2019 10:17 AM