Name conflicts using VIs for override

[Eugen Graf]

Hello LAVAs!

What is the best solution for the following problem? If I use VIs for overriding, so they have to have the same name. But if I create a executable I get name conflicts, because two VIs with the same name can't be saved in one (exe) folder.

Next question is: if I want to have VIs with the same name in two different classes I have the same problem (name conflicts), so I have always to use prefix in the members. Is there an another better solution as to use prefixes?

Thank you, Eugen

[Mark Smith]

QUOTE (Eugen Graf @ Jan 21 2009, 03:51 AM)

Hello LAVAs!

What is the best solution for the following problem? If I use VIs for overriding, so they have to have the same name. But if I create a executable I get name conflicts, because two VIs with the same name can't be saved in one (exe) folder.

Next question is: if I want to have VIs with the same name in two different classes I have the same problem (name conflicts), so I have always to use prefix in the members. Is there an another better solution as to use prefixes?

Thank you, Eugen

LabVIEW has some real underlying issues with the namespaces (classes, lvlib) and building into an exe - just try building an app using a lot of the new plug and play instrument drivers that use the same VI names for things like Configure, Read, etc and differ only by location on disk (they all reside in different folders) and owning library. You'll get a built app that may have half a dozen folders deployed so that each VI can still have a unique name. It looks pretty ugly, but I'll give NI credit - it does work. Still, this doesn't look like a good long-term solution since a LVOOP app will be even worse - if you have a lot of override VIs in a large app, I can see where you could get hundreds of folders in a deployed app. So, it appears we have a LabVIEW dev environment that uses namespaces but a compiler/linker that really does not - as you pointed out, each VI name must be a unique path. You can achieve that by prepending something to the name, or you can just save your child classes in unique directories - then the complete path to the overridden VI is still unique. The app builder will maintain this unique path (even though it will report a name collision) but it will create as many deployment directories as you created for the child classes.

Does anyone have any insight as to what the long term vision is for this issue? I'm curious.

Mark

[Eugen Graf]

Thank you Mark.

I known about this method of building executable.

Disadvantages:

1 many folders in the folder, where the executable is

2 warnings during building (I don't like this)

3 can't really good call dynamicaly some VIs, have always to check if it's a standalone or IDE execution

May be there are some more suggestions?

[Aristos Queue]

*grumble grrr*

LabVIEW's expected behavior is "if we detect two VIs of the same name in different classes then just assume that those go in a folder next to the EXE, with subfolders for each class." You shouldn't have to specify any paths to save the VIs to special locations -- including the class in the build should be sufficient and LV should handle the saving to a folder beside the EXE. And you will get the build warning that the VIs were put next to the EXE instead of inside the EXE.

Disadvantages 1 and 2 are thus expected behaviors and there's nothing you can do about it.

As for disadvantage #3 QUOTE

3 can't really good call dynamicaly some VIs, have always to check if it's a standalone or IDE execution

Try to name the VIs that you want to dynamically load by a unique name so they get packaged inside the EXE. That's all the help I can offer.

Now, having said that, I am sick and tired of this behavior, and I will seriously contemplate doing everything I can to hold the LV CD from being shipped to customers if the next version of LabVIEW doesn't allow multiple VIs of the same name to be stored in the EXE. The feature/bug fix (depending upon your point of view) is finally getting attention. I still can't promise it will be fixed because unforseen difficulties can put the kabosh on any new development, but I'm putting all the pressure I can to get this fixed.

[Eugen Graf]

QUOTE

Now, having said that, I am sick and tired of this behavior, and I will seriously contemplate doing everything I can to hold the LabVIEW CD from being shipped to customers if the next version of LabVIEW doesn't allow multiple VIs of the same name to be stored in the EXE. The feature/bug fix (depending upon your point of view) is finally getting attention. I still can't promise it will be fixed because unforseen difficulties can put the kabosh on any new development, but I'm putting all the pressure I can to get this fixed.

Thank you, I will wait for the next LabVIEW version :thumbup:

[Abdullah R]

I have base class with two child classes following the factory pattern and use of "Get LV Class Default Value.vi" for dynamic loading. For my built app, i include two base classes into EXE (under "Source Files:Always Included" section). What i am seeing is that after the app is built, i see two folders next to exe with only dynamic VIs in them but no .lvclass which is what i need to load the class by its path name.

Where is child1.lvclass and child2.lvclass are? in exe? I need path so i load it in exe.

[Aristos Queue]

QUOTE (paracha3 @ Jan 21 2009, 01:33 PM)

I have base class with two child classes following the factory pattern and use of "Get LV Class Default Value.vi" for dynamic loading. For my built app, i include two base classes into EXE (under "Source Files:Always Included" section). What i am seeing is that after the app is built, i see two folders next to exe with only dynamic VIs in them but no .lvclass which is what i need to load the class by its path name.

Where is child1.lvclass and child2.lvclass are? in exe? I need path so i load it in exe.

The .lvclass file is inside the .exe, along with all the other VIs. You should be able to do dynamic loading of it by taking the current path from your top level VI and appending "..\classname.lvlcass" onto it, just as you can for creating the path to any VI inside the .exe.

[Abdullah R]

Ok i tried that, but it seems like the .lvclass files are not in the EXE. I have tried the same thing on Factory Pattern example to make sure there is nothing wrong in my code and it is same behavior.

See attachment.

FYI. i am using LV8.5

[Matias Ribeiro]

HII I am student, beginer in the LabView, I need know how use the accessory BNC-2110

if some member this forum have some tutorial or step by step for beginers, please post links in this forum or send me email with some files for help me

thanks

[Aristos Queue]

Did you tell the project to put the class files inside the EXE? The only ones that are inside the EXE are those that are used by the Source files. If you want other files to be included in the EXE, add them to the bottom section where it says "Always Included".

[Abdullah R]

QUOTE (Aristos Queue @ Jan 21 2009, 03:55 PM)

Did you tell the project to put the class files inside the EXE? The only ones that are inside the EXE are those that are used by the Source files. If you want other files to be included in the EXE, add them to the bottom section where it says "Always Included".

Yes if you look into the attached project, you will see that it does say that destination of lvclass is in "Application.exe"

[Aristos Queue]

Here's a simple example that works.

Download File:post-5877-1232598869.zip

[Abdullah R]

QUOTE (Aristos Queue @ Jan 21 2009, 09:34 PM)

Here's a simple example that works.

http://lavag.org/old_files/post-5877-1232598869.zip'>Download File:post-5877-1232598869.zip

Thank you for your help. Would you be kind enough to send me code in LV 8.5? My company does not upgrade immediately

LabVIEW 8.5 code Please :headbang:

waiting for a breakthrough.

[Eugen Graf]

QUOTE (paracha3 @ Jan 22 2009, 05:57 AM)

Thank you for your help. Would you be kind enough to send me code in LV 8.5? My company does not upgrade immediately

LabVIEW 8.5 code Please :headbang:

waiting for a breakthrough.

Here you have

[Abdullah R]

QUOTE (Eugen Graf @ Jan 22 2009, 03:32 AM)

Here you have

Thanks Eugen, but your code does not work, the problem is actually masked and hence you dont see any error messages. I have added little debugging indicators and i see the same error as i get with my code. See attached updated zip file.

I dont understand how it is working on your side?

[Eugen Graf]

QUOTE (paracha3 @ Jan 22 2009, 06:00 PM)

Thanks Eugen, but your code does not work

It's not my code I only converted it for 8.5

[Abdullah R]

@Aristos Queue

Any ideas?

[Aristos Queue]

I just tried Eugene's 8.5 .zip file -- it works just fine in 8.5.

Eugene added a bit of extra code to it to make it more interesting... here's the 8.5 version stripped back to just my original example.

Download File:post-5877-1232650822.zip

[Abdullah R]

QUOTE (Aristos Queue @ Jan 22 2009, 12:00 PM)

I just tried Eugene's 8.5 .zip file -- it works just fine in 8.5.

Eugene added a bit of extra code to it to make it more interesting... here's the 8.5 version stripped back to just my original example.

http://lavag.org/old_files/post-5877-1232650822.zip'>Download File:post-5877-1232650822.zip

@AQ, i tried your zip file just now, no changes made. When i run the VI, yes it works and i do see "Kid". Then i build executable, it says Parent when run. See attached screenshot of exe.

[Aristos Queue]

QUOTE (paracha3 @ Jan 22 2009, 01:08 PM)

@AQ, i tried your zip file just now, no changes made. When i run the VI, yes it works and i do see "Kid". Then i build executable, it says Parent when run. See attached screenshot of exe.

Hm... I'm running 8.5.1. Are you perhaps running 8.5.0? I don't know of anything that got fixed in that bug fix release that would affect this, but maybe there was something. Other than that, I have no idea what could be wrong.

[Eugen Graf]

QUOTE (Aristos Queue @ Jan 22 2009, 08:00 PM)

Eugene added a bit of extra code to it to make it more interesting... here's the 8.5 version stripped back to just my original example.

No, I didn't

But I made a exe and it works on my PC. I use LV 8.6

[Aristos Queue]

QUOTE (Eugen Graf @ Jan 22 2009, 01:18 PM)

No, I didn't

Then where did the file path subVI come from? I've never used that subVI before to the best of my knowledge. Maybe it was introduced by the save-for-previous process to maintain some sort of binary compatibility?

[Eugen Graf]

QUOTE (Aristos Queue @ Jan 22 2009, 08:34 PM)

Then where did the file path subVI come from? I've never used that subVI before to the best of my knowledge. Maybe it was introduced by the save-for-previous process to maintain some sort of binary compatibility?

Which one do you mean? Can you make a screenshot please.

[Abdullah R]

QUOTE (Aristos Queue @ Jan 22 2009, 12:17 PM)

Hm... I'm running 8.5.1. Are you perhaps running 8.5.0? I don't know of anything that got fixed in that bug fix release that would affect this, but maybe there was something. Other than that, I have no idea what could be wrong.

NOOOOOOOOOOOOOO :headbang:

Such nice design of my software is now in jeopardy because of this issue!!! Yes i am running 8.5.0. Is 8.5.1 free upgrade or paid?

Where is what i see in 8.5.1 bug fixes that looks close.

QUOTE

4CML9UJ1: Get

LV

Class Default Value.vi cannot access LabVIEW class inside an LLB

and labview exe is essentially an LLB. Any workarounds?

Ohh God!

[TobyD]

Totally off topic...but I think I remember Stephen saying once that if his activity on LAVA suddenly increased it was usually a good indicator that all of his work for the next release of LabVIEW was complete and he had a bit of time before work on the next release had to begin. As I read through this thread I was noticing that you've been posting a lot today Stephen. :ninja: