Tool Bar control

[twols]

I would like to integrate a tool bar in my application, but can't find any to download or to buy. Is there any XControl like the tool bar in VIPM and other tools from JKI?

 

Putting buttons in a part of a splitted panel is not the solution.. Building own XControl would take too much time to make it properly.

[hooovahh]

I know of no XControl that does this.  Why is making it yourself "not the solution"?  And neither is making an XControl?

[fabric]

A simple solution is to put a collection of buttons in a cluster and set to arrange horizontally. Then you can show/hide buttons according to context using property nodes. Just use an event handler to detect clicks. How much easier can it be??

[Minh Pham]

I would like to integrate a tool bar in my application, but can't find any to download or to buy. Is there any XControl like the tool bar in VIPM and other tools from JKI?

 

Putting buttons in a part of a splitted panel is not the solution.. Building own XControl would take too much time to make it properly.

Do you really need to create an XControl for this purpose.

Even if you have to it shouldnt take you much time i think

[twols]

I would like to have a reusable tool bar for all the dialogs that need one. And preserve the same look across different applications. I Windows-like toolbar, not just a bunch of system buttons.

 

For the XControl I have to store icons and descriptions and make those editable through a configuration dialog. Could take some time to develop such a XControl. But probably there is no way around it..

[gb119]

Here's a toolbar XControl that I developed for one of my applications. It's not really intended for public consumption, so it's almost entirely undocumented and may not all work as exepected or indeed as I intended :-), but there is a minimalist example included in the project.

Essentially the toolbar is an array of picture controls and the core of the underlying state is an array of button class instances. The button class provides methods to draw itself and also to take an action when clicked. I've included a sub class of Buttons that stores a vi-reference in the button, uses the vi icon to genrate the button and executes the vi when clicked. Obviously one could sub-class the button class to do other things like pass messages via one of the many message/actor type frameworks.

The XControl itself returns a cluster giving information about which button was clicked.

(LabVIEW 2012)

Toolbar.zip

[hooovahh]

Here's a toolbar XControl that I developed for one of my applications. It's not really intended for public consumption, so it's almost entirely undocumented and may not all work as exepected or indeed as I intended :-), but there is a minimalist example included in the project.

Amazing, the community again thanks you for your contribution.  The case as you put it is quite undocumented, and needs work, but the concept is there and it works just well.  Also it should be noted to get this to work you need to install the Array XNode library, which also requires the lava_lib_labview_api_scripting_tools package as well.

 

...However I feel the need to post a topic using XNodes, simply because all I've heard about it is how unsupported it is which makes me nervous.  That being said NI said the same thing about Scripting before it was released and I was using it then too.

 

EDIT: I made a post expressing my concerns with XNode usage.

Edited February 11, 2013 by hooovahh

[gb119]

Amazing, the community again thanks you for your contribution.  The case as you put it is quite undocumented, and needs work, but the concept is there and it works just well.  Also it should be noted to get this to work you need to install the Array XNode library, which also requires the lava_lib_labview_api_scripting_tools package as well.

These are pretty much the reasons I've never released the code 'officially'. Actually the XNode dependency and hence the Scripting tools dependency is pretty easy to strip out and replace with 'static' code. I've sort of intended to do so for ages but somehow other things keep getting in the way. Also, I've a very long term, slow burning, project to replace the whole toolbar with something a bit more flexible that could include other types of control, not just a push button.

[hooovahh]

These are pretty much the reasons I've never released the code 'officially'. Actually the XNode dependency and hence the Scripting tools dependency is pretty easy to strip out and replace with 'static' code. I've sort of intended to do so for ages but somehow other things keep getting in the way. Also, I've a very long term, slow burning, project to replace the whole toolbar with something a bit more flexible that could include other types of control, not just a push button.

This is not a feature request by any means, but if you are thinking about making the tool look more native I would suggest having vertical separators  and a function that allows for resizing the window, which would collapse buttons into a single button when they all can't fit in the display.  See the image of Foxit Reader which collapses the buttons to a >> button which don't fit.

 

 

Just a thought.

[gb119]

This is not a feature request by any means, but if you are thinking about making the tool look more native I would suggest having vertical separators  and a function that allows for resizing the window, which would collapse buttons into a single button when they all can't fit in the display.  See the image of Foxit Reader which collapses the buttons to a >> button which don't fit.

The current design won't allow vertical separators as it uses an array of picture controls (so each slot is a fixed width). The new version replaced that with a single picture control and lots of messy code to work out which part of the picture needs to be redrawn when the user interacts with it. The messiness is one of the reasons I've never finished it !

[hooovahh]

The current design won't allow vertical separators as it uses an array of picture controls (so each slot is a fixed width). The new version replaced that with a single picture control and lots of messy code to work out which part of the picture needs to be redrawn when the user interacts with it. The messiness is one of the reasons I've never finished it !

That does sound messy.  The other solution I was tossing around in my head, was that each picture could be a separate running VI.  Then you can register for a mouse enter/leave for interaction, and mouse down to know which was clicked.  I did a quick test here which displays images, and each image is a VI.  It's far from perfect, and it actually does resizing (which you wouldn't want to do) but it may give you a new approach.

[gb119]

I've packaged up a partially cleaned up version of the code as a VIPM and stuck it on the Code Repository in Uncertified. (here). I think I've found and zapped the XNode instances (unfortunately, they don't show up in the normal dependency places) and some of the vi's now have descriptions. I've also added a tip strip capability to the toolbar which has been on my todo list for about a year !