Jump to content

subpanel odd behavior in 2009 build


Recommended Posts

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.

Link to comment

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.

Link to comment

Right, no shooting allowed... :thumbup1:

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.

Link to comment

Right, no shooting allowed... :thumbup1:

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.

post-10325-127380382061_thumb.png

[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]

Link to comment

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

Link to comment

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. :worshippy:

Link to comment

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. :worshippy:

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 :)

Link to comment

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.

Link to comment

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:

post-1431-127430004868_thumb.png

Link to comment

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.

Link to comment

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)

Link to comment

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. throwpc.gif

Link to comment

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. throwpc.gif

It HAS been a nightmare for me.:frusty:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.