LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Add an  option in the installer build to run cleanup-programs during uninstall.

 

On the advanced tab in the Installer build there is an option called: "Run executable at end of installation", but there is no such option for the deinstallation.

 

We use the existing option to run a batch file that installs and starts the application as a service. If the user decides to uninstall the application we would like to run another batch file to stop and deinstall  the service - but there is no option to run an executable during deinstallation.

The list of available destinations when you build an installer includes Common App Data Folder, but not Personal App Data. So instead of being able to just install an initial set of settings during installation we always need to hard-code the creation of those files.

 

It would be conventient if PersonalAppData was available as a destination as well - or even better; that the options included *all* the OS's standard folder references. Or that you could at least create new references to such system folders.

One thing prevent our company to upgrade to newer labview is that the run-time engine gets too big. Even I really like the features in later version, I still have to save the files back to 7.1 then to 7.0 to build application installer. Under 7.0, the run-time engine is very small, and the installer is less than 10MB and I can easily email the program to customers. In version 8.0, the run-time engine is 65MB and now the latest version is well above 100MB.

 

What I would like to see is that application builder get smart, only pick what is needed and build slim app.

We need the ability to manage multiple volume licenses from a single VLM instance.  We have several groups from different cost centers that use LV; however, currently all the license administration falls on me.  The only solutions available at this time are:

  1. Merge all the licensing needs from each group into a single license.  This is a nightmare for me.  For one, our internal accounting system isn't set up to easily transfer funds between cost centers, so getting the money to pay for the license has been difficult and usually leads to payment delays.  Second, it's very difficult to respond to changing license requirements of an individual group when everything is lumped into a single license file.  If a single group wants to discontinue their subscription, rather than just letting the subscription expire (which would cancel the subscription for all groups) they have to pay a fee to "break out" their licenses from the volume license.  If a group wants to add products to their license, all requests get funnelled through me.  This might be good for NI, but it's a royal PITA for me.  (License administration is something I do in my "spare" time.)  Third, it's inconvenient having to track how many licenses of each type each group has purchased and cross check that against how many licenses they are using.
  2. Maintain separate computers for each VLA.  From an ease-of-use perspective this is almost as bad as option 1.  From a practical perspective this is worse than option 1.  It's silly to have several different computers sitting around doing nothing other than running a license server.  Furthermore, it's harder to loan an available license from one group to another group (which does sometimes happen) as the user has to redirect to a new license server.

Neither of these solutions work very well.  I don't mind the license administration part of the job.  Creating installers, changing permissions, and stuff like that doesn't really take that much time.  What is killing me is the account administration part of the job.  The single license model forces me to be an account administrator for several independent groups, and the corporate culture and infrastructure here don't support that model very well at all.  What I would like to be able to do is have each group be responsible for purchasing and maintaining their own volume license agreements.  When they get the license file they can send it to me and I'll install it in the VLM.

 

I envision each VLA having it's own root node in the tree diagram.  Instead of a single "Volume Licenses" node, there would be one for "Group A Licenses," another for "Group B Licenses," etc.  (I have to be able to rename or annotate the root node for each VLA.)  The Users and Computers nodes still contain the users and computers from all the groups, but maybe those nodes have virtual directories I can use to organize them.

This is only a wish that NI could provide a Utility that converts a VI or Dir to Up or Down.

I had a project that was done in LabVIEW 5 (done many years ago by someone else); I couldn’t open in LabVIEW 8.6. I needed to do stage upgrade LabVIEW 7 and follow up with LabVIEW 8.6 and so on.

I understand there are cases that you can not simply down convert, because newer function may not be available in older version. In this case it OK, give user an option for force the convert and worse case the down convert VI is broken. Let the programmer fix it!

The utility should have a Status Report for convention.

Please..!

The title says it all - I'd like to have the option to inherit my configuration settings from the previous LabVIEW installation (or from a specified path).  Currently I have to do this manually by copying the ini file from the previous version, but I'm never sure whether there will be compatibility issues with the new version of LabVIEW or if there are obsolete settings.  The installer should check for compatibility/obsolescence issues as it creates the new ini file.

 

Alternatively / additionally, I'd like to be able to specify where LabVIEW loads the LabVIEW.ini file from (which could be located on a network or USB disk).

Currently, mass-compiling runs into problems with subversion files in "_svn" directories (files called X.vi.svn-base).  There should be a setting to exclude these directories.

Microsoft introduced a number of restrictions in Vista that makes it more difficult to save program settings and temporary files.

 

Applications can no longer write to the Program Files directory, but even worse; the common application data directories, like ProgramData and Users\Default  are by default only accessible for writes by administrators and the first user that did the write. Sessions by other users only have read access. The same goes for registry access; the computer keys can not be written by everyone.

 

As long as it is OK to not share settings between user's you have one good option left; the user's appdata folder. If you do need to share data though - you need to set the access right of the folders you create in the "common" directories. This can currently be achieved e.g. by using a tool like SetACL, however as it has been made a required action now, it should be included in the installer - AND preferably also as VIs on the file and registry (for registry access) palettes.

 

LabVIEW 2009 introduced one of the tools required to handle the UAC changes - a VI to get the paths of system folders. It should also have a tool to grant access to some of those paths...

When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon).  What I'd like to see is a solution that treats 3rd party installers as first class citizens.  I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.

 

2-3-2010 1-35-27 PM.png

 

This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.

 

2-3-2010 1-41-08 PM.png

 

When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run.  This is a pretty simple scheme that would really simplify the process for end users.

 

I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas.  I'd love to hear your comments.

When installing a new version of LabVIEW, I always find myself resetting all of the options I previously changed from the default settings in the Tools -> Options menu. This means I have to spend my time remembering what options I changed and where in the Options menu I need to change them. It would be nice if a newer installation of LabVIEW looked at the older version's Options settings and then applied those settings to the new installation.

 

The same idea applies to how I configure the palettes on the block diagram. It would be nice if newer installations looked at how I configure my palettes and then set them up the same way. 

 

With these changes transitioning to a newer version of LabVIEW might be even more seamless for users that change their settings from the default settings. 

For example:

1) install based on a license: this would install only the software related to a license;

2) reinstall/update based on license OR based on what's already installed.

 

For every new update of LabView I need to select the installation  of the toolkits I want, why not make it faster?

It would be very nice if we could tell the installer script to synchronize its version number with the version number of a specific executable.

 

12-29-2009 2-38-53 PM.png

 

Additionally, it would be very nice to have this version information (once they are synchronized) displayed on the installer wizard (for instance in the title window or on the wizard first page).

 

PJM

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

 

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

It would be nice if LabVIEW automatically check for updates and notifies the user of all of the upgrades available for everything that they have registered. It would be nice if patches were just down loaded and installed much like the Windows Updater function. It would keep LabVIEW, all of the tool kits, Measurement and Automation Explorer, and every licensed software up to date. It could also push down labview as long as you are on the subscription and current.
Builder should automatically attach version of LV to EXE so it can be seen in Windows Explorer. So you can always ask unexperienced end user about version. I drove 1000 km with wrong version of LV on my laptop... Upgrade to new version is not always straitforward... And I always forget to set version information manualy...

For modern application development we need better methods to detect wheter our application is called to open a file.

Currently the only help NI gives is based on command line parameters. And we need to jump through loops to get it working to react on opening a file when the program allready runs.

 

This is a major showstopper in creating professional applications.

 

LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.

 

 

I haven't checked out LV2009 on Mac yet, so please let me know if this has already changed.....

 

When creating an installer on Windows, we have control of everything within the Project.  Cereate EXE, then create Installer with all options within the project.

 

On the Mac we have the options for the Application but not for the installer.  I know (After I spent a day looking for products) that Apple has an installer packager which ships with the OS (On the developer CD) but why can't we automate this from within the Project shell?  As it is I need to create the Application, then switch to an external program, create the installer (luckily it's relativel easy o use) and then to finish things off go to ANOTHER pogram to create the dmg file.

 

Please give the Mac the same Installer creation options as Windows.

 

Shane.

Dealing with fonts in LabVIEW can be a nightmare due to the variations in fonts, types of fonts, rendering variations, resizing, etc.  If you are deploying a LabVIEW application on another machine, frequently the fonts or settings on the target machine don't match; creating a very ugly looking panel.

 

When developing for Windows in the past I have always edited my LabVIEW.ini file  to include the following:

 

appFont="MS Sans Serif" 13
dialogFont="MS Sans Serif" 13
systemFont="MS Sans Serif" 13

 

And when deploying an application; I include these in the app's ini file also.

 

This seems to work for most windows targets since MS Sans Serif appears to be a common font.  I suspect this will produce unpredictable results in OSX or Vista for that matter.

 

What I expect as a developer is not having to deal with these font issues.  I expect that when I develop an application that it has the same look and functionality; regardless of where it is deployed; even as a VI being edited on another machine with different font settings.  This means that the font information must be encoded and stored with the VI itself.  I would expect that both the LabVIEW editor and run-time engine would be able to recognize detailed font encoding within the VI and adjust the display accordingly based on the local machines font capabilities.  This is what one expects when printing or viewing an Adobe Acrobat PDF file; and the behavior of LabVIEW code; particularly since it is so graphical in nature; should also be similar.  I wouldn't expect that the actual font bitmaps be stored within the VI itself; but some detailed metrics about the font should be; height, width, kerning, etc.  Thus if a font substitution takes place when being deployed on another machine; at least the text will occupy the exact same extents as the original.

 

Though I don't know exactly what the detailed implementation would be; it does need to be transparent to the LabVIEW programmer, i.e. zero code; zero hassle; zero worries.  It should just work.  I hope we can all agree on this.

We are getting into trouble with all these run-time engine updates! Every time a new release or service pack come out we have to create a new installer with the new run-time engine and send it out onto all our customer's machines. It is not convenient to develop in 20 different versions of Labview and we like to keep our executables and updates recent.

 

Our instruments run on XPe with very little extra room for an additional RTE every 6 months. Asking the customer to uninstall old RTEs is painful as they are not supposed to go that deep inot our XPe build. 

 

I would like to see a modularized run-time engine where we don't need to update the whole thing every release. I know  with .NET updates are only necessary in 3-5 year increments. That would be much more acceptable IMHO:smileyhappy:

 

As outlined in a post in the NI forums HERE, and seeing as I'm currently being forced to re-install several LV versions on my Laptop (Have been doing so since yesterday!) I want to re-iterate my affinity for having LV installed in a Virtual PC.

 

Memory problems, Hard disk crashes, Virii, stupid user: there are many reasons why an OS would need to be re-installed.  In my case it happens that my HDD was on its way out.  I think this may be linked to many crashes I have been experiencing over the last 8-9 months.  I am nor re-installing ALL of my LV versions.  This is a major pain in the tuchas.  I have backups, but I would rather re-install since I don't know when the data corruption started.

 

Being a nice law-abiding citizen (or a sucker, depends on who you ask) I don't want to violate NI's EULA by installing each LV Version (Ideally each quarterly update)on a separate VM.  This violates rather quickly the "install on 3 PCs rule").

 

Please please let us install on many Virtual PCs as long as they are not distributed amongst other users.....

 

Did I say PLEASE?

 

Shane