WMassey Posted October 22, 2005 Report Share Posted October 22, 2005 The NI application builder can save a project's build settings to a ".bld" file. Has anyone here managed to figure out the format of the data contained in that file? Thanks! Quote Link to comment
tleibner Posted October 22, 2005 Report Share Posted October 22, 2005 The NI application builder can save a project's build settings to a ".bld" file. Has anyone here managed to figure out the format of the data contained in that file? Thanks! Well, not the file format itself, but there ara two VIs from the appbuilder's llb doing the job to read and to write the *.bld files: C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Load Script.vi C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Save Script.vi I did use them once to leave all diagrams within an executable for later debugging. Thomas Quote Link to comment
Michael Aivaliotis Posted October 22, 2005 Report Share Posted October 22, 2005 I know that OpenG builder allows you to import an NI build file. This means there is code out there to read this info. Why not download the OpenG builder and poke around? Of course, the real question is, "why do you need this?" Perhaps if you let us know, we might find another solution to your problem. Quote Link to comment
WMassey Posted October 23, 2005 Author Report Share Posted October 23, 2005 Well, not the file format itself, but there ara two VIs from the appbuilder's llb doing the job to read and to write the *.bld files:C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Load Script.vi C:\Program Files\National Instruments\LabVIEW 7.1\project\prodisttool.llb\Dist Save Script.vi I did use them once to leave all diagrams within an executable for later debugging. Thomas Thanks. Yes I found these yesterday after I had already asked the question the day before. I ended up using the Load Script VI to accomplish that task I had in mind. I know that OpenG builder allows you to import an NI build file. This means there is code out there to read this info. Why not download the OpenG builder and poke around?Of course, the real question is, "why do you need this?" Perhaps if you let us know, we might find another solution to your problem. Thanks as well. I have the OpenG builder but I have not taken the time to figure out how to use it yet. I certainly didn't know that it could import a BLD file. That will be a good starting point for me in the learning process because it'll allow me to take what I alreay know about the NI builder and see how the OpenG builder gets setup to accomplish a similar task. As to why I need this, forgive me for not saying in the original question but it was starting to get late at work on a Friday afternoon... Anyway here it is now: The NI app builder is pretty good at determining which VIs should retain their front panels and which ones should lose them when building an application, but sometimes it gets it wrong, especially when many of the VIs have their front panels opened programmatically. I had just tried my first build of a project and when it was run discovered that the app builder did indeed remove some front panels that were needed. It's easy enough for me to tell which VIs in the project need to keep their front panel (they all share a couple of common subVIs used to control the appearance of the front panel). But it wasn't so easy for me to check my list against the app-builder's list of VIs that got to keep their front panels (there are 450+ VIs in the project). I just wanted a way to mash the two lists together and have a result spit out telling me which VIs need their app-builder settings changed. This is what I came up with: The real trick (for me anyway) was figuring out how the 3-state current/build "rm panel" values actually determined what was going to happen. The v7.1.1 VI is attached but you will need to have the NI app-builder packaged installed to use it because it needs the Load Script vi out of that package. In fact, it would be best if the app builder were idling in the background before attempting to open the attached VI just so it'll automagically find the VIs that are part of that package without you having to tell it where to look. :question: This has all led me to another question. The app builder has some subVIs in the project flagged as needing their front panels yet they are ones that never are called upon to show their panels. Any ideas why this might be? Thanks again! Download File:post-2800-1130089051.zip Quote Link to comment
Jim Kring Posted October 23, 2005 Report Share Posted October 23, 2005 There are several things that the LV App Builder uses to determine whether or not the FP needs to be preserved. For example, if it has the Open Front Panel When Called attribute set to TRUE, implicit control property or invoke nodes on the BD, or control reference constants on the BD. Quote Link to comment
WMassey Posted October 24, 2005 Author Report Share Posted October 24, 2005 There are several things that the LV App Builder uses to determine whether or not the FP needs to be preserved. For example, if it has the Open Front Panel When Called attribute set to TRUE, implicit control property or invoke nodes on the BD, or control reference constants on the BD. I took a close look at the VIs that had their front panels retained and I could find obvious reasons for all but one. A bit of digging and testing on that one turned up a couple of places where the caption text of a front panel indicator was being changed (left over when the VI had a starring role). Once I removed those property nodes, the requirement to have the front panel loaded went away. Quote Link to comment
m3nth Posted October 24, 2005 Report Share Posted October 24, 2005 I had the exact same problem. At least I think it was the same problem. I compiled a list of the different things you should check, which it looks like you finally figured out. See my old post here on NI... the list is attached to the post as a document with screenshots of everything you can look into: http://forums.ni.com/ni/board/message?boar...ssage.id=115500 Actually... I'll just let the lazy be lazy and post the document here also 'for convenience' Download File:post-360-1130161952.doc Quote Link to comment
Jim Kring Posted October 24, 2005 Report Share Posted October 24, 2005 I compiled a list of the different things you should check [...] the list is attached to the post as a document with screenshots of everything you can look into This would make a great addition to the LabVIEW FAQ. Quote Link to comment
WMassey Posted October 24, 2005 Author Report Share Posted October 24, 2005 I had the exact same problem. At least I think it was the same problem. I compiled a list of the different things you should check, which it looks like you finally figured out. See my old post here on NI... the list is attached to the post as a document with screenshots of everything you can look into:http://forums.ni.com/ni/board/message?boar...ssage.id=115500 Thanks! :thumbup: This will be a handy thing to keep around. I agree with Jim that it should go into the FAQ. Perhaps a section of the FAQ could be devoted to application building? Both with the NI & OpenG tools? And speaking of App-Builder things that should go into the FAQ, here is another NI thread that was useful for me: Why are the fonts on my VI different from the fonts on the EXE after App Builder? (I will note that the INI file you save with the executable does not have to be the full LabVIEW.INI file; just the lines with the font information will be enough) Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.