kennoncotton

Dave, Yes that is an issue with our tools as well, even prior to the application instances in LabVIEW 8.0 and we have a way to deal with it. As far as that part of the API being "exposed", it is actually a private property so it isn't exposed but there is information on it outside of NI. So rather than spelling it all out, I'll get you pointed in the right direction, take a look at this thread: http://forums.lavag.org/index.php?showtopi...pp.menulaunchvi Kennon

Dave, Yep it would be nice if App Builder took care of this. We did make some progress in 8.0 in that we automatically copy the labview.ini file for you and rename it to yourapp.ini. We do remove some of the entries that are only used by the development environment, like grid line settings, and in a test I just did we do remove the SCC settings as well. I'm trying to decide if that is an oversight or because building SCC into an EXE is not very common, what we should do to not clutter the ini file for everyone else. I'm thinking it isn't too bad to clutter the ini file for everyone else and we should leave them in there. Also in 8.0 you can specify a .ini file from your project to use as your application's ini file, you could do this before but now it is highlighted as something that needs consideration. This way you know what settings are going to be used like specifying the web server to be enabled in the exe even when it is disabled in LabVIEW. I think copying the labview.ini by default is really just a good way to get started. If you have an EXE that you are serious about what you want to do is have a custom ini file for it. I recommend doing the following. Configure all your settings in LabVIEW the way you think you need them. Then open your labview.ini take out everything you don't think you need and save that as yourapp.ini (change the section header too). Then add that file to your project so you can include it as the ini to use for the build specification. I think that while building exes has gotten easier there are still some rough places (like ini files) that need some polishing, we'll keep working on it. Kennon

Dave, I assume you have followed the instructions on "Building Stand-Alone Applications with Source Control VIs" from the LabVIEW help? Here is an on-line link. I think your problem maybe that your application's .ini file doesn't have the necessary configuration tokens in them. Take a look at KnowledgeBase entry 3M0D2S00. This KB was supposed to be live but wasn't, a collegue of mine saw your post and realized it wasn't live and updated it today. Kennon

So I've been looking for an excuse to post one more time so I'd get a LabVIEW flag under my name, and even though Joe has answered the question, I'll post that yes the installer will look at a higher level than it has in the past and only install what has a newer version. You will have to bump the version number of your part of the installer as well so that it will be installed or uninstall your part first. When you run the installer the last screen you get before all the copying happens will show a summary of what will be installed and removed.

Well, I figured that I would get that question since I mentioned that App Builder does it. Basically like everything 'fun' in LabVIEW it is done through a private VI Server method. However since the My Computer node of each project has its own application instance you can create a new project, get a reference to My Computer and then add files. With the private method you wouldn't have to create a project but the net result is basically the same.

The new application instances have thrown a wrench into some of our toolkits as well (that is why the Internet Toolkit and Express VI development toolkit have patches that will be on the web this week). Application instances are a great thing, they are the magic behind the targets in LabVIEW 8.0 and are sort of a super namespacing so we can avoid name conflicts, not have our VIs that are running in the background show up in your VI Hierarchy Window, etc. The new Application Builder creates a temporary application instance to load the VIs you are building into during the build process, that way you don't have to close the VIs you are building any more. So what are these application instances? Well page 39 of the LabVIEW Upgrade Notes does a good job of introducing them. Basically there is a Main Application instance which is the default area for VIs that aren't in a project. Also there is an application instance for each target in a project, so you can have an area for the VIs on your desktop machine and an area for VIs on each target (specific RT device, PDA, etc). These areas can have different application level settings and you can have 2 VIs of the same name or even same path in 'memory' one in each application instance. There are also several private application instances one where VIs related to the project run, another for VIs in the Tools Menu, etc. They are a little different from the namespacing you get with project libraries because the application level settings (Tools>Options, Right-click on a target and Properties) can be different in each application instance, such as VI Server settings. And you can have a Project Library open in multiple applicaiton instances. So specifically for the Tools menu, the items launched from it are launched in the NI.LV.Dialog application instance, which is where we run LabVIEW based dialogs. So if you have a utility such as Web Publishing Tool that needs to be able to access all VIs in memory or like the Express VI Development Toolkit's UI that needs to open VIs in the user's current application instance, what can you do. Since we had this hurdle to overcome, we created a couple of VIs that are in vi.lib that we use in our VIs in the tools menu and you can use as well. They are mentioned on page 11 of the LabVIEW Upgrade Notes. <vi.lib>\Utility\allVIsInMemory.llb\VIMemory Get VIs in Memory.vi will return an array of clusters containing strings with the Project, Target and VI Name, plus the Application Reference for all VIs in memory. (Yes it says ComputingNode but imagine it says Target). You can optionally only return the VIs that have their front panels open. With the Application Reference and VI Name you can open a VI reference to the VI you need, even though it is in another context. <vi.lib>\Utility\allVIsInMemory.llb\Get User Application Reference.vi will return the current My Computer application reference the user is using. So it will return the Main Application Instance if they aren't in a project or the Application Reference for the My Computer node if they are in a project. Note it won't return the Application reference for a target, since this VI was designed with Utilities in mind we didn't think that we would want target application instances. As you mentioned in your referenced post you can either modify the Open G Builder to look in the other application instances or you could modify it to have a launcher VI that opens it in the user's application instance. I think the former might be what you want long term, but the latter will get it working quicker. So what if that isn't enough for what you need? There are some VI Server properties that allow you to get to this information, like Projects.Projects[] to Project.App. From Project.Targets[] you should be able to get to the application reference, however I didn't find a public way to convert it or get a reference to the Main Application Instance. I thought we had more public than what I'm seeing right now, but it has been a while since I turned off private stuff. I'll check into it and see why those items aren't available. Kennon PS why can't I choose LV 8.0 as my current version in my profile? I've been wanting to set it that way for a while

Yes it is now a 2 step process, really it always has been but it was an automatic 2 step process. No ease advantage I guess but it is more flexible since it gives you the ability to include more than one exe, dll or source distribution in an installer. Also you can rebuild the exe and test it on your local machine without having to rebuild both the exe and installer or change the settings and build and remember to change them back. It may take a little getting used to but I think you'll find a use for it. Ideally when you try to build an installer that includes the output of an exe build and the exe build isn't up to date, the installer build would recognize that and build the exe before it builds itself, sorry we couldn't get everything into 8.0. You can build both the exe and installer in one step by selecting the exe then while pressing ctrl select the installer so that both are highlighted, then right click on one of them and choose build. This will build all the selected build specifications in the order they were selected. Kennon

Yep it is a very similar experience. Check a box in App Builder, build your app, run it, then in LabVIEW go to Operate>Debug Application or Shared Library to connect to the app. And of course the app can just be on your local machine. If you are in the Beta program you can check it out now before you get your final copy. Kennon

Thanks. I've been following the forums for a while, I just haven't got around to posting. Which reminds me, I need to see about getting a Texas flag under my name to reflect my true country of origin If you have a list of things that aren't cleaned up by the RTE when it uninstalls let me know, to my knowledge it should remove everything, if it doesn't then we need to get that fixed. I understand the convenience of not installing the RTE, in fact I showed how to create a LabVIEW based autorun for a CD at NI Week 2002, so you could have a LabVIEW built EXE launch when the CD was inserted without having to first install the RTE. (BTW I'll be doing a similar presentation again this year, but I'll also be showing what App Builder might look like in the future.) Even though it is convenient and not too hard to do, as LabVIEW and the RTE get more complicated it will be harder to keep this up. This will work for simple applications where all you need is in the RTE folder, but if you are using DataSocket, 3D Graphs, Storage VIs or other LabVIEW features where you have files in various locations, have to register the DLLs, need certain files for certain OS versions, etc., an installer is the way to go. Kennon

Yep, you can always reverse engineer the installer it is mostly copying files and putting in registry entries or instead you could just run it

Actually, machine specific information does not need to be known at build time of the exe or of the installer. The Analysis VIs contain call library nodes that call lvanlys.dll, this DLL determines CPU type and loads the appropriate Math Kernel Library and calls it at run-time. So you could end up with a call chain of Mean.vi->lvanlys.dll->mkl_p3.dll or Mean.vi->lvanlys.dll->mkl_p4.dll at run-time. Since the CPU specific code is in a DLL it doesn't get compiled at build time and also because it is called indirectly it doesn't have to be copied around at build time, we assume the installer takes care of getting it on the system. I thought that our installer was smart enough to determine the CPU type at install time and install just the MKL DLL needed for the machine it is being installed on, but after looking at it some more, it looks like it is installing all of them all the time. Either way you shouldn't end up with exe/installer that you can use on one machine but not another, because the machine specific code is not directly called by the VI and the installer puts what you need on the target machine. Now if you are just trying to copy the EXE and the files in the RTE over to another machine, you could/would miss these secondary DLLs and might not copy the right one. So it is important to run the installer for the RTE. Kennon

Jim, With LabVIEW 7.1, the lvanlys.dll is not 'self contained' as it was previously. It has dependencies on other DLLs (Math Kernel Libraries) that are installed specificially for the CPU type being used (P3, P4, etc). So you really need to install the LabVIEW Run-Time Engine to not only get the other DLLs but to get the right one. Kennon