LabVIEW Idea Exchange

Post an idea

The context menu for a file in the project window always contains the entry "properties" - but the dialog that stays behind is different between LabView-Files and non-LabView-Files. e.g. for a VI the VI property dialog opens, for a TXT-file the windows file-property opens. With other words: I can't open the windows file-property-dialog for LabView files.

I would suggest to have an menu entry "file properties" that opens always the windows file-property dialog. The current "property" entry can disappear for non-LabView files.

Remark: I'm using LV2011SP1

View All (6)

Hi All,

I've just been working with the histogram function, and as you can see it returns an error (but no error cluster....but I know thats another issue ;-)) if the Interval is wired at less than or equal to zero. I wanted to avoid this error so I quickly checked what the default was and wired my code so this was used when the input was set 'out of range'. Then I thought of an alternative way to do it - put the subVI in a case structure so that the false case is unwired....and therefore use default.

And then I thought perhaps I could suggest a third way - how about a 'constant' - called maybe [DEF] (which will adapt to the data-type of the SubVI input). This would save the user from using a case strucure or from looking up the default value for subVIs. An alternative (in some cases identical, in some not) option would be a [Do Not Update] constant.

I've thought of a few other places where this might be useful. For example I like to set my subVIs inputs to 'this connection is required'. However there are times when you would like to use the default values or the last used values. If this is the case you have to set your subVI inputs to recommended rather than required. I'd like to be able to wire up a [DEF] constant or a [Do Not Update] constant so I can have my cake and eat it too;-)

Similarly of you are updating a front-panel object from different cases (i.e. a state machine) and there is a case where you don't want the FP object updated I either wire up a shift register with the previous value or (if I'm lazy) use a local variable. With this idea just wire up the 'Do Not Update' constant and it wouldn't update the FP object.

Dave

What I'm doing:

What I'd like:

And to conclude let me quote a hero of mine:

De-fault! The two sweetest words in the English language.
-- Homer Simpson

Often error terminals aren't necessary for class data accessor VIs. We can create accessor VIs without error terminals but then we can't make them available through property nodes. We have to call these VIs explicitly on the BD.

It would be great if we could use Bundle/Unbundle instead:

Notive the small wrench on the Unbundle node. That means there's still an accessor VI for parentData behind the scenes. childData belongs to the current class so that's a mere unbundle operation. The BD readability has improved.

Say I have some inputs/outputs that are shared between a function block in the start of code block and a function block that is 15 code blocks away in the LV Code.. And there are multiple such sharings occuring, without an involvement of a tunnel.. Now there are wires everywhere.. Either we cluster them into one single line (which becomes uneasy sometimes) or some use local variables (when shared and updated at multiple locations it becomes dangerous)..

Instead, if we can go wireless..

Like a transmitter at the source and single or multiple recievers at the required spots..

When there is a tunnel to be placed..

The appearance and the presentability of this method can be made much better.. (like tiny dots or something similar to bundly by name but not these ugly circles.. ) Just wanted to convey the idea.. This can remove wires flowing unnecessarily and would make the code more readable and easy to modify..

I brought this up briefly in this idea...

I ocasionally find myself pressing enter to open a subVI that is selected on the block diagram. I think it'd be nice if this action actually worked.

I have since tracked down how I get myself into a situation where it's easier to click enter than double click the mouse...

From any VI I hit ctrl+shift+E to get me to the project.

I then type "main" to get me to Main.VI (this is when I leave my mouse)

I then press ctrl+r, which brings up the error window because some other vi is still broken.

I press enter to go to that subVI.

I press enter to open that subVI, and am stuck.

Since my request for separating namespace from library membership hasn't gone anywhere, I'll throw out a less disruptive idea: provide an option to group project items by namespace.

Often I have groups of vis or classes that are related to each other, but do not depend on each other. (For example, the LapDog message classes are logically related to each other, but not functionally related to each other.) Since grouping by namespace helps me understand the code, I typically put them all in the same library, even though they are not functionally linked.

The alternative is to name each message class according to its complete namespace (i.e. LapDog.Messaging.NativeMessages.StringMessage.lvclass) and skip the lvlib. Doing this means I lose the grouping feature in the dependencies tree. If there were an option to automatically group project items in a tree according to their namespace, I would get the benefit of grouping without incurring the overhead of library membership.

Currently LV includes the file extension as part of the namespace. I think that's fine identifying a specific vi. When grouping within the project window I don't think the extensions should be used. For example, a class method that is a member of a lvlib might have a fully qualified namespace of,

MyLib.lvlib:MyClass.lvclass:MyVi.vi

That vi should appear in the tree at the same place as a single vi with the filename,

MyLib.MyClass.MyOtherVi.vi.

(I really think Namespace should be a new tab in the project window like the Items and Files tabs, since it represents a different view of the project. However, that would probably be more work to implement so I'll pare down the request.)