Help building an executable that uses a factory pattern

[SimonGoodson]

Hello,

I'm trying to build an .exe from a VI that uses the factory pattern. The VI gives me the error that it can't find the classes to load and is looking outside the .exe file to find them. The specific error is:

"Get LV Class Default Value.vi<APPEND>

<b>Complete call chain:</b>
     Get LV Class Default Value.vi
     Main.vi

<b>LabVIEW attempted to load the class at this path:</b>
C:\ATE\Experiments\Build Testing\Builds\Virtual Classes\High Class\High Class.lvclass"

I thought those classes were bundled into the .exe when it was built? I have included the class folders in the "Always Included" window of the build script.

Any help would be appreciated. I'm fairly new to classes and I haven't built an .exe with an app using the factory pattern.

Thanks,
Simon

[Bob_Schor]

When I open Main, it has a broken Run Arrow.  The Block Diagram shows "Get Class Name" as a Question Mark, and says it can't find it.  I'm using LabVIEW 2014, which looks like it might also be your Source Version.

Bob Schor

[AKA_TG]

Perhaps this may work for you? I cannot be sure though.

IN the build spec dialog..

Category :Advanced

USe LV8x file layout

[SimonGoodson]

---

@Bob_Schor wrote:

When I open Main, it has a broken Run Arrow.  The Block Diagram shows "Get Class Name" as a Question Mark, and says it can't find it.  I'm using LabVIEW 2014, which looks like it might also be your Source Version.

Bob Schor

---

Hi Bob,

Sorry, yes, I am using LV 2014 32-bit. Here is another zip. Perhaps I forgot to save before zipping last time, but I tested this one and it works.

Thanks,

Simon

[SimonGoodson]

---

@AKA_TG wrote:

Perhaps this may work for you? I cannot be sure though.

IN the build spec dialog..

Category :Advanced

USe LV8x file layout

---

Hi AKA_TG,

This seems to work, although it gives me errors concerning the identical file titles of the Get Class Name.vi and its two overrides. Additionally it makes folders out of the class name and places those identically named vi's in each folder name.

From what I read, LV8 layout only should apply to programs developed in those versions or earlier. This one is purely LV2014 code. Could someone point out what I am doing wrong that it won't compile in LV2014?

Thanks,

Simon

[Bob_Schor]

I didn't understand (and didn't read carefully) AKA_TG's response.  But I played around a bit, and discovered that if I checked the "Use LabVIEW 8.x file system" in the Advanced Option of the Build, the program ran.  That, of course, was the Message I Missed.

I recently had my own issues with Obscure, Poorly-Documented Build Options, and spent an hour on the phone with an NI AE.  We figured out what setting to change, but not Why, and not "But if it has to be set this way, why, by default, is it the other way?"  Sigh.

If you get a good explanation of what this switch means, when you must use it, when you must not use it, and what do to in the middle, could you post it here for those of us following this thread?  [I'll do the same ...]

Bob Schor

[Bob_Schor]

This might be the answer.  I found the following checklist on Building Executables.  It really is referencing things other than Objects, but maybe Object folders also need to be properly located ...

Bob Schor  [the stuff I found is below this line ...]

Ensure paths generate correctly.

Details

If a VI loads other VIs dynamically using VI Server or calls a dynamically loaded VI through a Call By Reference node, make sure the application or source distribution creates the paths for the VIs correctly. To ensure paths generate correctly, use relative paths to load the VIs. The following table depicts the relative paths for a top-level VI, foo.vi, which calls a.vi and b.vi. C:\..\Application.exe represents the path to the application.

Path to source files	Path to files in application
C:\Source\foo.vi	C:\..\Application.exe\foo.vi
C:\Source\xxx\a.vi	C:\..\Application.exe\xxx\a.vi
C:\Source\yyy\b.vi	C:\..\Application.exe\yyy\b.vi

If you use the LabVIEW 8.x file layout and you include dynamically loaded VIs in the application, the paths to the VIs change. For example, if you build b.vi into an application, its path is C:\..\Application.exe\b.vi whereC:\..\Application.exe represents the path to the application and its filename.

[mikeporter]

First thing is you can't use the old executable layout with OOP. With the old structure everything is essentially in one big directory, which means VIs can't have the same name -- but having the same name is how dynamic dispatch works.

From the error you're getting you either aren't specifying a path properly, or the class isn't getting included in your executable.

I'm sorry but I can't look at your code as I am on my phone right now.

Do you have all your classes in the Always Include section of the source file selection for the application builder? Your screen shot shows a folder but no indication of what is in the folder.

Based on the error message your code is not even looking in the executable for the class.

Mike...

[SimonGoodson]

All,

Apologies for not getting back to this earlier. Lots of meeting yesterday. After noodling around with this for most of the morning I think it is a problem with reading comprehension on my part. When I was educating myself on classes and paths and so forth I came across this article:

Why Does My Executable Not Work When Using the Current VI's Path Constant?

Basically it outlines the problem with using Current VI's Path.vi in the IDE and after build, and suggests to use the Application Directory.vi instead. I didn't read the description well enough and thought the application directory was a one and done solution. Instead it returns the directory of wherever the .vi or .exe are located. So it works great in the IDE environment when the main VI is in the base directory, but after being built I need the base directory along with the "\application.exe\" addition to find classes contained in the .exe. I'll post a new build Monday to see if my theory is correct.

Thanks for the help everyone!

Regards,

Simon

[mikeporter]

You are on the right track but there is a lot more to it -- especially if your source is located on more than one disk.. One simple solution that I have demonstrated is have some vi that is located in the same directory as the project file save its path to a FGV. I call this path the "internal path" and I use it to locate files that will be in the executable (in other words, LabVIEW files). For non LabVIEW files I use the application directory primative.

For me this is very easy to implement because by convention I always have the top level vi in an application located in the same directory as the project.

Mike...