LabView 2010 Application Builder for EXE Always Included files are not Included

[Dennis_Knutson]

You are completely missing the point. I don't give a rat's behind to see your clin\ents code I and am not asking you to provide it. You are the one that says there is a bug and you need to prove it. Make a new project is what I said. That's not too hard. My builds work just like I expect when I use "Always Include".

It is trivial to call a VI that is included in an exe and as mentioned, that is the default setting. You obviously did not change the default setting. Look at the "Source File Settings". Look at the Destination. Did you modify the destination per what the help file says? No, I'm sure you did not.

[dbaechtel]

---

@Dennis Knutson wrote:

You are completely missing the point. I don't give a rat's behind to see your clin\ents code I and am not asking you to provide it. You are the one that says there is a bug and you need to prove it. Make a new project is what I said. That's not too hard. My builds work just like I expect when I use "Always Include".

It is trivial to call a VI that is included in an exe and as mentioned, that is the default setting. You obviously did not change the default setting. Look at the "Source File Settings". Look at the Destination. Did you modify the destination per what the help file says? No, I'm sure you did not.

---

First, so far in this thread I have not mentioned the word "BUG", so far. I just said that "Always Include" does not always include the files that I listed into the Destinations specified. And I have proven with my screen captures provided, that is a fact.

If "Always Include" takes VI source files that are to be dynamically loaded and combines them into the EXE executable file, then that was the wrong thing to do and not my intention. New VI and Open VI Reference functions can not find the dynamically loaded VIs there and requires the source files themselves and a path to them.

Dynamically loading and launching multiple copies of a VI file is not the same as calling a VI inside an executable. To accomplish my application, I must load and launch independantly functioning VI's from a template source file on demand. And that is what the New VI and Open VI Reference functions were designed to do and are doing when the files are provided. But to use those functions I have to provide source files for the dynamic VIs as part of the Build. And it appears the "Always Included" will not do that, as I expected it o do.

Yes, I did look over the Destination Settings in the Build Properties and I am perfectly happy with the way I have them set.

Can you answer this question that I have asked before: How do I get the source files of VIs and their components, that are to be dynamically loaded by the application, automatically copied by the Build process into a known directory somewhere related to the Build directory at Build time? What feature provides this function?

[smercurio_fc]

---

@dbaechtel wrote:
Dynamically loading and launching multiple copies of a VI file is not the same as calling a VI inside an executable. To accomplish my application, I must load and launch independantly functioning VI's from a template source file on demand. And that is what the New VI and Open VI Reference functions were designed to do and are doing when the files are provided. But to use those functions I have to provide source files for the dynamic VIs as part of the Build. And it appears the "Always Included" will not do that, as I expected it o do.

---

Then you are not understanding the purpose of that part of the page. The "Always Included" does NOT mean that the files are copied as is to the source directory. If they are VIs they will be included IN the application, not separate from the application in the data directory. In fact, the help specifically states: "Specifies the dynamic VIs and support files always to include in the application". It doesn't say "next" to the application, or in the data directory.

If anything, the Help file should probably have a sentence added to clarify this.

---

Can you answer this question that I have asked before: How do I get the source files of VIs and their components, that are to be dynamically loaded by the application, automatically copied by the Build process into a known directory somewhere related to the Build directory at Build time? What feature provides this function?

---

Create an installer. This will allow you to place whatever you want into specific directories.

[dbaechtel]

---

@smercurio_fc wrote:

---

@dbaechtel wrote:
Dynamically loading and launching multiple copies of a VI file is not the same as calling a VI inside an executable. To accomplish my application, I must load and launch independantly functioning VI's from a template source file on demand. And that is what the New VI and Open VI Reference functions were designed to do and are doing when the files are provided. But to use those functions I have to provide source files for the dynamic VIs as part of the Build. And it appears the "Always Included" will not do that, as I expected it o do.

---

Then you are not understanding the purpose of that part of the page. The "Always Included" does NOT mean that the files are copied as is to the source directory. If they are VIs they will be included IN the application, not separate from the application in the data directory. In fact, the help specifically states: "Specifies the dynamic VIs and support files always to include in the application". It doesn't say "next" to the application, or in the data directory.

If anything, the Help file should probably have a sentence added to clarify this.

---

Can you answer this question that I have asked before: How do I get the source files of VIs and their components, that are to be dynamically loaded by the application, automatically copied by the Build process into a known directory somewhere related to the Build directory at Build time? What feature provides this function?

---

Create an installer. This will allow you to place whatever you want into specific directories.

---

What purpose does it serve to include dynamically loaded VIs into the executable file? New VI and Open VI Reference can not access them there. How can they be accessed inside the executable to be dynamically loaded by these functions which work from a file path specification?

The location of "IN" is a matter of interpretation. "In the application" I would interpret to mean "as part of the application package". This could mean that it is part of the executable, but it could also mean that the source files can be included as part of the application package seperate from the executable file. The application consists of the executable file and associated directories, including data, and associated files.

I would rather not build a installer every time I need an updated executable file, just because the build process for an application is incomplete. The installer is a much longer process and in LabView's case, requires a machine reboot each time.

It would be much easier and simplier if LV provide a simple feature like "Always Include" that copies files without interpretation of their use into the specified directories. That's no so hard to do. I would be very happy with that.

Without that, I do not see how someone can build an application that includes dynamically loaded source files without resorting to building a full blown application installer, which is overkill in this case.

Thanks for you help.

[smercurio_fc]

---

@dbaechtel wrote:

What purpose does it serve to include dynamically loaded VIs into the executable file? New VI and Open VI Reference can not access them there. How can they be accessed inside the executable to be dynamically loaded by these functions which work from a file path specification?

---

It serves a perfectly legitimate purpose. For example, I have a memory log that's based on a queue. I have a viewer for it. It's dynamically called so it can be run and it can run in parallel to the application. I don't need (or want) this to be separate from the application. Since it's a dynamic VI it's included in that little box. And I call it just fine with VI Server. I have no idea where you got the notion that the VI Server cannot access them from there. As far as a path is concerned, the application becomes part of the path, as a folder. This has been brought up many times, and is even part of a KB article: http://digital.ni.com/public.nsf/allkb/FD7DE8BC8FFC256C862565F4006BE363

---

The location of "IN" is a matter of interpretation. "In the application" I would interpret to mean "as part of the application package". This could mean that it is part of the executable, but it could also mean that the source files can be included as part of the application package seperate from the executable file. The application consists of the executable file and associated directories, including data, and associated files.

---

You are free to interpret things any way you want. It won't change the universe.

---

I would rather not build a installer every time I need an updated executable file, just because the build process for an application is incomplete.

---

That's your prerogative. I told you how to do it. If you refuse to accept the state of the universe then perhaps you may wish on creating your own.

---

The installer is a much longer process and in LabView's case, requires a machine reboot each time.

---

It does not. If you are including the Run-Time Engine then that will ask you for a reboot. If the Run-Time Engine has already been installed there is no need to reboot.

---

It would be much easier and simplier if LV provide a simple feature like "Always Include" that copies files without interpretation of their use into the specified directories. That's no so hard to do. I would be very happy with that

---

I would not. I cite my previous example.

---

 Without that, I do not see how someone can build an application that includes dynamically loaded source files without resorting to building a full blown application installer, which is overkill in this case.

---

dbaechtel, meet universe. Universe, meet dbaechtel. Have a pleasant stay.

[Dennis_Knutson]

The feature is there but you are not using it. It's as simple as that. Show how you have the destination set for the external VI.

[dbaechtel]

We could do much better without the sacrasm. The sarcasm doesn't add anything to the techical discussion. I am trying to have a serious discussion here and obviously you are not.

Please confine your comments to the technical discussion at hand and leave your sacrasm out of it.

Any more of this abuse and I will report you to the moderator.

[Dennis_Knutson]

If you were serious about a technical discussion, you would provide an example. You stubbornly refuse to do so even in the face of hard and cold statements that "always include" does in fact allow you to pick a destination outside the exe.

This project puts a VI, ctrl, and an ini file exactly where I tell it to go.

[dbaechtel]

---

@Dennis Knutson wrote:

If you were serious about a technical discussion, you would provide an example. You stubbornly refuse to do so even in the face of hard and cold statements that "always include" does in fact allow you to pick a destination outside the exe.

This project puts a VI, ctrl, and an ini file exactly where I tell it to go.

---

I am legally bound by NDA not to share ANY software source with ANY 3rd party. I am afraid this includes any samples and this also includes this forum. SORRY. It's not stubborn, it's legally binding.

The zip file you included did not include any Build Specifications. I do not know how it shows me how to Build an application that includes dynamically loaded VI source files outside of the executable without a Build Specification.

The source files that need to be included come from several sources: some are part of 3rd party toolkits and some are part of lvlib's. In order to preserve the practice of having one source file in its default location (in case of updates), I can not gather a copy of all of these files into a special folder just so the build process can include the entire folder. To acomplish my goal, I need to have the Build process take the files from wherever they reside and then place them somewhere relative to the Build executable. I do not care where. I do not think that I can use folders to do this because I think that would cause me to move the location of the source files from their default locations (e.g. inside a 3rd party toolkit) to another folder, or to make copies of the files needed. Neither of these options is good practice from a maintenance standpoint.

I have set the Destinations in the Build Specifications, but I do not see how to place the files that I need into the Destinations that I need.

Do you have any specific advice on how to take source files, including VIs and CTLs from arbitray locations and to get the Build process to automatically copy these files into some location relative to the build executable without having to first move the files into a special folder?

[RavensFan]

I just knew this thread was going to go down this route when I first posted into it.

I really don't believe your NDA is as restrictive as you think it is.  If it really was, I don't think you should be posting into the forums and asking any questions at all during this time period that you are bound by it.