LabVIEW Idea Exchange

The label should be hidden as standard on This VI referrence as it gives no extra information, it only clutters the block diagram.

/Y

OpenOffice last version was released 5 years ago. One of the best suites that continued the work is LibreOffice, developed by The Document Foundation. NI has a add-in for OpenOffice, but not yet for LibreOffice.

 

Please update the Integrating TDMS in Third-Party Products page adding support for LibreOffice, Apache OpenOffice, Calligra Suite, NeoOffice, etc.

Modify the default behavior of modal VIs to preclude them from becoming modal until the VI is actually executing, as opposed to the current behavior of becoming modal as soon as the vi is reserved for execution.

 

This prevents modal front panels that are left open during debugging from jumping to the front as soon as the top level calling VI is run, necessitating workarounds like killing LabVIEW via the task manager, the use of custom "Abort" VIs, or setting the modal property programmatically.

 

This idea is essentially a mutation of this one: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-option-for-window-modality/idi-p/2598027

 

Important disclaimer: I am sorry, this is not my original idea, because it is (together with many other nice features!) already implemented in the LabVIEW UI builder. Credits go to the relevant NI developers.

 

This Idea posted here tries to see how much interest there is in such a feature and to show support that we want this also implemented in plain old LabVIEW. Personally, I really like it! 🙂

 

(It is also somewhat related to this idea (but probably not a true duplicate), especially my comment there already exapands on the idea!)

 

The Unused Items Tray (see also e.g. Christina's Blog entry) is an area on the diagram that contains terminals or FP objects that have not yet been manually placed or are currently only "used" on the BD "xor" FP, i.e. not on both.

 

The current problem in LabVIEW is that if you place a new control on a complicated VI, the terminal will end up on some random place, typically piled well camouflaged on top of some other diagram structures and possible a scroll away from where it is actually needed. Similarly, if we create a control or indicator from a terminal on the diagram, the control will typically be outside the carefully placed visible area and there is no way to grab it without first messing up the FP alignment by either scrolling or enlarging the window.

 

In all these cases, it would be nice if the objects on the "other" window would land in a predictable reserved floating location for quick and easy manual placement where they belong. During development, there are probably a few terminals that are not yet used or connected, and we should be able to place them back into the unused items tray of the diagram so they never scroll out of view or get misplaced.

 

On the front panel, we might have some spare controls "parked", and they would not show in run mode at all. This could even be abused for "local variable zombies" (=hidden controls with the sole purpose of making a local variable) along these lines, which might be OK (=better than hidden controls!). Front panel items in this tray would look like their palette entries. We don't want e.g. full-sized graphs in there!

 

Now, how should all this look like? In order not to cover valuable diagram space, it should be something that collapses to near nothing when not used and would only expand to show the current contents when hovering or clicking in a special area. Of course there should also be an option to pin it open. When minimized, it should look different when "not empty" vs. "empty".

 

Pop up on a subpanel control. There's an option for "Make Panel Transparent". When you enable that, the background of the panel is transparent and you can see controls/indicators underneath. The key word here is "see". You cannot click on those controls. The subpanel eats the mouse clicks. I talked about this with a couple people and could come up with no use case where you would want a transparent subpanel and not be able to click on the controls behind it. What I think the behavior should be is "if the mouse click hits a control in the subpanel, that control gets the click. If no control in the subpanel gets the click, the click falls through to the controls behind it, if any."

When searching for a single pattern we define the pattern as *.vi (for example). If we want to filter out say three patterns like (*.c, .h,*.txt). It doesnt work that way. In file dialog if we define these patterns seperated by semicolon it returns the desired result but in list folder we have to use a for loop for multiple pattern searches. Will it not be useful if we define (*c;*.h;*.txt) in the pattern and get only these files?

It would be absolutely helpfull if Graphs would have Annotation font properties like Labels  have on generic control.

 

 

New properties for Annotation in annotation List that could allow to change "test" text fonts attribute.

 

 

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. 

Sometimes you have to read a lot of shared, local or global variables in sequential order. In this case, it can be a bit "boring" having to drag all the variables by hand. In addition, if you are reading shared variables, you also have to wire all the error cluster inputs and outputs. It could be useful to implement something similar to a property node or a Read/Write Control FPGA Node that you can resize and select which variable must be read or written in each position of the node as you can see in the following image:

 

 

 

The proposal consists in being able to format the content of a string control, to allow to read more easily: INI, XML, HTML, ...

 

 

Regards.