LVOOP Application building work arounds

[Omar Mussa]

I preface this topic by the following statement: I think that the fact that LVOOP Classes are not automatically namespaced in built applications is a serious problem that should have been resolved by 8.5. When I open a class in the development environment, it is in the name space "Class:VI Name" so it seems unreasonable to me that this is not handled automatically in the LV Runtime Engine (or LV Builder, choose your poison -- I personally think it should be a LV Runtime Engine fix because otherwise you couldn't dynamically load classes into built applications -- & I'm not even sure if you can do that now). If this problem were solved, there would be no need for the workarounds I mention below.

I recently upgraded a project from 8.2.1 to 8.5 (why, because my customer wants to be on the bleeding edge -- really no other reason than that). In doing this, for whatever reason, I was no longer able to build an installer from my application. After looking at the warnings, I decided it was most likely due to namespace issues in my built EXE. I grew weary and tired of the warnings from App Builder about LabVIEW finding namespace issues and decided it was time to use the 'Destinations' and 'Source File Settings' pages and take control of my namespace once and for all.

Then an issue hit me. If you select a class on the 'Source File Settings' page, you cannot set the contents of the class to have a 'filename prefix' (i.e. namespace).

However, if you select a Virtual Folder, you can set a 'filename prefix' (it propagates to all items in the Virtual Folder).

So the following workaround found its way into my life. If you create a Virtual Folder (I called mine 'Class Members') and then shove all of your methods, controls, Virtual Folders, etc. into the folder, you can then use this virtual folder for setting your class contents into a namespaced destination.

This resolved all of my build conflicts (others arose but were not namespace related so far as I can tell). I plan on using this workaround on any new classes I make until LabVIEW properly sets the namespace automatically in the build process.

[Aristos Queue]

Reported to R&D as CAR# 101630.

QUOTE (Omar Mussa @ Apr 4 2008, 04:53 PM)

I preface this topic by the following statement: I think that the fact that LVOOP Classes are not automatically namespaced in built applications is a serious problem that should have been resolved by 8.5.

Probably would've been except that this is the first time I've ever heard it mentioned as an issue. :-) As it is, it is too late to make 8.5.1, and is probably too late to make the next LV release. But we'll see if it can squeeze in. No promises.

[Aristos Queue]

QUOTE (Aristos Queue @ Apr 5 2008, 09:31 AM)

This was reported to R&D (#101630) for further investigation.

This was closed as NOT A BUG. This is correct behavior that was implemented in LV8.5. Here's the feedback I got:

This behavior is expected behavior. In pre-LV 8.5, libraries were treated as containers in app builder when it came to setting properties. So you could set inclusion, destination, etc on all items under a library via the library itself. This led to confusion since the option was not clear whether you were setting the option on the file itself AND the children or what. So in 8.5, we changed the behavior (which was documented) such that operations on a library affect ONLY the library. So, the "workaround" the user listed is the appropriate thing to do. By creating virtual folders (which do apply their settings to their contained items), he gets what he wants, without ambiguity.

Let me just add this: Remember that if you prefix all the items in a class, you will be changing the name of dynamic dispatch VIs, so you must give the same prefix to the entire class hierarchy so that all the dynamic dispatch VIs continue to have the same name. If you only apply the prefix to the VIs of one class and not all the VIs of all the ancestors, your dynamic dispatch subVI calls will have different functionality than you expect.

[Omar Mussa]

QUOTE (Aristos Queue @ Apr 7 2008, 07:53 AM)

Let me just add this: Remember that if you prefix all the items in a class, you will be changing the name of dynamic dispatch VIs, so you must give the same prefix to the entire class hierarchy so that all the dynamic dispatch VIs continue to have the same name. If you only apply the prefix to the VIs of one class and not all the VIs of all the ancestors, your dynamic dispatch subVI calls will have different functionality than you expect.

Ouch I forgot about that :headbang: ...

and it explains why I was getting the mysterious and always ellusive error 1502 during the build (Can't save a bad VI without its diagram) -- this error message is the terrible because it does not specify the bad VI path/name or anything.

Maybe you can help me figure out the solution to my original problem. I want to distribute the application without having LabVIEW auto move/rename VIs/ctrls during the build (or at least I want to move all of the output from the auto movement to the 'data' directory instead of the target app root directory. How do I do this?

[gmart]

QUOTE (Omar Mussa @ Apr 7 2008, 12:07 PM)

Ouch I forgot about that :headbang: ...

and it explains why I was getting the mysterious and always ellusive error 1502 during the build (Can't save a bad VI without its diagram) -- this error message is the terrible because it does not specify the bad VI path/name or anything.

Maybe you can help me figure out the solution to my original problem. I want to distribute the application without having LabVIEW auto move/rename VIs/ctrls during the build (or at least I want to move all of the output from the auto movement to the 'data' directory instead of the target app root directory. How do I do this?

The error reporting was improved in LabVIEW 8.5.1 to return the name of the VI that had the problem.

To avoid the auto rename, what you should do is in the Source File Settings page, manually set the destination of files that appear in the warning message to the "data" directory. By doing this, the auto rename does not run on the files.

[Omar Mussa]

QUOTE (gmart @ Apr 7 2008, 11:00 AM)

The error reporting was improved in LabVIEW 8.5.1 to return the name of the VI that had the problem.

To avoid the auto rename, what you should do is in the Source File Settings page, manually set the destination of files that appear in the warning message to the "data" directory. By doing this, the auto rename does not run on the files.

I tried setting the destinations but then I get the following error:

"Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: A LabVIEW file from that path already exists in memory, or exists within a project library already in memory."

I think that this is because "the auto rename does not run on the files" :headbang: -- without auto renaming I'm stuck. What I need is autorenaming WITHIN the speficied destination. I guess this is a damned if you do, damned if you don't bug.

[gmart]

QUOTE (Omar Mussa @ Apr 7 2008, 01:35 PM)

I tried setting the destinations but then I get the following error:

"Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: A LabVIEW file from that path already exists in memory, or exists within a project library already in memory."

I think that this is because "the auto rename does not run on the files" :headbang: -- without auto renaming I'm stuck. What I need is autorenaming WITHIN the speficied destination. I guess this is a damned if you do, damned if you don't bug.

You'll need to have a separate destination for each class. You can't send them to the same location because then you'll run into what you have now. That is why if you notice, the autorename creates a separate directory for each collision per class. So essentially, you'll need to try to do the same thing.

[Omar Mussa]

QUOTE (gmart @ Apr 7 2008, 12:49 PM)

You'll need to have a separate destination for each class. You can't send them to the same location because then you'll run into what you have now. That is why if you notice, the autorename creates a separate directory for each collision per class. So essentially, you'll need to try to do the same thing.

Ok, sorry for turning this thread into an NI support page -- not my original intention. I just want to vouch for the fact that this has worked and helped my build a working EXE... The one problem I have now is that when I try to build an Installer now, the installer seems to look for the files without regard for destination or name changes. I'm pretty close to waving the white flag and just leaving everything with default settings even though I finally have my EXE build output looking the way I want.

[gmart]

QUOTE (Omar Mussa @ Apr 8 2008, 12:56 AM)

Ok, sorry for turning this thread into an NI support page -- not my original intention. I just want to vouch for the fact that this has worked and helped my build a working EXE... The one problem I have now is that when I try to build an Installer now, the installer seems to look for the files without regard for destination or name changes. I'm pretty close to waving the white flag and just leaving everything with default settings even though I finally have my EXE build output looking the way I want.

There was an issue with the Installer builder in LabVIEW 8.5 where some files were not being placed in the correct location. This issue was corrected in 8.5.1. Would you be more specific regarding your problem? What do you mean that it looks for the files "without regard for destination or name change"?

[Omar Mussa]

QUOTE (gmart @ Apr 8 2008, 08:28 AM)

Would you be more specific regarding your problem? What do you mean that it looks for the files "without regard for destination or name change"?

When I drag my executable over to the Installer destinations tab, I see a preview of the installer output. The folders/names of the files in this preview do not match my built output.

My built output looks like this:

Application.exe

Application\Support\Alarm

Application\Support\Measurement

etc.

(Support is my application 'data' folder, but I've renamed it).

My Installer wants to create the following:

Application.exe

Application\Alarm

Application\Measurement

...

Application\Support\Alarm

Application\Support\Measurement

Which does not look correct as my build output does not create any folders at those bold locations. When I try to build, I get the following error:

"The following file(s) are not found on the system:

... (filelist of a lot of controls -- interestingly no VIs show up in the list)

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

CDK_CreateNewWizard_Invoke.vi.ProxyCaller >> CDK_CreateNewWizard_Invoke.vi >> CDK_InstallerConfiguration_Editor.vi >> CDK_Build_Invoke.vi >> CDK_Engine_Main.vi >> CDK_Engine_PreBuild.vi >> CDK_Engine_FileExists.vi

"

I thought at first the problem could be due to LabVIEW stripping out unused code so I moved the root virtual folder of my classes into the 'Always Included' area of the EXE build specification and I also unchecked the 'disconnect type defs' & 'remove unused project members' options. I'm not sure if LabVIEW is building the missing files into my EXE or what, but the EXE is working (I can run it at the built location) so I have no idea why the installer builder is generating that error.

It seems like there might be another root cause to this problem. LabVIEW does not appear to be differntiating naming rules for dynamic dispatch between controls and VIs. If I have two classes that inherit from each other and they both have a control named 'Properties.ctl' there should not be any dynamic dispatch related naming issues because 1) both are members of a library 2) there is no such thing as over-riding a control (only VIs can be over-ridden). Let me know if there is anything else I can do -- I really don't want to upgrade to 8.5.1 yet because I have other projects on 8.5 that can't be upgraded yet.

[gmart]

I would be tempted to try your code with 8.5.1 because what you describe sounds similar to the problem that was fixed. I think we're at a point where having sample code that reproduces the problem would facilitate debugging the issue. If it is possible to narrow down the problem to a subset of your code, that would be helpful. You don't have to have code if you can come up with steps that reproduce the issue. You could also post your code if that would be possible.

Regarding 8.5.1, it is compatible with 8.5 such that you don't need to mass compile your files. I don't have any other good suggestions currently.

[Aristos Queue]

QUOTE (gmart @ Apr 8 2008, 02:57 PM)

Regarding 8.5.1, it is compatible with 8.5 such that you don't need to mass compile your files.

Bzzzt. Almost true, but at the end you turned it into a lie.

8.5.1 will load any VI saved in 8.5.

8.5 will load any VI saved in 8.5.1.

So it is completely correct to say that the two versions are compatible.

HOWEVER, this does not mean you don't need to mass compile your files. Please read http://forums.lavag.org/LabVIEW-851-Released-t10528.html&view=findpost&p=43814' target="_blank">this post from LabVIEW's product support engineer.

[crelf]

QUOTE (Aristos Queue @ Apr 8 2008, 05:13 PM)

HOWEVER, this does not mean you don't need to mass compile your files. Please read this post from LabVIEW's product support engineer.

There's only one?

[gmart]

QUOTE (Aristos Queue @ Apr 8 2008, 03:13 PM)

Bzzzt. Almost true, but at the end you turned it into a lie.

8.5.1 will load any VI saved in 8.5.

8.5 will load any VI saved in 8.5.1.

So it is completely correct to say that the two versions are compatible.

HOWEVER, this does not mean you don't need to mass compile your files. Please read http://forums.lavag.org/-t10528.html&view=findpost&p=43814' target="_blank">this post from LabVIEW's product support engineer.

I turned off "immediate disclaimer" mode when I was responding. Thanks for backing me up.

[Aristos Queue]

QUOTE (gmart @ Apr 8 2008, 05:28 PM)

I turned off "immediate disclaimer" mode when I was responding. Thanks for backing me up.

Sorry... I got burned by this one recently -- took a full day to find a bug that was already fixed in 8.5.1 if only I had recompiled -- so I'm kinda pedantic about mentioning this.

[iandev]

Sirs,

im trying to build and application based on OO and found some additional problems about namespaces.

The suggestion to use virtual folders solved almost all my problems, but one remained.

I'd would ask you to take a look at the following image to get a better understanding of my problem.

As you'll see, since both classes: Sincronizador (baseclass) and SincronizadorFTP(subclass) are on the same hierarchy I added the same prefix to them to keep dinamyc dispatching working well. But this as would be expected brought me back to the collision problem between equal method names in those classes.

Any suggestion on how to workaround this problem?

Note: It could be suggested to get rid of "abstract methods" on baseclass but this would be undesireable in terms of my conceptual code organization.

[Aristos Queue]

QUOTE (iandev @ Jun 16 2008, 03:04 PM)

But this as would be expected brought me back to the collision problem between equal method names in those classes.

Any suggestion on how to workaround this problem?

What is the "original problem of collision between equal method names in those classes"? Is AppBuilder throwing an error because those VIs have the same file name? That shouldn't be happening. What should be happening is that those VIs are saved next to the EXE, each in their own subdirectory, where the EXE can access them.

That's the expected behavior of LV8.2 and 8.5. It is not considered a bug, although it is considered to be behavior we want to change in the future, but at the moment two VIs of the same name cannot save inside the EXE because historically it wasn't a scenario we had to worry about and the old code requires more refactoring than we anticipated. It's being worked on for a future LV release. But you should be just fine building apps today.