subpanel odd behavior in 2009 build

[Val Brown]

OK, this is a real mystery to me. Probably I just don't understand the implications of the setting but here's the scenario. I have a project with a top-level VI that has a subpanel that call two different VIs, each in a separate page of the control. So, shift to page 2 and one of the VIs is visible, switch to Page 3 the other is and the other tabs access controls that are internal to the top-level VI. The called VIs are included in the Always Included list in the Source Files page of the App Builder. Inclusion Type is set to Include if Referenced with the Application EXE as the destination. When i use the 8.X file layout in the Advanced page, the build succeeds and the app works correctly, loading and running appropriate VIs as each page is selected; however, if I deselect using the 8.x file layout, the pages are blank when called unless the flat VIs are included on the hard drive of the target system, in the correct location per the development file layout. Obviously I'm not setting up the inclusion process correctly but I really don't get what to do to make it work correctly when not using the 8.x file layout.

Any help would be appreciated including pointing me to relevant KBs that I've overlooked in trying to resolve this.

[jgcode]

OK, this is a real mystery to me. Probably I just don't understand the implications of the setting but here's the scenario. I have a project with a top-level VI that has a subpanel that call two different VIs, each in a separate page of the control. So, shift to page 2 and one of the VIs is visible, switch to Page 3 the other is and the other tabs access controls that are internal to the top-level VI. The called VIs are included in the Always Included list in the Source Files page of the App Builder. Inclusion Type is set to Include if Referenced with the Application EXE as the destination. When i use the 8.X file layout in the Advanced page, the build succeeds and the app works correctly, loading and running appropriate VIs as each page is selected; however, if I deselect using the 8.x file layout, the pages are blank when called unless the flat VIs are included on the hard drive of the target system, in the correct location per the development file layout. Obviously I'm not setting up the inclusion process correctly but I really don't get what to do to make it work correctly when not using the 8.x file layout.

Any help would be appreciated including pointing me to relevant KBs that I've overlooked in trying to resolve this.

Hi Val

I risk stating the obvious... (so don't shoot me down )

The VI paths change between build models (8.x vs 9.0).

It sounds like your inclusions are fine

How do you resolve the VI paths so that you get a reference to them?

I tend to use a Static Reference now-days rather than trying to resolve the valve of the path data type (based on Dev vs RT) so it doesn't matter what the internal structure of the 9.0 build is.

-JG

PS - I like to create a VI Tree.vi and stick all dynamic VIs in there so I only have to Always Include one file - so I don't forget to add new ones to the build spec.

[Val Brown]

Right, no shooting allowed...

I do what I've always done. It is a path control with the full path name of the VI that is to be included in the tab of the subpanel.

So don't shoot me if something else should be done to support the 9.x file format.

val

Hi Val

I risk stating the obvious... (so don't shoot me down )

The VI paths change between build models (8.x vs 9.0).

It sounds like your inclusions are fine

How do you resolve the VI paths so that you get a reference to them?

I tend to use a Static Reference now-days rather than trying to resolve the valve of the path data type (based on Dev vs RT) so it doesn't matter what the internal structure of the 9.0 build is.

-JG

PS - I like to create a VI Tree.vi and stick all dynamic VIs in there so I only have to Always Include one file - so I don't forget to add new ones to the build spec.

[jgcode]

Right, no shooting allowed...

I do what I've always done. It is a path control with the full path name of the VI that is to be included in the tab of the subpanel.

So don't shoot me if something else should be done to support the 9.x file format.

val

Deal!

Give this a shot and let me know how you go.

[edit]

In my browser the above picture is distorted (stretched)?

Just right click and select Open In New Window to view in native resolution

[/edit]

[Val Brown]

I'm a little confused. The first dynamic "object" I point to the file location for the VI I want to call dynamically in the subpanel?

[jgcode]

I'm a little confused. The first dynamic "object" I point to the file location for the VI I want to call dynamically in the subpanel?

Just drag and drop the VI you want to call dynamically into the Static VI Reference and it will show the icon for that VI.

Now you have a reference to that VI.

Now use a Property Node to get the VI's Path so that whether you call this in Dev or RT it will be the correct path.

Hope that make sense??

Cheers

-JG

[Val Brown]

Yes that does make sense. I'll give it a try. Thanks!

[jgcode]

Yes that does make sense. I'll give it a try. Thanks!

Cool - did you get it to go?

[Val Brown]

Cool - did you get it to go?

didn't get to try it yet but I will over the weekend and I'll let you know. thanks again.

[Val Brown]

OK so that did work and now I'm intrigued that having a path control with the absolute path to the VI didin't work but this process did. The question to NI is: what's the thinking on that one? Or to say it another way, shouldn't the absolute path work -- always -- regardless of anything else??

And thanks for the tip. I'm no longer blocked.

[jgcode]

OK so that did work and now I'm intrigued that having a path control with the absolute path to the VI didin't work but this process did. The question to NI is: what's the thinking on that one? Or to say it another way, shouldn't the absolute path work -- always -- regardless of anything else??

And thanks for the tip. I'm no longer blocked.

No probs.

What absolute path are you using?

I am sure you could still get to it, but you would have to be using the correct one.

The easiest way to do this is to use the reference and path property node to write it to the screen so you can see it.

Then you could try that path in accessing the VI (just to test it).

The 9.0 build model is a similar structure to whats on disk however, depending on your linking it can change.

Plus the .exe "folder" will be in there somewhere to.

Using a reference is by far the safest.

I haven't had to deal with resolving paths for a while now

[Yair]

Presumably, since the 8.x build option makes this work, it's simply a matter of you building the path in a way which is incompatible with the 2009 EXE structure. 8.x has all the files inside the EXE in a flat structure (except for those with duplicate names) and 9.x maintains the original hierarchy inside the EXE by using virtual folders.

As suggested, using static references is the best solution for this, but if you do need to load the VIs dynamically, the easiest solution is probably to place a VI in the plugin folder which will return a path to that folder. Then, you will get the path correctly regardless of where the folder is.

[Val Brown]

The plugins folder? I didn't know about it. Any KBs, example code or any other good refs for using it when building EXEs?

[Yair]

I simply meant the folder in which the code you call dynamically resides (or a parent folder. Basically just a base path which will allow you to build an absolute path to the VIs). Since dynamically called code is often plugins, that's the term I used. The point was that if you include the dynamic subVIs in the build, they will remain in the same place relative to that VI.

This VI can be as simple as this:

[Val Brown]

Even if I choose to have everything included in the built EXE?

[Yair]

Here's the scenario I think you have:

1. You have a VI which you only call dynamically (i.e. it's not in memory and you use the OVR primitive and wire a path into it). Its path is c:\my proj\VIs\dynVI.vi and the main VI is in c:\my proj).
2. When you build you tell the app builder "this is a dynamic VI, always include it".

In this case, LV will include the VI with all its dependencies and maintain the hierarchy, so the VI will be in c:\my exe\app.exe\c\my proj\VIs\dynVI.vi (the exact details may vary, I haven't studied this closely). If you place the subVI I showed in c:\my proj\VIs, it will always return the correct folder, even in the EXE.

[jgcode]

Here's the scenario I think you have:

1. You have a VI which you only call dynamically (i.e. it's not in memory and you use the OVR primitive and wire a path into it). Its path is c:\my proj\VIs\dynVI.vi and the main VI is in c:\my proj).
2. When you build you tell the app builder "this is a dynamic VI, always include it".

In this case, LV will include the VI with all its dependencies and maintain the hierarchy, so the VI will be in c:\my exe\app.exe\c\my proj\VIs\dynVI.vi (the exact details may vary, I haven't studied this closely). If you place the subVI I showed in c:\my proj\VIs, it will always return the correct folder, even in the EXE.

I don't think this is 100% guaranteed in the 2009 Build Model.

For example if you have a VI at C:\<src tree>\project\subVIs\*.vi and you do a build then

Link to D:\<where-ever>\*.vi then do a build

Then the internal hierarchies will be different.

I think the best\safest way is a static reference.

(Granted, why would you do the above - but it is still an edge case to consider, there maybe others too)

[Yair]

I agree that using a static ref is the best option. My description was simply that of the basic behavior of 2009.

[jgcode]

I agree that using a static ref is the best option. My description was simply that of the basic behavior of 2009.

Yer, I have seen the layout change internally and I don't like that.

But you can't have your cake and eat it too.

Whilst, a .llb layout is very handy for relative calls, encapsulating libraries and classes etc... inside the build (exe) is far more valuable IMHO.

However, its nice that you have the option to use the 8.x Build Model.

Otherwise porting up all my older code would be a nightmare.

[Val Brown]

Yer, I have seen the layout change internally and I don't like that.

But you can't have your cake and eat it too.

Whilst, a .llb layout is very handy for relative calls, encapsulating libraries and classes etc... inside the build (exe) is far more valuable IMHO.

However, its nice that you have the option to use the 8.x Build Model.

Otherwise porting up all my older code would be a nightmare.

It HAS been a nightmare for me.