Jump to content

DanS

Members
  • Posts

    7
  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 8.5
  • Since
    1997

DanS's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. The simple answer is, I don't. I explicitly set it up so that the exposed VI were all uniquely named. The whole exercise was meant to try and get the "best of both worlds" vis-a-vis the internal directory structure within an application built in LV 2009.
  2. I'm curious, what do you think of my particular approach for solving the problem? In my specific case, I have several VI that I intend to export from my application. By forcing the VIs to be placed in the "root" of the application, I can find the VI's directly by name without having to rely on any other lookup mechanism. I was actually trying to highlight a trick with the application builder, i.e. creating a custom Destination that pointed to the Application itself and by explicitly setting the Destination for any VIs that I want to export. Now I can use a general purpose Call Exported Function VI to access the VI.
  3. But my problem involved accessing a VI within an executable that is running as an ActiveX server by a separately running VI (not a different VI within the application). I don't see how either of those methods will work.
  4. I really like that they figured out a way in LV 2009 to fix the naming conflict problem in a built application. But an unfortunate side effect is that if you want to run a VI within an executable, you must know the full embedded path. Depending on how your sub-VIs are organized, this path can be unpredictable. You can go back to the LV 8.x file layout, but then you are back to the original problem. I figured out a way to have the best of both worlds--it is possible to force a sub-VI to be saved into the "root" of the application in LV 2009. First off, you need to create a new destination in your build that is the path of the built application. Then you need to explicitly add the sub-VI to the project, and set its destination to be the new destination you just created. Now when you build the application, no matter where the sub-VI is located relative to the top-level VI, its path will always be at the "root". This was really useful when I was building an app as an ActiveX server, and I wanted to call a VI within the app remotely using the VI server.
  5. The Windows API call that you are thinking of is SetParent. I have used it in an application, and it works with LabVIEW panels. You just need to get the handles of the parent and child VI's.
  6. You're right about the SHParseDisplayName(). I'm not sure even why I wrote it the way I did. As for the parameter specification for the pidl, I have absolutely no idea how to specify a pointer to an arbitrary structure in the Call Library node. The LabView documentation gives no examples, so I just took my best guess and figured that as long as I was telling it that I was specifying a pointer, that was good enough. I only specified Pointer to Array because the other two options didn't seem correct. I figured that I would just treat the structure as a byte array. If that is incorrect, then what should I be using for that parameter?
  7. I've made my own version of the folder browsing VI. I figured out a way to pass in an arbitrary root folder, so the browsing window only displays the folder and all its subfolders. (This VI is in LV 8.5) BrowseForFolderEx.vi
×
×
  • Create New...

Important Information

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