LabVIEW Idea Exchange

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

Hi,

I have several Labview versions, and some files are in 2010, others in 2011.

I often work with both version launched, and when I want to open a file, I have to do File=>Open and choose the file (with the good Labview version). Opening a 2010 file with both version 2010 and 2011 launched open my file with 2011, whereas it has been saved in 2010... (maybe a bug ?)

I would appreciate if I could drag and drop the file I want to open on the LV icon on taskbar (+1000 to the following idea : here)

Best regards,

The addition (in 2013) of the ability to use tags in the directory names of the builders struck me as really useful - normally I build to a ...\MYPROJ\... set of directories (each of the ) then rename ..\MYPROJ\... to ...\MYPROJ x.x.x.x\.... as required. When I read of the ability to use [VersionNumber] and [ProductVersion] tags I thought wahooh - at last an automated mechanism. However when I played with the tags it became clear that each builder (app; Installer; Source) used its own version and did not have access to any other builds' version info. Hence I could not use a single version in all builders. Especially as the Product version is one digit shorter than the others.

Given the principle that the builds now accept tags (akin to macros in my opinion) it would be really useful to have a global version tag (that could be set automatically or manually as present versions) accessible from all builders  in a project for use in directory name creation and ---- to go even further ---- to have this global version available from inside the project VIs so I can use it in my window titles and About boxes (I currently use App Info VIs to get a version, date etc to do this).

Everybody else is doing it ( Microsoft, Adobe, ... ).<br>You pay $100 a month and you get access to ALL NI software products, period. You also get access to all the older versions ( clients rarely use the latest version ). Remember the KISS principle ( Keep It Simple and Straightforward ). I keep getting resistance on this idea fron NI folks. Please forward this idea to the NI CEO for consideration. <br>Thank you

Hello forum

 

Wouldn't it be nice if we can add W10 IoT Enterprise PCs as Embedded Targets, where we can create VI executable and set it as startup programs and once deployed, the target will be automatically configured to: launch the startup programs with Embedded Enabling Features (EEF), Enhanced Write Filter (EWF), Hibernate Once, Resume Many (HORM) and File Based Write Filter (FBWF) but on different volume; as presented in NI Week TS2361 & TS8562 slides.

 

Thanks

Is it just me, or does the "progress bar" (that actually doesn't show a % progress -- it's a mystery) create optical illusions (and especially when it's animated)?  It kind of makes me dizzy to look at.

 

2013-04-18_10-47-26.png

Currently the only want to back up an entire lvproj and all the vis is with Save to Previous Version. Otherwise you need to create a source distribution or zip file for each system (my computer, crio, FPGA). Could we add a project build spec that would allow you preserve the project structure like in Save to Previous Version but allow you to customize the output folders to help users reorganize their projects when moving from computer to computer. 

 

It could feel very similar to a source distrbution but for the entire project. So any dependencies are also pulled for their respective 

 

Ideally everyone would have they project nicely organized in a folder with perfect subfolders but when you're given a project written by someone else, sometimes files are scattered everywhere and we end up missing dependencies when moving. 

 

project build spec.jpgBuild Spec.jpg

When creating an Installer for a Labview project, make it possible to execute not only exe files after installation. It shoult be also possible to execute *.reg or *.bat or other files.

 

This should work for the two options on the Advanced page of the Installer property dialog:

Installer Registry - Run executable.png

hello forum

 

what do you think about a "feature" where developers can enforce version control on applications deployed into end-user systems? it may sound something like some feature of a certain OS, but it may be beneficial in a way or two...

 

the most obvious being for version enforcement, some members may not like this, but often time newer versions of application are developed to address certain issues of the previous version, and it would be pointless if the end user kept sticking to the old version for certain feature they may have grown to like

 

it can also be extended to subscription based or trial version deployments, a more friendly way for developers to present their systems for customers for in-situ system trial

 

one way to deploy this feature, is to minimally trace the execution instances of the RTE in deployed systems, across newer and older version, log them for follow-up actions, that can range from friendly popup reminders for update to application execution prevention.

 

what do you think?

Hi,

      We know there are lot of posts in Version Conversion Board  for conversion of VIs and DLLs from one version to the other.In other programing languages like .net we can see the 'VERSION CONVERSION WIZARD'.Using that we can easily convert from one version to the other.Why there is no such conversion wizards in labview?It will be very helpful.Is there any problems for creating a conversion Wizard?

I strongly forwarding the idea of a version conversion wizard.

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.

Hi

 

I'm about to upgrade from LV8.2.1 to LV2013 and then there is a lot of unsupported properties and methods in the new version.

It would be very nice to have the possibility to find those unsupported stuff.

 

Actually NI seems to need that function too. smileywink:

Take a look at this thread I made a while ago.

"http://forums.ni.com/t5/LabVIEW/how-to-find-unsupported-methods-2Fproperties/m-p/3032045#M865373"

 

regards Bjarne

Download All

Currently you cannot perform a binary compare on two 'identical' exe's or installer builds. We need a way for our configuration management folks to build an exe per instructions and verify it is the same as what I built. But there are differences in the binary files due to time stamps and other things. Does anyone else need this functionality?

Hi,

 

Today LabVIEW 2010 has the option "Save for previous version" because it upgrades automatically the VI to the current LV version (this happens since I use LabVIEW).

 

This behavior may cause headache when you are working with different projects that uses different versions of LabVIEW. If your last used version was LV 2010 and you double click a LV 2009 VI, it will be saved as LV 2010 VI and your LV 2009 project will crash.

 

My suggestion is, change the default behavior by keeping the current VI LabVIEW version and provide an option to upgrade to the new version.

 

Doing this everybody will be able to work with LV 2009 projects in LV 2012 without have LabVIEW 2009, 2010, 2011 and 2012 installed in the same computer.

 

Cheers,

As of now, a Tab Control Page can be colored via Tab Control and Page property nodes. It would be nice if Tab Control Page Label can be colored, sized, and styled using Property Node. This feature should be incorporated in the future release of LabVIEW.

 

Right now in labVIEW the plots can be exported into excel and can be saved into different  image formats (*.png,*.jpeg,*.eps,etc,.). In addition to the other properties it would really a very cool and excellent option to save the plot data as a LabVIEW figure with an extension "vifig" (*.vifig). The idea here is when the  plot is saved as LabVIEW figure the tester with the help of an interactive tool or some thing like this reload the *.vifig to view, change the graphic object properties , maipulate legend, xaxis label, yaxis label so on... and finally save.

 

Let's assume a situation where the user wants to analyse the data (zoom in, zoom out, find delay etc.,) and change few properties the the data who doesn't know LabVIEW and he needs to use another programs like origin, excel etc. This could be done very easily witht he help of an interactive tool. Unlike LabVIEW, the softwares like MATLAB, Origin has such a pretty useful option. 

 

Thank you.

The Windows 7 file permissions in the Program Files directory are causing a lot of headaches, especially with *.ini files of existing applications. It would be nice if LabVIEW had an option where install file paths of these files could be set based on the system they are going on. For instance, if the installer is being run on Windows XP, the installer will know to put the ini files in <Program Files>\<App Name>\Config but on Windows 7 install the files to <User>\Local Settings\... or whatever we choose.

 

Right now it seems our only option is to build 2 installers and have a batch file decide which to run. Unless, of course, someone can tell me otherwise.

Problem:

As much bug as suggestion, but since it's been this way for a bunch of years i assume it's a "feature"

 

I just had a project in which i defined some DAQmx tasks in the project, but in order to get them installed on the target i need to:

1. Export the tasks from the project

2. Select import MAX tasks in the installer which starts and forces me to run a new export.

3. Re-export the tasks from the project to overwrite the max export ...

(yes i could have skipped step 1 had i known the cumbersome mess)

 

Why cant i simply select a configuration file to include in the installer?

Why cant i select/choose tasks defined in the project?

 

If i want to avoid the exporter i need to edit the project xml, that's not acceptable.

 

Solution:

Allow to simply select a configuration file to include in the installer

Allow select/choose tasks defined in the project

 

/Y

Hello,

 

I have recently installed a new PC under Windows seven with the complete 2010 developer suite ...

On this PC i have to run an old CVI application which use traditional Daq ... and it don't work for known compatibility reasons !

But i get this information after many web searches and NI support investigations ... 

 

It should be nice to add a compatibility icon in the developer suite and device driver installers, in order to view the compatibility of each product to install.

 

It should be a way to rapidly know if a product will work or not, or will perhaps work with no garanties ... on a specified Operating system.

The icon should be something similar with a traffic light : Green => The product is OK, Orange => The compatibility is hazardous, Red => No compatible at all ! 

 

Manu.net

 

 

Yes, this is a corner case, but it has bitten more than once.  There's no way to deactivate then reactivate third-party plugin licenses for off-line (No internet) LabView development machines.  These machines need upgrading and they fail just as often as internet connected machines, yet third party plug-ins are often left in limbo when the computer ID's change.

 

NI should recommend and support third party deactivation for off-line machines (EX: https://support.softwarekey.com/index.php?/Knowledgebase/Article/View/28/54/how-do-i-know-my-client-entered-the-trigger-code-to-deactivate-his-computer) via softwarekey.ni.com.

 

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.