LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Unlike the capability to swap diagrams in regular case structures, the conditional case structure CANNOT swap diagrams. It would be nice if the conditional case structure could swap diagrams to avoid pulling out code from one case into another.

 

be able to choice the "minus sign" for the negative non-decimal numbers

 

            i'm only talking about the way that an indicator can display a number.

 

                                                  like this,

 

                     demo.png

 

minus.png

Background

The LabVIEW project window has two tabs: (1) Items (2) Files. The "Files" view is very useful to me as a quick check to make sure all subVIs are loaded from expected locations.

 

I am not aware of an equivalent view into the current Vi hierarchy if we don't use a LabVIEW Project. Maybe I haven't found it yet. 😉

 

Idea

My Idea is to have an optional window that show the current VI hierarchy in a layout very similar to the "Files" view of the LabVIEW project, even if we currently don't use a project.

 


 

(Image for illustration stolen from this article)

While working with index array (or similar primitives) we have to use the index element as I32 format only which is really a question when using them in FPGA code. In most of cases I know the amount of elements in the array I am going to handle. So it would be a better option to make the Index terminal as polymorphic and it accomodates Integer values (I8, I16 and I32).

CustomIndex-old.png

CustomIndexValue.png

This idea is not only for FPGA, and also it applies to all the array primitives which uses index terminals.

Download All

I am posting this idea because when you select "View > Tools Palette", you should see the tools palette!

 

The following knowledge base:  http://digital.ni.com/public.nsf/allkb/84FCD62020BF074186256569008375E2  does not work or does not work all the time or does not work in my situation.

 

The issue is discussed here.

 

A brief description of the issue is when more than one person works on a remote station and one individual has a screen ;arger than the screen from the remote station and of the other person developing software remotely, the person with the widest and most resolution can bring the tools palette (and maybe other palettes) to a section of the screen which is not accessible by anyone else.  As a result, the tools palette I can no longer be used, until the person with the widest screen brings back the palette into view.

 

We cannot depend on a parameter within the  LabVIEW.ini file, as it is not always listed in the initialization file.

example:  toolPaletteLoc=400,1499,551,1577

 

The recommended idea is that when selecting "View > Tools Palette", either bring the palette to the center of the screen or implement an intelligent routine that determines the size of the screen and bring the palette within a viewable area.  Since others must also develop on remote stations, bringing the palette to the center of the screen would be the better option as their development screen may be of a different size than that of the remote screen.  Furthermore, it will make it easier to find the tools palette when requesting to view it.

 

Thanks!

If one had to explain the architecture of a larger project to a new person that implements classes & interfaces without referring to a top level UML diagram, the eyes could quickly start to glaze. Adding simple functionality may prove to not be so simple.

 

Perhaps adding to the context help when hovering on the wire showing the hierarchy would be helpful as outlined below.

 

Note: Kudos to Piotr for making the code available. Thank you!

VIWeek 2020/Functional programming inspired object-oriented template in LabVIEW + SOLID

 
 

interface & class context help.PNG

 

I don't like that controls, type defs and strict type defs all have the same file extension: "*.ctl".  I'd like to see something like:

 

  • Standard control: *.lvctl
  • Type definition: *.lvtypedef

(I don't think there needs to be two extenstions to distinguish between type defs and strict type defs).

My idea is to provide references to parts of complex objects (this is already done in a few places but needs to be a general policy). For example, on a table there is a lot that coud be done with the column and row labels (like text rotation) if I could get a reference to just that part of the object.

 

Mike...

Find items with no callers contextual menu on class and library root nodes like available in a projects.

Hello,

 

NI should provide any text label that can be rotated by custom user defined angle like 45 or 30 or -45 or -30 degree.

Currently we have following options only.

 

_aniket72_0-1589361098132.png

 

Best Regard & Stay Healthy,

 

The new icon editor is a big step forward compared to the old one, but there's still room for improvement.

One big issue is using anti aliased/sub pixeled text, like Tahoma.

 

As the picture shows, text written in text fields are AA'd towards white, not the actual color (top row), but when writing the text directly in the picture it gets AA'd towards the background, making it alot prettier and easier to read (2nd row).

 

All text should ofcourse be AA'd towards the color shown, i guess it's an issue with the merging of the icon.

 

regards

/Albert

The 'Prompt User for Input' express VI (LabVIEW 2010) conveniently sets up the return and escape keys as shortcut keys for  the OK and Cancel buttons if you want a 2-button dialog, but if you only want one button (OK), it doesn't get assigned a shortcut key, so you end up having to customize every such express VI . Surely it makes sense to retain the use of the return key to complete data entry in a 1 button dialog?

Add a quick way to start a new LV project in the folder where you want to save it.

 

 

window new menu

A common use case we have is that we have a functional view component (that has behavior) that we want to reuse on a another view.  (For instance, we often want to show behavior from a subsystem view also on a higher-level view.)  It should be the case that we can just insert the functioning, encapsulated view component on any other view and it should work (provided, of course, it will function correctly in the new context, but in the cases I am discussing it will).  In other words, the larger view will be a composite of smaller elements.  (See the Composite design pattern for a related discussion.)

 

Subpanels offer a means to do this, but I suggest they can be simpler to use for this purpose.

 

Currently, using a subpanel this way requires several steps, most notably sizing the subpanel to match the size of the VI we want to insert in it (which is not straightforward).  (Yes, I know we can size the contents of the subpanel to match the size of the subpanel, but we have yet to have a use case for this.)  We also typically write code in the main view VI to insert a VI into the subpanel, run the subpanel VI, and abort the subpanel VI when closing the main view VI.

 

Since this is what we want to do with a subpanel 99% of the time, I am recommending that LabVIEW include a "smart subpanel" that handles this use case in a straightforward fashion.  (All we want to do is select the VI I want to put in the subpanel, and LabVIEW can handle the rest.)  Why should the particular application deal with these (repeatable) details?

 

Notes:
1) There are other ways to use subpanels (although I don't use those ways), I realize, so I am in favor of keeping the current version of the subpanel as well.

2) I know we can write an XControl to do this, but that is a more complicated solution to implement, not a simpler one, and I think the smart subpanel behavior we are seeking should be part of native LabVIEW.

3) I think the smart version of the subpanel should include a property to change the visibility of the subpanel.

When searching for functions in the functions pallet (or the controls pallet), I instinctively begin typing my search terms immediately after I click on on the search button, thus leaving my mouse in the location it was when I clicked on "search". The sequence is shown below:


image_for_submission.png

 

The problem here is that if I use the search function naturally, I can't see my search text as I'm typing (or after I've typed it). Obviously I can avoid this problem by moving my mouse after clicking "search", but that's a less intuitive way to use the search feature. The LabVIEW overall experience could be improved if this mouse-over context help popped up somewhere other than on top of the search text (or not at all).

When performing some scripting I found it handy at times to create the block diagram objects, use a Cut Selection method on the selection objects, and then I would have the image of the objects in my clipboard.  The cases when I needed this I also needed to delete the scripted objects so this one method performed the delete, and allowed me to have an image of the scripted code.

 

When doing the same operations on the front panel I noticed there isn't a Cut Selection method on either the panel or pane classes and made a post about it.

 

http://forums.ni.com/t5/LabVIEW/Missing-Cut-Selection-Front-Panel-Method/m-p/3190560

 

This idea is to create the Cut Selection method on either the pane or panel class (or both I don't really care) which operates like like the Copy Selection, and Delete would today.

It would be nice if there was some consistency in the definition of regions in the vision development kit.  For example, the extract takes a 4 point array as a rectange.  BUT the ROI to rectangle tool outputs a cluster with the rotation:

cluster to array.PNG

It would be nice if there was a generic IMAQ extract ROI and if there was one "rectangle" definition not two.

 

 

Right now, we can only edit a few select build specification properties, such as Icon, Name, and DisplayName. I think it would be very useful to be able to edit more of these properties programmatically.

 

Things I would like to be able to set/read via property nodes:

Build specification name

Target filename

Destination directory

Build specification description

everything under "Version Information"

 

Other items would be useful as well, but those are the ones I care about the most.

 

Typically, when working with classes, one tend to work on one class at a time. Consequently, opening a specific dynamically dispatched VI (from another VI) should result by having the class implementation opened (like if it was opened from the lvclass). The Choose Implementation dialog should not be shown (in most cases).

 

10-16-2010 1-47-24 PM.png

 

I did some quick statistic, and in most situation, I care about the class implementation (about 80% of the time). In some instance I care about parent or children implementation (about 10-15% of the time). Finally, in some rare instance (<5% of the time) I care about the sibling implementation. Note: I confirm this with a few of my colleagues as well.

 

So what I am proposing is that by default we should not see the Choose Implementation dialog. When we specifically want to see this dialog we could use either of these methods:

 

  • Access it through a menu option (Ex: View>>VI Implementation).
  • Access it through a right click menu (Ex: Open Implementation).
  • Use a key modifier such as adding SHIFT (so SHIFT + Double Click or SHIFT + CTRL + Double Click will open the Choose Implementation dialog).

Comment and improvements welcome.

 

 

Have a property node function that can set the aspect ratio of the gridlines in a Graph based on the data. Similar to the 'asp = #' function in r