Resize Front Panel With Listbox

[jmltinc]

After a couple days of searching, I have not found an answer to my problem.

I have a listbox that loads new data when the user double-clicks on an item. The listbox resizes to accommodate whatever data it may contain - both in width and in row number (both up to a maximum).

I want the Front Panel to resize with the listbox keeping a static margin on the right and bottom edges of the listbox.

Can anyone help me with this?

Thanks,

-John

[hooovahh]

It isn't quote clear what you are asking for.  Do you simply want a list box that fits to a pane?  If so use splitters to split up the UI into sections which can be resized independently.

[smarlow]

Can you post some code?  Are you resizing the listbox using a control ref?  is this a "floating listbox" VI?  You should be able take the dimensions you are using to resize the listbox, add a margin, and then set the VI front panel to the new dimensions with the margin added on.

[smarlow]

Is this what you are looking for?

[Thoric]

For your front panel to resize to fit a changing front panel control, you will need to programmatically adjust it. There is no way to do this automatically.

Smarlow has shown a great example above of how to do this.

[jmltinc]

Thanks All to the replies and sorry I am tardy returning. Perhaps you might be kind enough to give it another go with me?

I have a listbox that is resized depending upon with what it is populated. It may have 5 rows; it may have 15 - it may be 600px wide; it may be 1200px wide. The Top/Left position of the listbox never changes - only the Height and Width. There is no Splitter - only two buttons at the bottom of the listbox, each aligned with the outer edge of the listbox. As the listbox resizes, the buttons move in height with the height of the listbox and rightmost one aligning with the right of the listbox. I would like the VI's Front Panel to resize with the listbox to maintain a predetermined margin on the right and bottom; eliminating scrollbars or need for the user to resize the window.

When opening the VI it populates the listbox with a first level of a Bill of Materials (BOM). The user selects an item and the listbox is repopulated with items from the next BOM level. This continues until the last level is reached. The listbox will resize in width depending upon the text inside the 'Description' column and in height depending upon how many items (rows) are in that BOM level. No references are needed for this VI. I cannot provide working code as the listbox is driven by data from a database and its operation requires several sub-VI's inside a State Machine for operation. See screenshot of FP layout.

Smarlow, I tried your solution, but the Front Panel shrinks to hide most of the listbox. For what it is worth, I already position the buttons so the Cancel button is always at the right of the listbox and the same distance below it no matter the size of the listbox. I had been using that control as my reference to resize the Front Panel. I tried several variations of the same - taking the Height and Width of the cancel, adding it to its Top and Left properties, and then somehow add it to the current Front Panel Bounds, but the window either collapsed or continued to grow with each resize (user clicking on the listbox).

I hope there is a solution.

Many thanks,

-John

Edited January 4, 2018 by jmltinc

[hooovahh]

Okay thanks for more details on what you are doing and trying to do.  Attached is a demo of code that shows what I typically do in these situations.  The UI has a splitter setting the upper half to a single pane that the Multicolumn Listbox (MCLB) is fit to.  The pane also is set to scale objects while resizing.  I then have an event triggered when the pane is resized which resizes the columns.  At the moment it has 100 pixels for the 1st column, 90 for the 3rd, 60 for the 4th, and what ever is left is the second.  I also setup panes for the buttons below so the right button sticks right, and the left sticks left.  I also added a New Data button for generating new random data which stays in the center due to more panes.

The thing to notice about this type of solution is that there is zero code handling resizing or moving of controls.  This is all done by LabVIEW and even happens when the VI isn't running.  This means there is not math or code figuring out how big or where a control should be making some parts of the development process easier.  Working with panes can be a pain and some shy away from this solution but the improvements on performance and ease of use once you master working with panes is why I typically use this method.

Hooovahh MCLB Test.zip

[jmltinc]

Thank you, hooovahh.

I have LV2013, so I was unable to open your example.

If I understand you correctly, your code resizes the objects inside the Splitter as the user resizes the window, yes? Perhaps I have this wrong...

I do not need to resize the listbox (or two buttons) when the user resizes the window. I need the window to automatically resize about the controls as the listbox is programmatically resized.

If I am wrong about what your example does, would you be so kind to send it in 2013?

Thanks,

-John

[hooovahh]

Attached is 2013.  I think I understand what you want but I'm just thinking.  In some cases the number of rows might exceed the resolution on the monitor.  One way to always keep the number of rows accessible is with a vertical scrollbar.  Besides users understand how to resize a window, and if they only see 3 rows of 100, they know to resize the window to add more rows.  Or if a column can't be fully viewed they may make the window wider.  It is a design choice and will effect the user experience.  You might also notice I set a minimum window size so you could just make that larger.  It really depends on how much data you typically display.  My solution is just one and you may know more about the users of your software and understand their needs better than I do.  Still I think you could use my demo and programatically resize the window to show the set number of rows you want too.

Hooovahh MCLB Test 2013.zip

[jmltinc]

Thank you for the LV2013 example and your quick response. It is appreciated, hooovahh.

Your example works wonderfully for someone resizing the window. Very nice! I think I might use that sometime

I am looking to do the opposite, though. The listbox remains anchored and its 'Description' column and row count are resized programmatically depending upon data content, which changes with each level of the BOM. The listbox is limited to 15 rows, then it receives a vertical scrollbar. The 'Description' column is also limited in size, preventing the listbox from becoming too large for the screen.

What I am looking to do is programmatically resize the Front Panel as the listbox is also (programmatically) resized so no user input is required. The window/Front panel must expand or contract with the listbox leaving a static margin at the right and bottom.

Can this be done?

Thanks, again.

-John

[jmltinc]

smarlow,

I went back to your original example in your second post - the image. It was behaving much like my previous attempts (in this case hiding part of the listbox), so I dismissed it. But, I realized it did behave differently and so I added constants to add width and height to the FP. It seems that with some tweaks it will do what is required. Thank you. Now, I need to see what I was doing wrong in the first place!

Thank you Hooovahh for your effort. I must not have been clear in my needs.

John

[Jordan Kuehn]

38 minutes ago, jmltinc said:

smarlow,

I went back to your original example in your second post - the image. It was behaving much like my previous attempts (in this case hiding part of the listbox), so I dismissed it. But, I realized it did behave differently and so I added constants to add width and height to the FP. It seems that with some tweaks it will do what is required. Thank you. Now, I need to see what I was doing wrong in the first place!

Thank you Hooovahh for your effort. I must not have been clear in my needs.

John

Glad you found a solution. I would encourage you to look at Hooovahh's solution again when you have time. There is a lot of value to using splitters/panes vs programatically adjusting/polling when it fits your needs.