LabVIEW Idea Exchange

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

Please implement a way to generate reports in ODF (native format of OpenOffice) as it is a file format everybody can read (.doc is not because you must buy Microsoft software).

 

 

If you do that, programmers will automatically be able to generate PDF because OpenOffice has a dos command to convert any ODF document to PDF.

I know we have some ways to personalize the Getting Started window but to my taste, it's not enough!

What exists right now could be integrated into a SubPanel to keep the same functionality and that would also let anyone make it's own little plugin into this windows.

 

Here's a little example :

 

gsw.PNG

It would be nice that if a VI documentation set is created into HTML with PNG as picture format a snippet option would be included.

This option would embed a VI snippet of the top-level BD inside the PNG instead of a static image.

This way it's possible to distribute the code inisde the documentation.

 

 

 

Currently it's only possible to have drag and drop events for files on a path control.

 

It would be usefull if we could have drag and drop events for files on any control.

This way simpler GUI can be build with a very nice user experience.

 

Ton

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 you’re making a By Reference LabVIEW Object using a Data Value References (DVRs) the user of your class would need to embed each Dynamic Dispatching VI inside an In Place Element Structure (IPE). Or you have to create wrapper VI for each method but this undermines the advantages of LVOOP Inheritance.
 
The idea is that a DVR containing a LabVIEW Object wired to a Dynamic Dispatching Terminal is equal to calling the Method VI inside the IPE structure like illustrated below.

DVR DynamicDispatch.PNG

Message Edited by Support on 01-15-2010 04:39 PM
My mouse (Logitech) has a scroll wheel that also has the Left & Right scroll ability.  Labview does not natively support.  why?

The current implementation of the integrated SCC options have an option to exclude (or ignore) vi.lib and instr.lib files.

Mysterically user.lib cannot be excluded!

This ought to be fixed.

 

Ton

If an XControl is placed inside user.lib this XControl is not added to the palette.

 

This means that if you distribute an xcontrol you need to send a mnu file with the xcontrol which adds another folder inside the user.lib palette.

 

I think that an Xcontrol should be indexed like standard controls.

 

Add cmd line parameter to LVCompare.exe which would contain the file name for an image file.  If the image file name exists in the cmd line parameter, create an image file that contains all of the differences between the two vi's.  The images would be the same via LVCompare.exe, when stepping through the differences and doing an equivalent print screen.  It would be nice to automate the process of documenting the differences between two vi'.
Message Edited by Laura F. on 12-17-2009 08:38 AM

Creation of a VBScript Node, similar to the MathScript Node, allowing to run a VBScript.

The Lego NXT software release (not toolkit) is a wonderful interactive environment, that should be provided as an add-on application

on its own, call it "block application builder".  I see many useful applications in a variety of different industries where businesses wish to extend to their customers interactive and intuitive interface that they can program in their desired configuration of the product's behavior according to their own use cases.

 

That means we need an environment where we can prepackage blocks that is functionally specific to their applications, with ability to sequence them, run them in parallel, add conditional runs, and iterative loops. The blocks themselves could be computational in nature, or additionally provide user interface popups for interrogating the user, and have access to the full range of Labview functionality. Each block properties settings can appear as front panel settings for user to customize the behavior of that block. This is exactly how the

Log mindstorm software was configured, except we ask that you extend the availability of that functionality for the general users to develop their own intuitive applications using the same environment framework design. This application can target building the customer created sequence of operations as a windows .exe or .dll. We also would like to customize the menus in the application. In other  words, make the Lego mindstorm application a generic template for us to develop our own applications with similar intuitive framework.

Just like LabVIEW 2009 introduced Custom User Hooks for Data Member Access and Override VI LVOOP templates....

 

I would like Custom User Hooks for Dynamic Dispatch and Static Dispatch LVOOP templates as well.

Message Edited by jg-code on 11-26-2009 02:26 AM

When you want to find out where exactly a control is located on a computer screen (for some dark reason), there is a method for Panes called 'Convert Pane coordinates to Panel coordinates'.

 

However there is no easy way to get the owning pane of a control!

The propery 'Owner' of a control always returns the actual VI, not the pane.

GetScreenCoordinates.png

 

Ton

This post

Has gotten me thinking about how to handle preserving a memory location for external data updates.  @009 has much better memory management- couldn't a Preserve Memory primitive be written? For obvious reasons a counterpart Deallocate would need to be required for each "Preserve" call

 

hmm2.PNG

I hope LabVIEW wishes to become the next-generation all-purpose programming language that will be used all over the world in all industries.

 

.NET and Java are the dominant Technologies in almost the entire world.  With the introduction of the ability to create a .NET Interop Assembly with LabVIEW 2009, I was very excited because I thought that now I could go back to several former employers and make a convincing argument for them to use LabVIEW.... But then I realized,  yes, I can now expose my code written in LabVIEW to .NET applications, but my code cannot do many things which are standard in those worlds.  For example:

 

I can create a .NET Assembly, but I cannot:

  • inherit .NET classes
  • use generic .NET classes
  • create.NET classes that use generics
  • implement .NET interfaces
  • expose a LabVIEW event to a .NET caller
  • expose a LabVIEW class to a .NET caller 
  • cannot create Office Plugins, or any other Plugin that requires me to implement an interface

 

i.e. almost every single financial institution has an in-house developer that creates various Excel Plug-Ins and Add-Ins, LabVIEW cannot be used to create such a product because LabVIEW cannot inherit from and implement the IDispatcher interface.

 

The CLI - Common Language Infrastructure is an open specification developed by Microsoft tha

 

It allows anybody to create a programming language that creates fully compliant .NET code.  There are 3rd parties that have created products such as ActivePerl and ActivePython, which allow developers to use Perl and Python (and even COBOL!) to create .NET compliant code.  My vision is for LabVIEW to do the same, so that now every single organization in the world that uses any .NET language can also consider using LabVIEW, without having to run into many issues along the way.  Only with full .NET compliance will random worldwide organizations consider writing a portion of there software in LabVIEW before hopefully moving entire projects onto LabVIEW!

Message Edited by John80 on 09-03-2009 01:49 PM

Would like to target Labview embedded on a host of platforms. Specifically x86, lynuxworks, Vxworks and xilinx platforms - boards, SBCs, COMs, stacks, PC/104... Like PXI, the way to get the users onboard is to show that the industry supports this direction and you are not tied to one vendor. It would be expensive if in an iterative learning process (necessary but collaboration is also necessary with well established & matured platforms/standards) the users one chosen platform vanishes (maybe like fieldpoint?). Packaging options is also very important to achieve something like Adlink's MilSystem 800 that the application demands.

 

Pavan Bathla

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:

 

Subversion is one of the most popular SCC systems in use yet currently LabVIEW can only integrate with the help of rather flakey 3rd party plugins. It would be so much easier if LabVIEW included native SubVersion support, allowing full integration with the LabVIEW Project etc.

Title says it all really.

 

Openoffice is cross-platform and free.  All good points.

 

Please?

 

Shane.