Lots of problems building a large executable with LVOOP classes

[THANG NGUYEN]

I have this warning message when trying build the executable file under LabVIEW 8.5. This is the issue with name:

LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts.

The following files were moved to a unique location:

D:\Project Name\Project Classes\Store Manager\Set Path.vi
D:\Project Name\Project Classes\Channel Config Manager\Set Path.vi
D:\Project Name\Project Classes\Store Manager\Get Path.vi
D:\Project Name\Project Classes\Channel Config Manager\Get Path.vi

.......

LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts.

The following files were moved to a unique location:

D:\Project Name\Project Classes\Store Manager\Set Path.vi
D:\Project Name\Project Classes\Channel Config Manager\Set Path.vi
D:\Project Name\Project Classes\Store Manager\Get Path.vi
D:\Project Name\Project Classes\Channel Config Manager\Get Path.vi

These are the VIs with the same name but belong to different classes. Although LabVIEW solve this problem but I want to know if I should assign different names?

This is the warning message only. I can finally build the executable file.

Thang Nguyen

[gmart]

The message is only a warning not an error. The warning is informing you that because of the current mechanism used when building applications, there was a name collision and one or more of the VIs whos name collided will be placed outside of the app. There should be no need to rename your code since doing that would break you class override behavior (if you have that functionality).

[billings11]

Is this really how the builder is supposed to behave?  Is it really going to give me a warning for every single name conflict between every single class?  If it is copying and renaming these files, where is it copying them and what is it renaming them to?  And I notice every method vi in a class cannot be built into the executable.  They have to go along with the executable as support files.  Is that the plan going forward?  Why is it like this?  In labview 8.5 do we still have the bug where we can't choose the "Remove as much as possible" option in the build?

Also, why if I look at the class ownership of a vi does it just open the class?  What if the vi got moved out of the correct relative directory to the class?  Can I see the relative path to the class or does labview assume the class must always be in the same directory as the method?

You say all known bugs have been fixed, but if every single namespace violation shows up as a warning in the build it seems like its not fixed.

[gmart]

The current behavior is the way it is as of LabVIEW 8.5 We are aware this is not ideal and are working on how to make this better. The need to save classes outside of the EXE has been called a bug by the developer of LV classes so I think there is a good chance the behavior will be improved in the future.

Yes, you will be a warning for every name collision. There shouldnt' be renaming of the class VIs. They should all go into separate directories and have the same name.

You should be able to use the "Remove as much possible" option (which is now multiple checkboxes - select all of them for the same behavior).

[THANG NGUYEN]

Thank you,

I knew that this is only a warning message. In my understanding, instead of copying all of VIs into one big folder, LabVIEW seperated them into different folders to avoid the name collision. LabVIEW 8.5 is a fixed version for the issue building executable with LabOOP only. I can build my EXE file already.

I think we can wait for another version come out soon.

Thang Nguyen

[gmart]

Well, I wouldn't say that LabVIEW 8.5 is only a fix for building executables that use LVOOP. There's much more. As mentioned before, many issues with building executables with classes have been fixed. There are also other enhancements and features. Take a look at the upgrade notes for more info on this. I'm glad to hear your building experience works for you now.

[labJunky]

Hello everyone,

I am using labview 8.5 and am trying to build an .exe using LVOOP classes with the application builder.

After following the advice in the previous posts, like not including any of my lvclasses in the supporting files, and with the debugging checked... I click generate preview, and not surprisingly get a warning about all of my classes for name conflicts.  Then I click ok, and build. 

This results in the following error:

"Error copying files.

Source: ...BEC Suite\Tools\xmlNode\getXMLNode.vi

Destination: ...Internal.llb\getXMLNode.vi

Invoke Node in AB_Source_VI.lvclass:

Copy_SourceItem.vi -> AB_Build.lvclass:

Copy_Files.vi -> AB_Application.lvclass:

Copy_Files.vi -> AB_Build.lvclass ->

AB_EXE.lvclass:Build.vi ->

AB_Engine_Build.vi ->

AB_Build_Invoke.vi ->

AB_Build_Invoke.vi.ProxyCaller

<APPEND>

Method Name: <b>Set Path</b>

Details:

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 ->

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." 

Anyone know what is wrong and how to fix it?

Thanks,

Paul. 

[yenknip]

Are the problem VIs inherited or in different classes with the same name? From the error log it looks like that is the case.

To solve this issue, you will need to compile each classe into their own llb directories.  Check the options in the source files and destinations tabs in the exe builder. In destinations set the class destination type as an llb.

[labJunky]

Hi thanks for your reply!

this particular vi is not inherited or has a duplicately named vi / class anywhere in the project. However, I am having the same build problem with some other vi's which are inherited. So I will do as you suggest and get back to you if it doesn't work.

Thanks again,

Paul. 

[labJunky]

hi Ed,

your solution works great (though is slightly tedious, if there are many of these errors coming up for different vi's), max Kudos to you!!

Thanks again.

Paul.