LabVIEW Idea Exchange

Idea:

So my idea is to add an optional parameter "ObjectRef" to both GObject methods "Replace" and "Replace No Attributes":

My request is mostly for replacing a control or a constant, but the proposed formalism could also work to replace any Node (SubVI, Structure, ...), a Diagram, a Panel, a Pane... by copying the properties and content of an existing one in memory.

Reasons:

Often in my scripting, I need to replace a control or a constant by copying an existing one. Most of the time, this is to change its data type, but also sometimes its style.

The current GObject methods "Replace" and "Replace No Attributes" are very handy to replace a control or a constant while maintaining their links to the other objects on the diagram, provided that you have the path to an existing (saved) .ctl file to give as a parameter to the method.

If the data type is not a type definition or is an unsaved type definition, things get complicated. This can happen and I don't have control over the data types passed to my tool.

To achieve this, I found 2 techniques:

1. Replace by a temporary Control file:

  - Create a new VI of type "Control VI";

  - Drop a new control using VI methods "Create from Data Type" or "Create from Reference";

  - Save the .ctl file to a temporary path;

  - Use method GObject.Replace with parameter "Path" on the old control / constant .

This works in most cases except when the data type contains out-of-scope typedefs. I can then work around this by disconnecting the typedefs and replacing sub-elements by path as a post-process, unless some typedefs are not saved by the user...

2. Recode the Replace method from scratch:

  - Drop a new control / constant using VI methods "Create from Data Type" or "Create from Reference";

  - Copy all relevant properties from the old control / constant to the new one;

  - Reconnected its terminal to the wire on the block diagram if needed;

  - For a control, relink locals, linked properties nodes, linked method nodes, references;

  - For a control, reassign it to the connector pane if needed...

  - ...

  - Delete the old control / constant.

This is a lot of work, seems quite inefficient and also is not future proof in case new properties are added to controls.

Regards,

Raphaël.

Idea: The Assert Structural Type Match node should be growable (able to expand the number of inputs downwards and/or upwards). This would be similar to how many well-loved nodes can be "grown" downwards or upwards, such as Build Array, Concatenate Strings, Index Array, Merge Errors, etc.

The following screenshot shows a real-world VIM that I created where I would have benefited from this feature. I needed to ensure that three inputs were all of the same data type. This required using two Assert Structural Type Match nodes. It would be possible to use a single node with three inputs if this idea was implemented. This would result in fewer wires and fewer objects on the block diagram.

Many of us using graphical programming for scientific applications, where we dealing with numbers, measurements, etc.

How often we grab to Windows Calculator to compute simple equations?

What about ability to enter something like 3,75*2,8 into any constant or control (in principle everywhere where we can put numbers) and then get computation result in this place:

In the past I've worked in desktop publishing industry and using the software called "Macromedia Freehand MX", and that was really "killer feature", which saves huge amount of time.

This is how it works:

Or for example, 5 rotated copies:

Even in Color mixer simple computations are allowed:

Everywhere where I can put some numbers, in any dialog:

So, my suggestion to have the same in every numeric control or constant.

This is what I mean:

So, it should be allowed to enter here something like "3*5" or "42+3*5" 

As MVP suggested to have the only (at least) base operations *, /, +, -, also combined as shown above, but may be "advanced" support (like fully offered by Formula String) is also not so bad, why not:

Anyway it should work everywhere, including constants on the Block Diagrams:

Also, for example, on Resize Objects Dialog:

Or even in the Settings (in general everywhere for any numeric field across whole LabVIEW):

And also in Run-Time, of course, not only in Development Environment.

If you think that "always enabled" feature will be annoying, then I can suggest to make this optionally per Control/Constant Option:

Or may be as global setting in the Options.

I am making ever more webservices with labview, but I feel I have little control over the server. It can happpen that a webservice becomes unreachable. Sometimes I would be a crashed webservice application, sometimes it is the NI webserver. But no tools available to find out. I can imagine the following tools in the NI webserver API

- start/stop server

- disable/enable server

- enumerate active webservices

- start/stop or enable/disbale webservices

- redirect domain root endpoint to webservice

- set favicon

- some proxy options would be nice to redirect a domain to a specific webservice

Notes

• Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
• Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
• This idea is somewhat related to the following idea: "Show node names when dropped" option

Using "Edit Palette Set" is cumbersome and painstaking.

Specific use case example:   I create a class library that has an embedded menu file that I want to distribute as a compiled packed library (PPL) or even as a source code distribution for re use by other developers.     To make the mnu available in the functions palette, you have to manually recreate the menu file to link to the versions of the functions inside the distributed functions, which is painstaking for a larger library.

It would  really nice if we had the ability to generate or easily edit mnu files.  In the example, a simple search and replace of the paths that the functions in the palette link to would work