Endless NXG control loading when trying to open project

[IlluminatedG]

I'm curious if anyone has already run into this before I submit a support request.

I've got a project that gets "stuck" loading NXG controls and just keeps going... and going... and going... and going... and going... and going... and going... and going... and requires killing with task manager.

In the log file is an entry for DWarn 0xDE90B5AC: typeprop caused typeprop a third time! I'm also unfamiliar with this <libdir> pseudopath it's pointing at. I've tried deleting the VI from disk that it references just so I can get the project open but that hasn't helped. I'm assuming I'll be submitting a support request later today.

No. I cannot share the code.

[IlluminatedG]

Clearing cache, mass compiling, deleting VIs from disk that are mentioned in the LV logs... nothing gets it unstuck. I though maybe there was some corruption from a git merge so I've checked out back to work before the merge and no dice. LabVIEW just hates this project now.

[billko]

---

@IlluminatedG wrote:

Clearing cache, mass compiling, deleting VIs from disk that are mentioned in the LV logs... nothing gets it unstuck. I though maybe there was some corruption from a git merge so I've checked out back to work before the merge and no dice. LabVIEW just hates this project now.

---

Eek.  Yeah, NI thought that, by making the VIs xml they would make it easier for versioning software to handle, but instead it opened up a whole new can of worms where versioning software tries to "smart-merge" conflicting copies, and the only way to avoid this is to mark them as binary - which totally defeats the whole reason why they are xml files.

But like you said, this doesn't seem to be the problem, and NXG has been sunset  for a while.  I used to be fairly knowledgeable - at least on a higher level - but since NI discontinued NXG, I have as well.

[Kyle97330]

---

@billko wrote:

---

@IlluminatedG wrote:

Clearing cache, mass compiling, deleting VIs from disk that are mentioned in the LV logs... nothing gets it unstuck. I though maybe there was some corruption from a git merge so I've checked out back to work before the merge and no dice. LabVIEW just hates this project now.

---

Eek.  Yeah, NI thought that, by making the VIs xml they would make it easier for versioning software to handle, but instead it opened up a whole new can of worms where versioning software tries to "smart-merge" conflicting copies, and the only way to avoid this is to mark them as binary - which totally defeats the whole reason why they are xml files.

But like you said, this doesn't seem to be the problem, and NXG has been sunset  for a while.  I used to be fairly knowledgeable - at least on a higher level - but since NI discontinued NXG, I have as well.

---

Um, I'm pretty sure he's not using NXG.  He's using regular LabVIEW, which has had controls that look like NXG added to it for quite a while now (since 2018 or 2017?), and it's loading those that is messing up.  Nothing to do with NXG and its fancy XML save files.

As for a solution to the actual problem, I think <libdir> is just an indicator of the root folder containing the other .lib folders (instr.lib, vi.lib, user.lib).  So it's probably "C:\Program Files (x86)\National Instruments\LabVIEW 2021" or whatever, depending on your LabVIEW version and bitness.  Which do you have, by the way?

If you go to the vi.lib folder of your main LabVIEW install, could you completely remove the "NXG_controls" folder and see what happens when you load your project?  

Have you tried loading this project on multiple different PCs or just one?  Is there a chance it could be a problem with your particular install getting corrupted instead of a problem with the contents of the project?

[IlluminatedG]

billko, did you even look at the screenshot? This is regular LabVIEW loading the NXG style controls. Some remark about smacking comes to mind 😉

[billko]

---

@Kyle97330 wrote:

---

@billko wrote:

---

@IlluminatedG wrote:

Clearing cache, mass compiling, deleting VIs from disk that are mentioned in the LV logs... nothing gets it unstuck. I though maybe there was some corruption from a git merge so I've checked out back to work before the merge and no dice. LabVIEW just hates this project now.

---

Eek.  Yeah, NI thought that, by making the VIs xml they would make it easier for versioning software to handle, but instead it opened up a whole new can of worms where versioning software tries to "smart-merge" conflicting copies, and the only way to avoid this is to mark them as binary - which totally defeats the whole reason why they are xml files.

But like you said, this doesn't seem to be the problem, and NXG has been sunset  for a while.  I used to be fairly knowledgeable - at least on a higher level - but since NI discontinued NXG, I have as well.

---

Um, I'm pretty sure he's not using NXG.  He's using regular LabVIEW, which has had controls that look like NXG added to it for quite a while now (since 2018 or 2017?), and it's loading those that is messing up.  Nothing to do with NXG and its fancy XML save files.

As for a solution to the actual problem, I think <libdir> is just an indicator of the root folder containing the other .lib folders (instr.lib, vi.lib, user.lib).  So it's probably "C:\Program Files (x86)\National Instruments\LabVIEW 2021" or whatever, depending on your LabVIEW version and bitness.  Which do you have, by the way?

If you go to the vi.lib folder of your main LabVIEW install, could you completely remove the "NXG_controls" folder and see what happens when you load your project?  

Have you tried loading this project on multiple different PCs or just one?  Is there a chance it could be a problem with your particular install getting corrupted instead of a problem with the contents of the project?

---

LOL yeah, I took a closer look after your post and it seems the OP meant "NXG-style control".

[IlluminatedG]

My co-worker can load the latest version of the repo from git just fine.

I've done a repair of LabVIEW to no avail.

[Kyle97330]

---

@IlluminatedG wrote:

My co-worker can load the latest version of the repo from git just fine.

I've done a repair of LabVIEW to no avail.

---

What about a complete uninstall and then reinstall?  "Repair" doesn't catch everything.  Clearly the code isn't the problem since your co-worker's setup works.

[IlluminatedG]

Wish me luck

[IlluminatedG · Accepted solution]

The solution to this tale ended up being to make sure when you update some code a coworker previously wrote (when they worked at NI) that you don't put the new VI in a folder they had excluded in a VIPB. So VIPM had re-linked to the temporary package build location after it copied the project over but since the file wasn't actually included in the build it stayed linked to that VIPM build folder and apparently results in these horrendous symptoms and lv log dwarns about too many typeprop attempts. None of which was apparent until I retraced my steps of everything I had done because not even a full reinstall was working. Still not sure how they were able to open the dependent project though...

If I can (have time) reproduce this support will be getting a nice bug submission.