07-14-2020 08:49 AM
I renamed a namespace and I'm left with this discrepancy:
The code works, but the it's disconcerting to say these old names hanging around (SCPITestFramework was the original name.) There's quite a few of these 'funnies' kicking around - it's not just namespaces, the rename feature doesn't seem to change all instances of the original name, although the application will still work.
Is there a way to fix these?
Solved! Go to Solution.
07-14-2020 01:21 PM
Hmmm, I've actually not seen this. Or, more correctly, I haven't noticed it. Have you tried hiding the label and then showing it again? Maybe it's just a refresh issue. I know this doesn't ultimately help you because you'd have to go through your entire code to fix them, but I'm curious. What does the context help say?
I don't have NXG at work, so I'll have to go home to experiment.
07-14-2020 04:23 PM
The wire was actually added today but I renamed that namespace a week or more ago; all I'm doing in the above image is hovering the cursor on the wire. So it affects new wires and old wires and seems fairly prevalent. Same with other nodes as well: for example, I can drop a class instance onto the diagram and link a Class Properties and the name of that shows the old namespace as well.
My working theory is that internally, references are kept with some form of UUID so the app works, but in the saved files (XML??) the 'names' are not being changed and are read and presented as-is. I've not wanted to fiddle with the files directly because NXG seems fairly fragile - it crashes and aborts a lot, rather than error out which is an issue with the way it saves, and I have to regularly clear the .cache file when it gets its knickers in a twist - so I don't want to do anything without specific guidance or advice.
07-14-2020 05:04 PM
I've heard that the all controls and VIs were xml files to be more versioning software friendly, but it had unexpected consequences that weren't versioning software friendly.
Since xml files are just text, VIs are no longer thought of as "binary" files, so your favorite versioning software can use its fancy text algorithms to save only the parts that change. BUT... because they are now text files, if two people edit the same revision of a VI, your versioning software just might use its fancy text merge algorithms to patch together a mixture of both files, instead of declaring a conflict. This would cause a headache as the resulting "VI" would likely be corrupt.
In reality, it's just not as obvious what happened; the remedy would be the same in LV Classic and NXG - choose one file over the other.
07-15-2020 01:55 PM
Fortunately, I don't need to worry about versioning conflicts (unless I get something very wrong!!) The problem does lie in the XML files:
This is just a partial snapshot of the node I show. It would appear that renaming a resource in NXG does not change the Target/TargetName attributes in the XML file(s); I assume that internally at least, it uses the various ID attributes which is why it still works.
I suppose the question is: "Can I do that manually?". That checksum at the start would be a concern for a start. But really, I'm refactoring quite a lot so how many times do I need to do it?? I have a lot of files so more times than I have the patience for, that's for sure. But it's annoying in any case.
I'm assuming this is a bug of some sort.
07-15-2020 02:52 PM
It has to be some kind of bug. I'm sure it's not expected behavior. At least, it's not what I would expect it to do.
08-09-2020 03:31 PM - edited 08-09-2020 03:32 PM
It’s worth closing this off. I used BBEdit to find all occurrences of the old namespace in all project files and change to the new namespace (>3000 occurrences in my case although heaven only knows why so many!). Everything is good afterwards.
Really, this should be fixed. What drove me to it was a working project on Friday evening, and a broken one on Saturday morning because at least one class and a couple of it’s VIs (not all of them though) had ‘changed’ to the new namespace and broken dependencies across multiple places. How, I have no idea, nothing I did.
What doesn’t help is the Errors view only shows errors for the selected VI/class and immediate dependencies rather than ALL errors so tracking them down is a boring,manual task. Coupled with this is the possibility to run a working VI that at some point calls an unidentified broken VI causing NXG to crash and burn losing any changes in silently changed files not saved!
08-09-2020 08:22 PM
What a sucky workaround, huh? And it only helps for the instances that you are aware of. And it means that you have to manually keep track of everything. Ugh.
08-10-2020 04:08 AM
Yeh, it sucks but fortunately BBEdit is rock-solid so I can trust what it does! And fortunately it has a batch find-replace function that can walk down a directory structure. MacOS only unfortunately.
On the one hand, I really like NXG; on the other, the ‘silent changes’ and the willingness of NXG to crash and burn at the slightest provocation is frustrating. These two things in combination are a real, work-losing issue.
The error reporting is frustrating as well. I had a VI that was reported ‘good’ and I could run, but at some point NXG broke down in tears and threw its toys out of the pram. All I could do was reload NXG and single-step through the calling hierarchy until it reached the VI causing the issue, reload again and then inspect: NXG said it was good but in fact it turned out there was a missing wire on the ‘Error’ case causing the problem.
Now I’m aware of these issues I can work around them but I’m happy to persevere and lucky I don’t use it for production/work stuff. Having thought about the git integration a little more I’d be very concerned that developing across a team would lead to XML file corruptions: no evidence of course, and little LabVIEW experience, just instinct telling me something isn’t quite right with the way NXG is managing its dependencies.
I don’t want this to read as a rant by the way because I do like it! I just figure it’s worth highlighting some of the problems for others who come across my threads.
08-10-2020 11:50 AM
Hello Andrew and Bill,
I remember having this same problem when I did a project in NXG and having to ask our team "wait! Why is my name wrong if I already renamed the Library!" (I had a typo in my library's original name).
Turns out the Library has a namespace inside of it (similar to what VisualStudio does, of course, not fair to compare one to the other). This means that the library name and the namespace are different once the library is created.
To rename the namespace and have NXG do all that work of searching and replacing for you, just change the namespace name inside the library by right clicking on it in the following view:
All the best,