LabVIEW Idea Exchange

When setting the option "Separate compiled code from source file" will make the .vi-file NOT to contain executable code.

The forum filter accepts .vi files to attach to posts. But if selecting VIs with this option set, the posting is declined with the remark that the file type is invalid.

I recommend updating the attachment filter to accept VI files with compiled code removed.

Norbert

Hello,

I often have to use report generation toolkit in order to generate EXCEL reports.

This is a very easy way to generate userfriendly test reports.

But, the API of the EXCEL report generation toolkit should be improved, in order to be abble to insert real Excel graphs in the excel sheets.

For the moment, when you want to insert a graph in Excel, this is done by inserting a MSChart object.

The problem is that a MSChart object is not an Excel graph !

There is no link between the data inserted into Excel and the MsChart graph object.

A MsChart object contain all the data necessary to draw the graph.

It should be interesting to had the ability to create real EXCEL graphs ... with a link betweend the data inserted in a sheet and the graph.

So it should be possible to have access to data modifications directly reflected on the EXCEL graphs.

Thanks a lot.

(And sorry for my approximate english)

Manu.net

whenever a change of .NET dll is introduced, LabVIEW kept wanting to use the old dll. The change in a 3rd Party dll caused a full blown LV crash... 

A simple Uninstall of the entry in C:\Windows\assembly did the trick.

This was not mentioned in the following:

https://decibel.ni.com/content/docs/DOC-5921

http://zone.ni.com/reference/en-XX/help/371361J-01/lvdialog/assemblies_in_memory/ (only talks about runtime, which is helpful when creating the distribution)

This is not obvious nor an easy to find solution. An ability to pick and choose within LV the required dll (and version) would be helpful.

Not so much a new idea as a request to maintain current functionality. LV2010 does not support importing of LabWindows/CVI function panel drivers, can we have it back ASAP please!

For more info see:

http://lumen.ni.com/nicif/us/gb_infolvinstdriver/content.xhtml

http://zone.ni.com/devzone/cda/tut/p/id/3164

Kevin Snelling

(CVI Certified, CLAD, Alliance Member)

I did a search on this forum to see if the subject been asked before but couldn't find it quickly, so I post. I have been seeing business push and pressure to move in this direction over the years, more so recently and have migrated to eclipse for my current project and like CDT. I saw the following today and it got me off my inertia to ask/feel the question here. I would venture that Operating systems and other mature s/w tools aren't rocket science anymore, but commodities and open-source w/ customization makes sense. Easier said that done. Thoughts?

pavan

This inspired me to ask the question:  The Eclipse Helios simultaneous release of 39 Eclipse projects and 33 million lines of code showcases the diversity and innovation going on inside the Eclipse ecosystem. In terms of statistics, the Helios release includes 33 million lines of code developed by about 500 Eclipse.org committers from 44 companies. The important thing to remember about Helios and Eclipse simultaneous releases in general is that even though it's a simultaneous release, it doesn't mean these projects are unified. Each project is a separate open source project within Eclipse.org, operating with its own project leadership, its own committers and its own development plan. The simultaneous-release concept is designed to provide a transparent and predictable development cycle.

Other ref:

Microsoft ups the ante in the robotics market, makes MSRDS free ... (see coments from emiliekopp)

CentOS, Ubuntu...

Eclipse & addons

Python

GCC

Octave

Scilab

Android (I think it is open?)

Open-office

ISO formats for docs

Open Car

Open prosthetics

...

The list goes on.

I have LabVIEW Classes of the same name in two separate LabVIEW Project Libraries (e.g. for namespacing reasons) in the same LabVIEW Project.
When I go to configure the Inheritance of the a Class, the All Class In Project list just shows the Class names.
These names can be the same and it is not immediately obvious which Class is the correct one.
The only way to pick the correct Class is by looking at the Selected Class Path on the right.

My idea is that the All Class In Project list will display the qualified names.

Either as one long name or nested, mimicking the LabVIEW Project hierarchy. 

(I think I currently prefer nested). 

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.

Similar ideas have already been posted but non of them totally hits what I'm missing.

As always - what is the current situation?:
- LabVIEW is installed under "C:\Program Files (x86)\..." - this is a folder where admin rights are usually required to modify it.

- in the named folder the standard VIs are included: vi.lib / user.lib / instr.lib

- my project lays somewhere else - e.g. "C:\myLVProjects\project1", "C:\myLVProjects\project2", ...

- my first project is LabVIEW32 bit, my second is LV64bit,
- one project needs to have the binary code separated from the VI, the other one not
- one projects needs some toolkits from the VI Package manager, the other one not or maybe even incompatible ones to the first project

- one project needs VIs from an additional search path, the other one too but with a different version

long story short:
There are many situations where the configurations of two or more projects conflict with each other. Therefore, switching between two projects can be quite effortful — from adjusting configurations to (de)installing toolkits.

What I like to propose is the following:
Having a new option in the LabVIEW start screen "Create a new development environment".
The only the user has to do is to select a folder on a drive with enough free space.
LabVIEW shall now setup an entire code- and configuration environment. Means it copies vi.lib, user.lib, instruments.lib to this folder. It create a LabVIEW.ini and a link to the exe using this INI. It creates a folder for the compiled object code cache and so on. Installing add-ons from VI package manager shall also be stored in this new folder structure.
And of course, there shall be a place where I can manually add some libraries, my project files and finally also my build results.
If LabVIEW is now started from the named link it only uses the VIs from the environment folder as long relative paths are used (which shall be default).

Again in short: I expect an encapsulated environment that contains everything that is needed to develop one project entirely independent from a second and third project.

When a third party add-on expires you get a dialog asking you to activate it, but the dialog does not offer you the option to remove it instead:

If would be nice to be able to select add-ons in the add-on list and then click a Remove/Uninstall button (and/or right-click). The current solution is to manually fire up the package manager and uninstall it from there (the remove button could alternatively (if needed /quicker to implement) call the package manager and tell it to start the removal of the selected packages.