01-10-2023 01:25 PM
The attached project is saved in LV 2022 format and has:
1. Main.vi contains a Public VI from Lib 1.lvlib.
2. Said Public VI from Lib 1.lvlib takes the data type of a Community Enum Type Def. from Lib 2.lvlib as an input to the "Enum to Array of Enums.vim.
3. Lib 1.lvlib is a Friend of Lib 2.lvlib.
On a system with Windows 11 and LabVIEW 2022 Q3 - Main.vi has a good run arrow but building an EXE gives an error with this message.
On a system with Windows 10 and LabVIEW 2020 this works fine in both debug mode and building the EXE.
Solved! Go to Solution.
01-10-2023 03:31 PM
I am not able to get this to build on my Win 10 VM. It doesn't surprise me as the VIM isn't a friend of Lib 1 so probably breaks during app build. I am surprised it works on you win10 system and I guess would stop building once you clear compiled object cache.
Functionally, I wouldn't expect this to work at all. VIMs function like VIs with some trickery, but community scoping would break with any other subVI call that isn't a friend. I would say this is a bug around the development environment not breaking the caller due to how it generates VIM instances that get embedded in the caller.
01-11-2023 02:56 PM
I tried again in Win 10 and LV 2020 and first went to Tools -> Advanced -> Clear Compiled Object Cache and then closed LV and cleaned the cache with the attached batch file (I changed the file extension to be able to attach it). The EXE built fine in LV 2020. Could you try it with LV 2020 please? My guess is the OS doesn't matter. I've attached the project saved in LV 2020 format.
It doesn't surprise me as the VIM isn't a friend of Lib 1
I think you meant Lib 2 (which has the Community Enum Type Def.)
Functionally, I wouldn't expect this to work at all. VIMs function like VIs with some trickery, but community scoping would break with any other subVI call that isn't a friend.
In Win 11 and LV 2022, I tried making the the Enum to Array of Enums.vim a friend of Lib 2 but it still won't build the EXE. Note: when I open the Add friend file explorer dialog it doesn't list VIMs, I have to allow the listing of all files. But if I save a copy of the VIM, change the file extension to .vi, keep the inlining, and manually swap the controls/indicators on the new VI for the Community Enum Type Def., then add this new VI as a friend of Lib 2, the EXE builds.
I can understand why LV implantation wise this might not be allowed: behind the scenes, the VIM gets replaced with a VI whose controls and indicators have their data types based on the input data types the VIM was called with. If I were to literally do that, I would expect it to NOT compile (in both debug mode or the EXE). However, VIMs are required to be inlined. My understanding of inlining is that at compile time the content of the inlined VI is dropped on the block diagram of the calling VI. If that is done literally, then the VI *where the code ends up is a friend of Lib 2*. Ok, I can see why an API designer might want to control if inlined VIs shouldn't be allowed to do this though.
I should be able to just make the VIM a friend of Lib 2 then right?
01-11-2023 05:44 PM
Inlining is inconsequential to permissions of the code. Just because something is inlined (either because it needs to be or for performance considerations) shouldn't violate access scoping. That would violate the point of access scope and encapsulation if that was a "workaround".
That said, I would have expected setting the vim as a friend to resolve the issue but it didn't. I should have known better and tested that myself! There's definitely some regression after 2020 as I did my own SFP and it built regardless of the friend setting as you've stated. It seems VIMs get some special treatment because of their instancing mechanism on violating community scoping.
I'll submit a bug for this tomorrow and post the bug # once that's done./
01-12-2023 02:12 PM
The other weird part of this is that in debug mode there is no indication of a problem. Only when building the EXE, I get an error and the error isn't very descriptive of the actual problem.
01-23-2023 11:37 AM
Any progress on this and/or the bug number?
01-24-2023 01:22 PM
I found the following KB regarding the error 1502, did you try the workarounds explained in there?:
01-25-2023 06:38 PM
Unfortunately I ran out of time in my departure from NI to finish the bug submission. I'll see if I can rope a sympathetic TSE into submitting it. (Hence a new name since they now don't let you keep old accounts)
If you're feeling froggy, bugs can be submitted without active support entitlement.
01-25-2023 06:40 PM
Looks like someone forgot to log out of the download testing account before posting, who are you, secret SSPTest poster? 🙂
01-27-2023 11:16 AM
I'm Joan, from the NI TSR support team, and yep I forgot log out the SSP Test account before commenting 😅, sorry for that. I already reported the bug with R&D, the case number is 2282052 just in case.
Thanks for your support!.