kennoncotton

QUOTE(LaserDrive @ Apr 19 2007, 11:02 AM) Or if you are using 8.2 you can right click on a build specification and choose Duplicate, to get a new copy of the build spec. And as part of duplicate on an installer spec Application Builder will generate a new Distribution ID and Upgrade Code, so that the new installer spec generates an installer that won't do an upgrade / uninstall of the output of the original installer spec. We had the Product Code visible prior to 8.0 in the UI as an indicator and you could generate a new one, mainly because it seemed common to reuse a .bld script to generate a new exe (new program, not just new version) and you probably didn't want the installer to upgrade. We took it out of the UI in 8.0 because we thought with separate projects people wouldn't run into this as much. We are contemplating putting back in, but for average Joe LabVIEW User it is a little strange to see a GUID like that, even more so to see 2. And if we put it back in it would probably be as a control so that you could have 2 installer specs with the same info if you wanted them to actually affect one another. I guess that is the real dilemma is it more common to want to set these codes to be the same (need to be able to set them in the UI) or to want them to be different (just an indicator or not visible at all)?

QUOTE(crelf @ Apr 10 2007, 11:23 AM) LabVIEW decides whether to use a relative link or system search path based on what you type into the 'Library name or path' control in the Call Library Function configuration dialog. If you put just a name, when you press OK LabVIEW will search your system path (and then your VI Search path, I think) for the library and load it from there. If you put in a path when you press OK LabVIEW will verify the DLLs existance and store a relative link from the VI to the DLL. Using just the library name does mean if your path environment variable is different on different machines you may get a search dialog on other machines. And yes if the DLL is different on different systems you could have trouble, if there is a function available in XP that is not in 2000 your VI will be broken, if the parameters differ the call could fail, if the underlying code is different then the behavior could be different. The OS calls I've used and seen others use Microsoft generally does a good job keeping the API compatible (at least on all NT OSes, 9x<->NT has differences). If there is a difference in the API then a case structure or conditional disable or dynamic VIs can be used to call the correctly configured instance. I would say in general it is a robust enough thing to do, but obviously test on all the platforms, specifically in areas where you are concerned there may be a platform difference. The http://sine.ni.com/devzone/cda/epd/p/id/4935' target="_blank">Windows Utilities LLB for instance has been around since LabVIEW 4 and Windows 95? / NT 4? and still works. There is a DLL included in the .zip but many of the VIs call directly into the Windows DLLs

Actually Application Builder will determine if the DLL used in the Call Library Function Node is a system DLL / whether to include it or not based on the way it is referenced in the Call Library Function Node. If you have the full path to the DLL in the Call Library Function Node (c:\windows\system32\win32.dll), LabVIEW will store a relative link from the VI to the DLL and Application Builder will copy it assuming that it is not a system DLL. If the Call Library Function Node only contains the name of the DLL (win32.dll), LabVIEW will not store a relative link and will search the system path to load it and Application Builder will not copy it assuming that it is going to be in the system path of any machine you are going to put the DLL on. Since you did not include the DLL directly in your project or build specification, I suggest checking all the Call Library Function Nodes in your application. Load your start up VIs and dynamic VIs and go to Edit>Find and Replace and search for the Call Libary Node. You should be able to open each one you find to see where win32.dll is being called and change it to just have the file name and not the full path, save the VI and then try building again. If it happens to be a VI from NI let us know and we'll fix the VI. Kennon

QUOTE(machyaer @ Feb 23 2007, 05:23 AM) Max, There are a couple of command line arguements that you can pass, INSTALLDIR and DISTROOT, in the Run executable after installation portion of the Installer Properties that will give you the information you are looking for. Here is a link to the help topic for that dialog: http://zone.ni.com/reference/en-XX/help/371361B-01/lvdialog/adv_installer_settings_db/' target="_blank">http://zone.ni.com/reference/en-XX/help/37...er_settings_db/ Kennon

The limitation is not the long, qualified in memory names, they will stay "long" after the build process, the problem is the filename on disk. On disk LibA.lvlib:ClassA.lvclass:anything.vi is c:\somewhere\anything.vi, if you have 2 Project Libraries that have anything.vi in them, then they must be in separate folders because the OS won't allow them 2 files of the same name to be saved in the same location on disk. Or they have to be in separate LLBs because a LLB is a essentially a single directory. So your project has 2 VIs of the same filename in memory because they are different qualified names and life is great in the development environment. When we build an app we essentially create a single LLB of all the VIs and stick it into the EXE, unless you create multiple destinations and specify parts of your source to go to those different destinations. So those 2 files of the same name are going to be stuck into the same LLB, which means either we fail because you are putting 2 files of the same name in the same directory or we let the last one copied into the LLB 'win' or we rename the duplicates and update all static linkages. We chose to rename any duplicates going to a destination and update the static linkages and since we don't know about the dynamic linkages we give a warning about them being renamed. The thought was more of the links are probably static and would be updated so the EXE would work without any further problem. If you are calling VIs dynamically I recommend you create additional destinations and put each Project Library in its own destination, this does require you add logic for where the VIs will be found when in an exe, but it allows the file names to stay the same. One other caveat about when we do a rename is with LabVIEW Classes and dynamically dispatched VIs, as mentioned those must have matching names so when App Builder finds one it will not put it in the EXE by default but rather create a separate folder for it and put it outside so that its filename can stay the same. This is the way it is going to have to be until we either stop using LLBs as the internal storage mechanism for EXEs or make LLBs support multiple files of the same name being stored inside of them (seems like that would be confusing). I know that doesn't solve the rename problem, I'm honestly not sure when or if we will do that, but hopefully understanding what is going on will help you be able to handle it better. Kennon

The VIs you mention in 1 is the BuildTargetBuildSpecification.vi, well that VI is the supported way of programmatically building an app/dll/installer. A global is no longer used to pass build progress information and there isn't a supported way for you to view that information. Generally with a programmatic build I would think you are calling it from the command line / a batch file that is scheduled to run at a certain time (overnight?) and you don't want to have anything show at all or you don't need anything to show. I'm trying to figure out why you want a programmatic build but are going to be watching it so you want to see progress and be able to cancel. What does Build, Build All or a multi select and Build not give you that you need? Is it a pre build or post build operation that you are doing? Kennon

The LabVIEW Installer Builder doesn't currently support that. However a recursive file listing of the Installer Destination directory will return that set of files, the only problem is it will also return any other files that were prevously there. We do clear some of the subfolders that are generated, like Volume\Bin, but the main folder just gets files copied into it. BTW 8.2 has a Recursive File List VI on the Advanced File IO palette, it exists in 8.0 as well in <vi.lib>\utility\libraryn.llb\Recursive File List.vi. This also isn't currently possible. We intentionally made the programmatic build be completely non-interactive, not to show any UI. Are you wanting the progress dialog to track the progress of the build or to be able to cancel the build or both? I can see us possibly adding an option to show the dialog, but it would be off by default. Kennon

Okay, I didn't think about the DLL being called through a CIN, but the intent of my response is still correct, you need to do some work further up the build chain process to fix the problem. I would say either A) don't include it in the EXE build and instead add it in the installer or B) change the where it is going in the EXE build spec and if necessary where the CIN looks for it. A) If you don't include it in the EXE build, you'll have to manually copy the DLL on your build system to get it to work, but you could include it in the Installer to go into windows\system32 so the EXE will work on your target systems. This is the quick solution. B) A more complicated solution but maybe more "correct" is to modify the CIN so it can find the DLL when the VI containing the CIN is used in the Run-Time Engine / an executable and put the DLL in that relative location in the EXE build instead of in system32. It would then propogate to the Installer build in that relative location. Also I was able to reproduce the behavior of the Installer builder moving the .dll into the [ProgramFilesFolder]\Browser, but I wasn't able to have it automatically make a second copy if it in [systemFolder] with out selecting it from the project and including it there, can you tell me how to reproduce that or email me an example of code that is exhibiting that behavior. Kennon

I think you should be able to remove it but it will need to either be done in the EXE build Specification or in the Call Library Nodes for the DLL or both. Basically the Installer builder attempts to keep all the files in the same relative place from your EXE build because we don't want to break VI linkages or change them while building the installer. It expects that you have everything configured the way you need it in the EXE build and you need to include that exact image. This works well when the EXE is built into one main destination folder and its subfolders, but can break down with items that are linked to are in folders that only share the root folder (c:\) in common, like your EXE preview shows, or the relative paths require going up several folders and then back down. I think what is happening here is the Installer builder is adding zlib.dll to [ProgramFilesFolder]\Browser because it can't calculate a good relative path up out of there to where the EXE builder says it should go. And I'm assuming that you added zlib.dll to the [systemFolder] manually in the Installer(which is the right thing to do). Based on the EXE preview I'm assuming you are either manually including zlib.dll in the EXE build, because it was not there or you manually changed its destination from the Support Folder to system32? Solution A: If you are manually including it in the EXE as a Support File I suggest removing it, because it is in the System folder the linkage to it doesn't get updated and it will be found there. And only manually including it in the Installer Build going to the System folder Solution B: If you are manually changing its destination in the EXE build to go to the System folder, I suggest changing the way the Call Library Nodes are configured. Since the DLL exists in the System Folder it is in the search path for the system and LabVIEW will find it there, we don't need to store a relative link to it. So go to each Call Library Node and make sure you only have the library name listed "zlib.dll" not the full path "c:\Windows\System32\zlib.dll" This will indicate to LabVIEW the DLL resides in a folder in the system search path and it won't store a relative link to it, so the EXE builder won't put a copy of it in the Support folder so it won't be part of the EXE preview or the files the EXE builder tells the Installer Builder to include. But you will have to include the DLL manually as part of the Installer Build so that it is guaranteed to be on the system the installer is run on. Kennon

Willy, You can buy Application Builder and install it on LabVIEW Base or Full Development Systems. If you have it installed on Base or Full it should up under Add Remove Programs. It is possible that instead of being installed App Builder was copied to that machine and not everything was copied that it needed. I suggest getting the installer for App Builder 7.1 Kennon

Willy, Based on what you said I think the problem is due to some missing files in the <labview>\applibs folder, something that shouldn't happen so there isn't a great error for it. Check to see if you have dllshell.lib and lvapp.lib there, if they aren't, I recommend going to add/remove programs and choosing to repair your installation of App Builder or LabVIEW Pro. Kennon

No problem. Sorry this post took a while, it has been a busy week figuring out what we need to be working on based on all the feedback from NI week. Hmm, I was thinking that you would be using this VIs as subVIs not as subpanels. From the testing I've done, I can run a VI from another EXE as a subVI (call by reference) but I can not insert it into a subpanel. It sounds like you have some common UI modules/reuse code, not just a common API or non-UI reuse code, I think my option 3 of doing a source distribution makes the most sense for your setup. I've got a nice autographed copy of that same reference sitting on my desk here, Thanks Jim. You might be having the same problem I had initially in that I didn't have localhost wired into "machine name" on Open Application Reference. I have to admit I didn't compeletely write out a test for this option before I suggested it. But I've cobbled one together between meetings yesterday and finished it up this morning. Basically the attached project builds 2 EXEs. One contains A.vi and B.vi. A.vi opens a reference to B.vi that shows you can use a path with <foo>\some.exe\<bar>.vi in an exe to call VIs that are in that exe. The other EXE uses VI server to access the first EXE and call B.vi, it also tries to insert it into a subpanel, which fails. To show you can view the panel I added an open panel and a loop with a wait to keep it around after the reference closes. One caveat is the first EXE must be running (well at least open) for the second EXE to access it's VI Server, the old method of calling a VI right out of another EXE didn't require it be open. So this should show what is possible using VI Server (or the ActiveX server) abilities of an EXE, but I do think you need a more modular approach on these common features and create a source distribution(s) for them. Hope this helps, Kennon Download File:post-624-1155914696.zip

Todd, Yep in 8.2 we made a change that "fixed" being able to take a .exe (or .dll) rename it to a .llb and view its contents, at least on Windows. Some people have been worried about this being a "security" hole because you can see the VI names and connector panes if you have the same version of LabVIEW the executable was built in. But you can't see the block diagrams or most of the front panels (just the ones you specifically kept), so I don't know how much of a "security" issue it was but it certainly bothered some people. Now if you had debugging turned on in 8.0, App Builder kept the front panel and block diagrams so it really did have your all code, but you shouldn't be handing out debuggable exes. The reason we changed this behavior wasn't for this security issue, but for compatibility with the upcoming Windows Vista. In Vista you can / need to sign your executables (I'm pretty sure XP supports this as well and 2000 might) to show they are legit and if you signed a LabVIEW built EXE or DLL made in 8.0, the EXE/DLL stops working. So we changed the way we put the VIs into the EXE/DLL so that signing the EXE wouldn't "destroy" it, and as a result you can no longer see the contents of one by renaming it to be a .llb or access VIs in it by path from outside of the EXE. As the person who told you that would still work, I think I did misunderstand your question or didn't communicate my answer well, so let's get it in writing . You can still call VIs that are in an EXE, obviously ones you are calling directly/statically but also dynamically through VI Server. But you can only call them dynamically from a VI is in that EXE or running in that EXE's application instance. So if c:\myapplication.exe\a.vi dynamically calls c:\myapplication.exe\b.vi it will work but if c:\foo.exe\d.vi tries to dynamically call c:\myapplication.exe\b.vi it won't work. The reason is sort of related to the Application Instances that Michael referenced, in that c:\myapplication.exe\* is a valid directory for VIs that are in the Application Instance created when c:\myapplication.exe is run, but more that .exes are no longer essentially .llbs (at least on Windows, the didn't change on Mac or Linux). So what do you do about this change of functionality? There are a couple of choices I see: 1. You are basically treating these VIs as exported VIs. So one option would be to create a DLL out of them and have all your EXEs call that DLL. This would make your executable code more modular and is probably the best design choice of these solutions and maybe the least work. 2. Another would be to configure the EXE build specification to have these VIs reside outside of the EXE in a folder or LLB next to the EXE. The problem I see here is making sure all the subVIs the VI you are calling needs are not in the .exe otherwise they won't be found. The work here would be to keep up with the subVIs to make sure they are all outside the EXE. 3. A source distribution of the exported VIs would sort of be a combination of 1 & 2. It would provide DLL modularity, as you would call the exported functions dynamically and would be making the LLB I mentioned in 2 it's own build. Probably the same amount of work as #1. And since you are using LabVIEW to call the VIs, it probably makes more sense than #1 (DLL is best for C++ calling VIs) and would be my recommendation. 4. Enable the ActiveX interface for the EXE you are calling into and use the VI Server ActiveX interface to run the VI (Get a VI Reference, Set the Control Values, Run the VI, Get the Indicator Values), this is a lot of work for the caller of the function and a little for the build specification. 5. If you enable the VI Server for the application you could open an Application reference to that port on your local machine and then use Open VI Reference and call the VI as you did in the past. While it isn't much more work for the caller, you do have to keep your ports numbers straight and keep up with the right settings in the ini files for the EXEs. Alright I've typed enough, Kennon

They should be on the shelves at your local Best Buy, Target, etc. I haven't been to see the Powered by LabVIEW logo on the box yet, but I know some guys who have bought them at a local Target already. So if you need to bring one to NI Week you can stop and pick one up before you leave. I haven't heard anything about them being sold at NI Week, but I haven't asked either. Kennon