LabVIEW Idea Exchange

The left data node in the VI Activation event should include a reference to the VI that was activated.

This event proves very useful as a workaround for other LV flaws--namely, that you can't register for FP control events before the FP is opened--so we often wait until a VI is activated before we attempt to register for generic control interaction events. But, since we don't actually have a reference to the VI, we have to use the VI name to obtain a reference. And then there is always the question of what "VI Name" will mean when dealing with namespaced (library member VI) or clone instances...

View All (3)

View All (5)

Currently the build specification name, the output filename and output path of the build is hard coded on the "information" page of the Build specification properties window.

It would be a HUGE help if optionally the version number from the "version information" page could be added to the build spec name / filename / path. Right now unless I continously change the filename and folder path the project explorer overwrites the existing build and just by looking to the file name I dont know which build is this exactly.

I have used Packed Project Libraries (PPLs) in a couple of smaller projects before with mixed amounts of success. Now I have read all of the caveats/pitfalls and I have a pretty good understanding of how they work (same application instance but under a different namespace) but my main problem still comes down to this: Passing class references into PPLs just breaks and causes me severe headaches.

Here is the situation...I pass everything I need into my plugin VI as a variant because within the PPL, you can do 'variant to data' and even if it is a type definition it will collect the correct reference which is valid in my application. This doesn't work for classes - the variant to data node complains because the data type does not match:

Error out 2 throws error 91 whilst the others are fine - even the user event which is based on a type definition in a library - QMH.lvlib:ctl_Msg.ctl.

The reason for this is that the variant passed in Class.lvclass and the data type it's trying to convert it to is Plugin.lvlibp:Class.lvclass. Apples != Oranges. The problem is that it IS the same class so I don't see why I should get an error here (because QMH.lvlib:ctl_Msg.ctl also becomes Plugin.lvlibp:QMH.lvlib:ctl_Msg.ctl, right?). If the type/class version/mutation in the PPL is incompatible with the main application instance then throw an error but if it's just because the namespace is different I want to be able to use that class in my PPL.

Can I please tell LabVIEW somehow that Plugin.lvlibp:Class.lvclass is actually Class.lvclass (including any classes used inside) so that I can use it inside my PPL with the same data space.

This sort of transfer mechanism between namespaces is already sort of possible with the 'Get Exported File Path' VI, so can I have a psuedo-equivalent for classes please?

I know I can build Class.lvclass and all of it's dependent classes into a 'shared' PPL but that would mean shipping my re-use library as a PPL and all sorts of other reasons (like not shipping vi.lib as PPLs).

I'm not actually sure what the solution would look like - there are far more intelligent people than me on here who can put forward some ideas of how to implement the idea - all I know is that I want to be able to pass my class into the PPL and have it work.

VI Analyzer seems like a really great tool but sometimes VI analyzer can't gauge the code intent and the author might have a legitimate reason for breaking the rules.

The current method of handling this is, for some tests, you can set a maximum number of allowances per VI, or, you can skip the test altogether for certain VIs. The problem with those methods is that they have the potential to hide legitimate issues and they don't document why a certain test was deselected.

I propose we add a way to document the issue (either in comments, labels, control documentation, etc) and have VI analyzer ignore or hide the authorized exceptions.

Example:

I tried to parse the output-file from the "Export Strings" function with the LabVIEW XML-Parsing function, but neither the standard (string) XML functions nor the VIs provided with the XML Parser Lib provide satisfying results.

For localisation and string manipulation in a VI it would be a great help, if this output file could be somehow parsed and processed with a (self written) LabVIEW Tool, but unfortunately it's realy hard to get the data into a structure for further processing in LabVIEW.

An alternative could be if LV exports the strings into an binary file, and NI provides a typedef to parse the data against.

View All (3)

I use LabVIEW OOP quite frequently and I like to have a small alignment grid on my FP and BD. With LabVIEW, you can set these in the LabVIEW options for when new VIs are created, except for when you use LabVIEW Classes and VIs are generated by scripting.

It would be terrific if there were a way to extend this functionality to OOP Class generated VIs. Currently, I have to go to the properties tab of each VI and change this manually.

Current settings when VI generated by LV Scripting in class. Have to change manually.

Would like an option to be able to set the Class generated VIs similar to the LabVIEW environment settings in "Options"

This is my preference, but it may vary, it would be great to have this setting to automatically generate new VIs with desired settings, instead of doing it manually in classes.

Thanks!

During debug following from one vi to the next and thus opening the diagram window tends to generate sometimes a
massive amount of windows (frontpanel and diagram)

One solution to this could be to place the diagram on the backside of the frontpanel, and to have a command to flop the window over.

During debug frontpanel is not of much interest but must still be there. This would reduce the number of windows to half.

Window size would be a problem; I suggest use the window size of the larger of the two.

View All (1)

I would like to see a few improvements to the BM:

parse only text fields that actually start with a # at position 0 (not displaying fields that have the # somewhere in the middle)
display tags case-insensitiv

I see that the actual work is done in the "Get VI Bookmarks" Invoke Node, thus it may not be trivial to add such features.

one related Idea deals with providing custom tag identifiers: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/bookmark-symbol-change-to-or-user-selected/idi-p/2976865

-Benjamin

Sometimes we create code, which is not reused elsewhere, but may be visually large or unpleasant (bad readability etc). Creating a file/subVI is not always the most elegant approach to solve this, but seems to be the only option.

It would be nice, to have the option to "Collapse" and "Expand" code parts (like some editors for textual programming have).

The example below may not candidate as visually large or unpleasant, but here goes...

We have some code.

And wants to collapse part of the code.

We mark/select the code part and right-click. From the menu, we select "Collapse".

The code we selected, collapses into some icon, without generating any files. It is purely visual.

If we want to edit or see the collapsed code, we double-click the icon, to open a new window containing the code.

If we want to return to the originally code view, we right-click the icon and select "Expand".

We now see our code in its originally form...

I think this option would be nice to have.

View All (10)

View All (5)

Writing good code typically involves spending a lot of time coding up error handling cases.

Dropping error cases around enumerated or string controlled cases is a common structure task.

This takes up quite a bit of diagram space and coding time when integrated over the entire job.

If an enumerated or string controlled case structure could have an optional terminal dedicated for the error data type only, this structure could be more efficient to code.

A typical implementation looks like this: