Skip navigation


1 2 3 Previous Next

UI Interest Group

32 Posts

Event handling Problem

Posted by MDPatil Apr 28, 2015

Can Event structure be handled in Sub VI's? If yes then what is its method.


Collapse and Expand Controls

Posted by Ludwig72 Nov 14, 2014

Hi together,


I created an XControl for collapsing and expanding controls. It is just an suggestion to discuss.

Improvements are welcome. Things I have in my head are speed optimization and plugin-like data for the content of the controls.





First I hope I have posted in a relevant forum.  To improve the UI interactivity I have want to include a picture with some simple graphics (omitted for simplicity) representing an area in my UI.  I would like to create Firstly; objects based on coordinates in this picture and and Secondly; be able to click or right click the objects to get a menu like in the attaced  .jpg

To solve the first task I basically tracked the coordinates and printed a textbox. Then by monitoring the coordinates for the mouse I know if I clicked the the textbox "object". I assume that there might be more efficient ways to create these object, having properites or nodes that would help in my second task, which is in either case challenging..

Thankful for suggestions!





LabVIEW GUI Gallery

Posted by cacalderon Dec 22, 2013

I present them my gallery of snapshots of applications developed in LabVIEW.

I thank to some members of LabVIEW-user groups, for their contributions with regard to the design of GUIs.


GUI Gallery Link: 7584&type=1&l=3e64def6f2


1Diapositiva SCADApump.png


2Diapositiva SCADAthermic.png


3Diapositiva SCADAhormy.png


4Diapositiva Invernadero.png


5Diapositiva SpeedControl.png


6Diapositiva CoolingLab.png


7Diapositiva V-beltsLab.png


After seeing this idea exchange post I decided to investigate a couple of ways of implementing that functionality in LabVIEW today.


In this video (and the attached code) I demonstrate two reusable ways of adding an "Explore" option to file paths. The first is creating a new XControl that adds the Explore option but otherwise behaves and looks like the File Path control. The advantage of this technique is that the Explore option is available at edit time. Downsides include having to replace any existing file paths with the XControl and incompatibility with arrays and the like.


The second technique uses the concept of a "BRAT VI" (a child that controls the parent). You drop my VI on your diagram and it adds the Explore option at runtime to any path control or indicator on the front panel of that VI. It does this by getting a reference to it's caller, and registering to recieve events for any path control whenever the shortcut menu is activated or a menu item is selected.



Someone recently asked me if there was a way to standardize LabVIEW font sizes relative to other Windows applications as altenbach describes in his idea exchange post

Screen Shot 2013-06-07 at 3.57.12 PM.png

I did some digging and was able to write a VI to convert a point size into the equivalent LabVIEW size.


Screen Shot 2013-06-07 at 4.02.26 PM.png


I'm posting here just in case anyone else is in need of this functionality. (Note that I haven't tested the backsaved LabVIEW 8.0 VI)


infotainment system home page.jpg


I make .exe, using Properties I hidden menu bar.

Menu bar is only hidden when exe is running.

But when we stop the exe then again Menu bar is come.

Problem: I never want to show menu bar.....when exe is not run means ideal mode.

I trying by run timemenu bar and file-> property option.

still propelm is remain.

plz help me.


Hello all!


So is it really possible to add any new UI objects to your user interface during run-time and even link data to those new objects? Yeah it is! If you use some nice tricks I made this demo for Northern Europe NIDays last year and I just wanted to share it with our UI Community. The code is pretty simple and I made it for demo purpose only. So it's not ready application with proper error handling etc but you will find some cool functions there that you can reuse with your projects. I tried to keep the code as clean as possible so it should be pretty easy to understand how it works.


With this demo you can add new LabVIEW UI objects to the Front Panel and move those objects around with your right mouse click (works best with LabVIEW 2011 btw. There is some feature in 2012 that will popup the right click menu to the objects even though it is disabled. You can hide the menu by clicking the Esc button during the movement if you use 2012.). you can also link data to these new objects (just watch the video how to do it).


Here is simple video that will show you how it works:



If you have any questions please comment and I will try to answer those. Enjoy!


Best regards,




Updated: Added also 2011 verision and fixed one linking problem.


Hi all, this is LabView 2010 version of subVI with a vertical cluster of fallen oil drops.

Regards, Roberto


Hi all!

As soon as I work for Oil & Gas industry, this code is an alternative to the code developed by Pelle Steen.





Hi guys,


When I installed Visual Studio 2012 Express I noticed their nice loading animation in the bottom. See image below (found on web):


After a couple of hours, I'm sort of satisfied.


Just run the file called Loader in the attached folder.


If you want to resize the cluster that contains all the moving objects, that should work just fine. And if you want to add more objects than 5 that should also work fine as long as you tweak the "slow speed area" (see code) setting. I imagine if you spend some more time, you can even make nice patterns in the y-direction.


Have fun and please post your improvements,



In my previous post, "Resizable UI’s in LabVIEW", I went through the basics of creating a flexible and professional user interface that scales to any screen resolution. If you’re new to creating resizable user interfaces in LabVIEW, I recommend you start with that post.




Equipped with an understanding of splitter bars, panes, and fitting controls/indicators it’s easy to imagine how we can create nice looking UIs. So off I go, creating a UI for a new configuration utility. I drop a multicolumn listbox down in my largest pane, fit it to the pane, and set up my columns exactly as I want them.



Looks good so far – I’ve followed all of the rules about making my UI resize, so let’s maximize this window and watch the resizing glory.




Not quite what I had in mind. I only need 3 columns, now I have 10. Your natural LabVIEW instinct will tell you start wading through the various property node options but unfortunately you won’t find a quick fix here. This requires code.


When creating complex applications, you will quickly find that the items you want to scale easily, rarely cooperate. In my previous post, I mentioned a few items that require a little more effort and some code to make them work.


Some of these items include:

  • Multicolumn Listboxes
  • XControls
  • Subpanels


In this post, I will only be focusing on Multicolumn listboxes but will be covering XControls and Subpanels in the future.


Multicolumn Listbox Resizing


Multicolumn listboxes tend to resize best vertically. The problem (as demonstrated) is when we expand horizontally we end up with extra columns or fewer columns. The extra columns make the UI appear cluttered and difficult to read. They tend to make your UI look like you’re working in Excel, and the higher the screen resolution – the worse it gets. Now the question is what behavior do I want my multicolumn listbox to take? Here are a few of the most commonly used options:


  1. I want the columns to grow proportionally and distribute across the screen.
  2. I want the columns to hold their width, but have my final column extend to infinity to reduce the amount of clutter.

To capture a screen resize event, we can use the event structure and the event for “Panel Resize”. The three properties we can make use of in this event are; VIRef, OldBnds and NewBnds corresponding to the VI reference, the previous screen size, and the new screen size respectively. To complete the process, we need to create a code module to do some multicolumn listbox resizing.




Proportional Distribution


This is the most commonly used type of multicolumn listbox resizing. We can determine the percentage of the listbox that each column consumes and maintain the proportions as the screen grows or shrinks. This is illustrated below:




The downside to this method is that data becomes sparse on a large screen resolution. For multicolumn listboxes, which do not occupy the entire screen, proportional distribution is the ideal method. For large listboxes that occupy the entire screen, we may be better off using last column only growth to maintain the look and feel of the application.


Last Column Only


This is another common method for resizing, where only the final column grows. This allows you to maintain the defined column layout, while reducing the clutter introduced by the extra columns typically generated by growing the window.




This method is nice for listboxes which occupy the entire screen. It maintains your layout and does not space data out or alter the appearance of the application.This is all great, but how is it done? Let’s take a look.


The Code


In order to make this function reusable for many listboxes, we will create a generic subVI. This subVI will be dropped into our event structure for screen resize events.




The code accepts a VI reference in order to Defer Panel updates; a listbox reference; the old panel size; the new panel size; and a resizing mode.




For the proportional method on the block diagram, we perform the following steps:


  1. Determine how many pixels the screen has grown by.
  2. Determine if the new bounds are different from the old bounds, if not don’t do anything.
  3. Defer Panel Updates so that the columns resizing happens faster.
  4. Count the number of columns and filter blanks.
  5. Determine the width of each column.
  6. Find the original proportion of the column in relation to the previous screen size.
  7. Adjust each column width proportion multiplied by the new screen size.
  8. Turn off Defer Panel Updates.




For the last only method on the block diagram, we perform the following steps:


  1. Determine how many pixels the screen has grown by.
  2. Determine if the new bounds are different from the old bounds, if not don’t do anything.
  3. Defer Panel Updates so that the columns resizing happens faster.
  4. Count the number of columns and filter blanks.
  5. Determine the width of the last column.
  6. Find the original proportion of the last column in relation to the previous screen size.
  7. Adjust the last column width proportion multiplied by the new screen size.
  8. Turn off Defer Panel Updates.

Conclusions and Next Steps

These are two simple methods for resizing multicolumn listboxes. You could always adapt your own methods for more complex resizing, such as making specific columns grow and others remain fixed. Using my last post "Resizable UI’s in LabVIEW" and the code presented in this post, more complex resizable user interfaces are now possible. In the future, I will give instructions on creating resizable subpanels and XControls which takes resizing all the way to complex architectures and reusable plugins.

Graham Beauregard

Prolucid Logo.gif


Hi Everyone,



I have finished my tookit, for LabVIEW and I would like to share it with LabVIEW community. I think, the quality UI become as important part of a LV code as a functionality itself nowdays. Customizing the LV Controls & Indicators can be done many ways, but what about the LV RTM? (Run Time Menu). Maybe the color of RTM can be chage (I'm not sure) but I clearly know there is no way to insert images into menuitems, that could improve the presence of our FP.


So, I've started to develop a control that may replace the "old-timer" LV RTM. Before saying some words about the toolkit please take a look at the attached pictures.


dotnettoolstrip-slide-1.pngVertical Bar - Example.png


The pictures above show the ToolStrip can be used as Horizontal and Vertical dock.

The following docy types are supported:

  • Left / Top / Bottom
  • Right: (Not suggested - DropDownDirection)

The following ToolStripItems are supported already:



ToolStripItem    Functionality
ToolStripButtonSimple Button
ToolStripLabelSimple Text filed
ToolStripSeparatorSeparator Item
ToolStripMenuItemNestable Item (dropdown)


and the following items are under development:

  • ToolStripProgressBar
  • ToolStripTextBox
  • many more...


How to use:


The picture shows and example. (This VI is also available in the package with many more example.)


  • LabVIEW 2009 or later
  • .Net Framework 2.0 or later
  1. Before use this toolkit, please visit: for more information about usage.
  2. Detalied documentation of VIs is also available here
  3. Toolkit Download Link - the zipped file contains an exe. It is not neccessary to run the exe but makes your life easier if you dont want to copy the toolkit files into user.lib\ manually.


  1. ToolStripButton and ToolStripLabel can be inserted dierctly to the ToolStripControl; can not be nested. (TS - - ParentTag must be empty.)
  2. Parent Tag must refer only ToolStripMenuItem.ItemTag or empty string.



Event Handling:

I think, this is most interesting part of it


User Level: I want to simplify the event handlig as much as possible, so the user doesn't have to take care .Net Events and more. .Net ClickedEvent is registered for UserEvent and used in the top-level vi. The Event returns the ItemTag of the selected ToolStripItem. This ItemTag is used as a parameter of the following methods:


Method Name
TS -

TS -

TS -
TS -
TS -


For more info can be found on the website.



The picture above shows the event handling part of the code. The ItemTag <string> is an individual identifier of each ToolStripItem.


Checked Property:

Checked States.png

There are two types of checked-state. If a ToolStripMenuItem has any icon, the checked state dispalys as the "New" menuitem. Under the New menuitem, Open item has the same icon but its state is unchecked.

And if the menuitem doesn't have any icon, the standard pipe appears as its state is checked.


Version Overview




Feature Request:


  1. MenuEvents can be handled by Queue.  Please check Example II. The Process Queue is responsible for ToolStrip Event handling. The Queue - Dequeue element returns the ToolStripItem ItemTag.
  2. Password protection removed from subVIs. - Feel free to update or modify the source code.




### BSD License ( ###


Copyright (c) 2012, mvTech <> | All rights reserved.



This Full Version tookit is free to use for everyone.

Please place the ToolStrip logo to your application about window.


Source Code:

The complete source code added (without password protection), full of with OO programming tools. ( Recursive algorithm, DVR objects, and so on...)




No Limitation | Full Source Code added


Feel free to use and ask if you have any question!


Resizable UI’s in LabVIEW

Posted by GrahamB Jul 4, 2012


Often as I open new software and the user interface pops up, I make a few typical clicks around, and I can almost immediately recognize it as a LabVIEW application. It’s funny how as a LabVIEW developer, I can recognize just from a user interface alone and some minor interaction that it has been written in LabVIEW. In the past, I found this true with other development platforms; although this is no longer as obvious. So, what is one of the things that made me suspicious of it being written in LabVIEW besides my familiarity with the common controls/indicators?


The screen would not resize.


It seems that generally speaking there is an opinion that in LabVIEW it just isn’t easy or worthwhile to design a nicely laid out, resizable UI. There aren’t very many good examples or documentation available, but it is really quite simple to accomplish. Resizable UI’s give a great feel to clients and give your software added professionalism at very little cost to developers. There is one caveat to this though, it should be considered up front at design time. Completing software without this in mind and trying to convert a UI to become resizable is typically a nightmare and should be avoided when possible. This is most especially true with complex UIs.


So, how is it done?


(After reading this please check out my follow up blog: Advanced Resizable UIs: Multicolumn Listboxes)


The most important step in making a UI resizable is some up front planning. Typically, we do some mock ups of how we anticipate the user interface to look and feel. This is a good time to plan which aspects you want to resize, and which you do not.

Elements to Scale

Elements you wish to resize or not resize should be grouped into sections.


In a LabVIEW application, the following elements typically should resize:


  • Graphs/Charts
  • Multicolumn Listboxes (extra code often required)
  • Image Acquisition
  • Tab Controls
  • Subpanels (extra code often required)


The following elements generally should not resize:


  • Text, Numeric, Boolean controls/indicators
  • Buttons
  • Static images
  • Enums, Ring control/indicators


Keep in mind these are just general recommendations, not rules. See the image below for my sample layout. Notice I have grouped elements such as text inputs, Boolean indicators, and buttons which I do not want to change size.


In this example, the only element I want to scale as the UI resizes is the graph.




Now it’s time to add one of the more underutilized elements on the front panel palette – splitters. These can be found under the “Containers” palette in both Modern and System sections. Adding a splitter to your VI will create a hierarchy of “Panes” on your front panel. Each pane can be considered a section of your front panel that can have separate resizing settings from the rest of the UI.



There are horizontal and vertical splitters, and which you choose first is more important than you might think. It depends on your intended layout, but using my example it is obvious we want all of my text inputs to stay on the left as well I may want to leave some room below for future additions. As well, I want to keep my digital indicators in line with the left side of the graph. In order to keep the entire left side usable and clean, we should start with a vertical splitter.


Drag a splitter onto the front panel and section off the left text boxes from the graph as shown below. At this point, it’s going to look a little sloppy with scroll bars everywhere. Simply right click on the splitter bar, drill down to the pane you are concerned with and turn off each scrollbar to clean things up.




Repeat the same process for a horizontal splitter to section off the bottom digital inputs and buttons. Your screen should look as shown below when you are done:




Looks better now, but the splitters are a bit thick by default. It’s a little tricky to do, but you can shrink down the splitters to be about 1 pixel wide and almost invisible by grabbing the resize terminals in the middle of the splitter when you hover the mouse over it.


The next step that was not obvious before is relating to the buttons. We really would like the buttons to stay on the right side of the screen as it resizes, and keep the digital indicators on the left side of the screen in line with the graph. That will keep things looking clean as it resizes. How can we accomplish this? Add another splitter. Drop a vertical splitter just to the left of the buttons.


Next we need to define which way each pane sticks, grows, and shrinks. This is all configurable from the right click menus on each splitter. By default, each pane will stick to the top left corner and will not resize when dragged. These default settings are good for our left pane, and our digital indicator pane. For the buttons, we want slightly different behaviour to keep the buttons on the right side of the screen.


Configure all the splitters as listed below:


  • Right click on the left splitter and select Splitter Sizing -> Splitter Sticks Left
  • Right click on the bottom horizontal splitter and select Splitter Sizing -> Splitter Sticks Bottom
  • Right click on the bottom vertical splitter and select Splitter Sizing -> Splitter Sticks Right




If you resize the screen now you’ll see the desired behaviour. There is one last step, which allows the graph to resize. In order to do this, simply right click on the graph and select “Fit Control to Pane”.


That’s it. Now resize the screen all you want, it will always lay out nicely. To add more controls and indicators with their own behaviour, just keep adding splitters as necessary.


Your screen should now look like this:




Minimum Screen Size

Once you have set up your UI, it’s generally a good idea to compress it down until it’s as small as possible while still being usable and set a minimum screen size. This will ensure users don’t make the window smaller than you ever intended (which can introduce some odd bugs in the LabVIEW layout).


Accomplish this with the following steps:


  • Shrink the window down as small as reasonably possible without covering up any controls/indicators/labels
  • Go into VI Properties -> Window Size and click “Set to Current Panel Size” and click OK.





Conclusions and Next Steps

This was a simple demonstration for creating a simple, professional looking and scalable user interface. These concepts can be extended into much more complex interfaces involving tab controls, subpanels, XControls, etc. These more advanced topics are covered in my next blog: Advanced Resizable UIs: Multicolumn Listboxes.



Graham Beauregard

Prolucid Logo.gif

1 2 3 Previous Next