Application Builder Problems for LvClass

[MikaelH]

Hi

I have problems creating an executable file, for my OO-based application:When NOT adding the debugger I get this problem, for this VI:

When adding the debugger, I can get the exe-file to be created.BUT I get these dialogs:

The Exe-file has been created and I can run it (but it doesn't work properly).

If I try to connect the debugger. It searched for ObjectReference{1,2,3,4,5...}.vi files but can't find these.

The "Find the control named"-dialog appears, and it asks me to find "Storage.lvclass:ObjectReference4.vi",

I guess this is one of the things it has renamed, the original name were Storage.lvclass:ObjectReference.ctl.

It's a Enum inside a datalog refnum TYPE, not a VI. All my classes has this reference and it looks for all of them.

One "...:ObjectReference.ctl" has not been renamed, but it still can't find it.Then LabVIEW just crashes.

Ideas?

//Mikael

[crelf]

Is there anything under the "details" section on this one? Are you able to post real code and your build spec (the whole project would be even better)?

[MikaelH]

Is there anything under the "details" section on this one? Are you able to post real code and your build spec (the whole project would be even better)?

I can't post the code right now, I'm using Endevos new reference based OO architecture,

and we haven't decied if it will be open source code or not.

And the OO kernels isn't locked yet

I found a problem.

When building the exe-file, LV renamed a sub class method, that I call dynamic.

Why?

Probably because I have the same method-name in another sub class.

Both these classes derive from a common base class.

But the base class don't have this method in it.

If I create this method in the base class It might work since it then forces it to have the same

name, since it could be used by dynamic dispatch.

//Mikael

Is there anything under the "details" section on this one? Are you able to post real code and your build spec (the whole project would be even better)?

YES, I got very usful information under Details:

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

:headbang:

//Mikael

[crelf]

I can't post the code right now, I'm using Endevos new reference based OO architecture, and we haven't decied if it will be open source code or not. And the OO kernels isn't locked yet

All the more reasons to upload it!

[LAVA 1.0 Content]

I can't post the code right now, I'm using Endevos new reference based OO architecture,

and we haven't decied if it will be open source code or not.

Do you have any good reasons to make it closed soruce? I doubt you would get huge income from a closed source packagee. I also doubt that the the net revenue will be worth the effort of supporting the product and consuming your most important asset, namely your software developer's time. But with open source package you can get a lot of goodwill and you do not have to provide support.

[Aristos Queue]

MikaelH, I already put this info in e-mail to you, but I didn't know it was also here on LAVA.

For the rest -- this is a behavior common to all libraries, not specific to LV classes. The AppBuilder was built in a time when all VIs were expected to have a unique file name. So when it bundles libraries into the EXE, it has to rename any VIs that collide.

For LVClasses, we put in a hack that saves the dynamic VIs outside of the EXE, since those VIs *must* have matching names. But for static VIs, they follow the same behavior as other VIs in any library.

A workaround that might work is to make your static VIs dynamic, even though you're not expecting to override them. I don't remember if the hack for dynamic VIs is invoked simply by a VI being dynamic or if that gets invoked only when the VI is overridden.

This behavior is going to require significant changes to AppBuilder to fix, and it is an area outside of my purview. It gets annoying since it impacts the Factory pattern for LVClasses, which calls for an identically named static VI on a series of classes.

If you do find a good workaround, please post it here.

[LAVA 1.0 Content]

For the rest -- this is a behavior common to all libraries, not specific to LV classes. The AppBuilder was built in a time when all VIs were expected to have a unique file name. So when it bundles libraries into the EXE, it has to rename any VIs that collide.

You got to be joking! :headbang: This means our projects will very probaly face the same issue when it's time to build them. We've been developing with the expectance that long names (LibA.lvlib:ClassA.lvclass:anything) really stay long after the builf process also. Can't this feature be fixed in the builder to use the long names instead of renaming stuff errorneously?

[kennoncotton]

You got to be joking! :headbang: This means our projects will very probaly face the same issue when it's time to build them. We've been developing with the expectance that long names (LibA.lvlib:ClassA.lvclass:anything) really stay long after the builf process also. Can't this feature be fixed in the builder to use the long names instead of renaming stuff errorneously?

The limitation is not the long, qualified in memory names, they will stay "long" after the build process, the problem is the filename on disk. On disk LibA.lvlib:ClassA.lvclass:anything.vi is c:\somewhere\anything.vi, if you have 2 Project Libraries that have anything.vi in them, then they must be in separate folders because the OS won't allow them 2 files of the same name to be saved in the same location on disk. Or they have to be in separate LLBs because a LLB is a essentially a single directory. So your project has 2 VIs of the same filename in memory because they are different qualified names and life is great in the development environment. When we build an app we essentially create a single LLB of all the VIs and stick it into the EXE, unless you create multiple destinations and specify parts of your source to go to those different destinations. So those 2 files of the same name are going to be stuck into the same LLB, which means either we fail because you are putting 2 files of the same name in the same directory or we let the last one copied into the LLB 'win' or we rename the duplicates and update all static linkages. We chose to rename any duplicates going to a destination and update the static linkages and since we don't know about the dynamic linkages we give a warning about them being renamed. The thought was more of the links are probably static and would be updated so the EXE would work without any further problem.

If you are calling VIs dynamically I recommend you create additional destinations and put each Project Library in its own destination, this does require you add logic for where the VIs will be found when in an exe, but it allows the file names to stay the same. One other caveat about when we do a rename is with LabVIEW Classes and dynamically dispatched VIs, as mentioned those must have matching names so when App Builder finds one it will not put it in the EXE by default but rather create a separate folder for it and put it outside so that its filename can stay the same.

This is the way it is going to have to be until we either stop using LLBs as the internal storage mechanism for EXEs or make LLBs support multiple files of the same name being stored inside of them (seems like that would be confusing). I know that doesn't solve the rename problem, I'm honestly not sure when or if we will do that, but hopefully understanding what is going on will help you be able to handle it better.

Kennon

[crelf]

...stop using LLBs...

:thumbup: Great idea!

[Aristos Queue]

You got to be joking! :headbang:

You should've heard the headbanging when I first heard about this behavior.

The workaround to "establish custom destinations for all the VIs to sit next to the EXE instead of just the dynamic dispatch VIs" should work. But this has to be addressed sooner than later.

[LAVA 1.0 Content]

You should've heard the headbanging when I first heard about this behavior.

I can still hear the echo... Why not to use similar packaging method that is used for Java application and libraries i.e. the library is packaged as a zip package which includes some sort of directory structure.

[crelf]

...the library is packaged as a zip package which includes some sort of directory structure.

Like the OpenG package files - that'd be pretty cool. I know that I've had to significantly change a number of my architectures to deal with the application instance changes (which I love, by the way ) and I know that it means a lot(?) of work is needed to be done to the app builder, but it's got to be done somehow. All that aside, I really don't mind how the new architecture of an exe is set up - I'd like to be able to help with ideas (who knows the strengths and weaknesses of building apps better than us LAVAer's?), but ultimately, as long as my apps run and it's an intuative architecture, then it's really up to NI...

[MikaelH]

I have problems creating an executable file, for my OO-based application:When NOT adding the debugger I get this problem, for this VI:

Okay, so when using classes in the application it puts all dynamic class VIs under the data folder like this:

So it will not be just an simple exe-file to distribute any more

//Mikael

[LAVA 1.0 Content]

So it will not be just an simple exe-file to distribute any more

I prefer using an installer rather than an exe as the distributable for an application

[crelf]

I prefer using an installer rather than an exe as the distributable for an application

...but an exe and an installer have two very different purposes :question:

[Jim Kring]

...but an exe and an installer have two very different purposes :question:

And sometimes an installer is an exe.

[LAVA 1.0 Content]

Okay, so when using classes in the application it puts all dynamic class VIs under the data folder like this:

Is the source code of these dynamic VIs protected or locked automatically or do I have to lock the block diagram manually? I could try this out but I'm lazy. This is btw something I've never thought of, are the VI block diagrams accessible from an executable?

[Aristos Queue]

Is the source code of these dynamic VIs protected or locked automatically or do I have to lock the block diagram manually? I could try this out but I'm lazy. This is btw something I've never thought of, are the VI block diagrams accessible from an executable?

The VIs are saved without block diagrams when you build an EXE or library unless you explicitly tell AppBuilder to retain them. Even then the diagrams cannot be loaded by the app builder -- without the editor present, there's no ability to load the diagrams. Front panels can be stripped as well.

[Jim Kring]

Is the source code of these dynamic VIs protected or locked automatically or do I have to lock the block diagram manually? I could try this out but I'm lazy. This is btw something I've never thought of, are the VI block diagrams accessible from an executable?

As Stephen mentioned, the diagrams are removed (by default), but I believe that the VIs (that are saved outside of the EXE) can be used as subVIs of other LabVIEW applications (within the same version of LabVIEW ) . This means that it is possible for the end customer of your application, to re-use the VIs in other applications and even build them into other EXEs.

[LAVA 1.0 Content]

As Stephen mentioned, the diagrams are removed (by default), but I believe that the VIs (that are saved outside of the EXE) can be used as subVIs of other LabVIEW applications (within the same version of LabVIEW ) . This means that it is possible for the end customer of your application, to re-use the VIs in other applications and even build them into other EXEs.

Hmm... this really isn't what I'd like to see happening when I'm distributing an application. Would there be any workaround that would hide everything?

[Jim Kring]

Hmm... this really isn't what I'd like to see happening when I'm distributing an application. Would there be any workaround that would hide everything?

The only thing that I can think of, would be to make all of the VIs that are saved outside of the EXE part of a password protected project library (.lvlib) or class (.lvclass) and make sure that all of the .lvlib and .lvclass files get saved inside the EXE. I think that this might prevent the VIs from being called without the .lvlib or .lvclass files, which cannot be extracted from the EXE... but this is just a guess.

[Mike Ashe]

Hmm... this really isn't what I'd like to see happening when I'm distributing an application. Would there be any workaround that would hide everything?

Yep. It is a bit of extra work, but there are at least a couple of different ways to prevent reuse. (This doesn't hide, just make unusable)

1. Create a subVI that does nothing, but is stored in your *.exe from the build. Put that VI on the diagram of every dynamically loaded VI that is saved externally. That way the VI will break and be unusable if it is not loaded by your *.exe

2. Variation on above: have each of your dynamic VIs look to see who called them and if it is not your *.exe, ie and authorized app, then either don't work (recommended) or send back incorrect data or behavior. (not recommended due to debug and liability issues).

[LAVA 1.0 Content]

Yep. It is a bit of extra work, but there are at least a couple of different ways to prevent reuse. (This doesn't hide, just make unusable)

1. Create a subVI that does nothing, but is stored in your *.exe from the build. Put that VI on the diagram of every dynamically loaded VI that is saved externally. That way the VI will break and be unusable if it is not loaded by your *.exe

2. Variation on above: have each of your dynamic VIs look to see who called them and if it is not your *.exe, ie and authorized app, then either don't work (recommended) or send back incorrect data or behavior. (not recommended due to debug and liability issues).

First option might be applicable, especially if the subVI would be put inside disable structure so that it doesn't affect runtime performance. Second alternative is not an option due to many reasons.

[Jim Kring]

Yep. It is a bit of extra work, but there are at least a couple of different ways to prevent reuse. (This doesn't hide, just make unusable)

1. Create a subVI that does nothing, but is stored in your *.exe from the build. Put that VI on the diagram of every dynamically loaded VI that is saved externally. That way the VI will break and be unusable if it is not loaded by your *.exe

2. Variation on above: have each of your dynamic VIs look to see who called them and if it is not your *.exe, ie and authorized app, then either don't work (recommended) or send back incorrect data or behavior. (not recommended due to debug and liability issues).

Option 1 can be defeated by providing a VI with the same name and connector pane.

Option 2 is possible, but requires a bit of thought+work and incurs performance penalties.

[Aristos Queue]

First option might be applicable, especially if the subVI would be put inside disable structure so that it doesn't affect runtime performance. Second alternative is not an option due to many reasons.

A code disable structure would not achieve the effect -- if it isn't compiled into the code then when the subVI is missing the VI isn't broken. You could put the subVI into a case structure that is wired with a control (not a constant!) whose value is FALSE. Then it would be compiled in but never executed.

But as Kring points out, all they'd have to do is load a VI to fill in the missing subVI.

I'm not sure why this is a problem... in previous versions of LV, you could load the VIs even if they were inside the EXE using various magic tricks. It's only recently that you couldn't -- and more people have complained about not being able to access the VIs inside the EXE than have complained about not being able to access them.

Now, there is a game that I can play on the C side of the code that I've used a couple of times for hiding VIs... I have the equivalent of a string control whose value is the save image of the VI and then I load the VI from the string instead of loading from disk. Thus there is no VI anywhere on disk that is the VI that I'm loading. I have no idea if any such mechanism exists on the G side of the code. Has anyone ever done something like this? And, now that I think about it, Express VIs generate VIs that are saved inside the caller VI. I wonder if there'd be a way to hide other VIs in there with a custom built Express VI? I've never used the Block Builder Toolkit, so I don't know if this is doable or not.

All of these suggestions are a bit of a longshot, and probably not easy even if they would work. Sorry, Jimi, but with AppBuilder I'm pretty much in the dark. It isn't an area of LV that I've paid attention to much, though it appears that with LVClasses I'm going to have to go learn about it more than I had expected. :ninja:

2. Variation on above: have each of your dynamic VIs look to see who called them and if it is not your *.exe, ie and authorized app, then either don't work (recommended) or send back incorrect data or behavior. (not recommended due to debug and liability issues).

What if you just created an LVLibrary that owned your entire application and made all the VIs private to the LVLibrary? Then even if others managed to load them they couldn't run/call them.