Collapsing right side pane

[wiebe@CARYA]

Here's a (brand new) library that handles virtual panes:

https://github.com/Carya-Automatisering/Dynamic-Scaling

It handles object scaling in panes that don't need to be there during edit time. So you can really hide a pane, in stead of shifting it to the side.

It's OO, but you should learn how to use that rather then ovoid it.

It's not the easiest OO library to start with. As it's designed to be flexible and powerful, you need some understanding of inheritance. There are some examples...

[brentjustice]

---

@Hooovahh wrote:

I always have a hard time finding this.  I buried it in my harddrive a while ago and I don't remember where I found it.  Any way I think it was once called Messing around with Splitters, or Fun with Splitters, now I have it named Messing around with sliding a splitter.

In any case it is a demo that shows how panes can be collapsible.

---

@hooovahh, thanks for sharing this code.  I had a fun time poking through it.

I ended up making a very similar, but much less capable toolkit for myself.  (Attached for anyone curious)

I wanted something that felt more like a programmatic API rather than a framework.

Moreover, I didn't feel the need to preserve collapsing multiple panes on the same side.

Question for you:

I'm starting to create some more advanced UIs as I get better at LabVIEW.

That often results in lots of nested subpanels, and nested splitters within subpanels.

A hassle that I'm fighting right now: it seems annoyingly easy for LabVIEW to "crush" splitters in subpanels when the top-level window is shrunk in size.  I find myself having to write code that, on pane resize, tries to update the splitter position to pop it back into its non-crushed state.

You'll see in the code that I've shared here that I created a method called "resize" which does exactly that.  It's really just an anti-crush method.

I'm curious if you've seen any frameworks or toolkits that try to handle this issue.

It seems like setting minimum pane size is a good way to prevent splitter crush, but that has its own drawbacks.

[kevanA]

I ended up writing a class that fleshed out some ideas I found in various places. The object was initialized with the splitter and the pane references on either side. A call to open or close pane would hid the splitter. It mostly works. The more I play around with it the more I wish my UI was simpler.

[Hooovahh]

---

@brentjustice wrote:

Question for you:

I'm starting to create some more advanced UIs as I get better at LabVIEW.

That often results in lots of nested subpanels, and nested splitters within subpanels.

A hassle that I'm fighting right now: it seems annoyingly easy for LabVIEW to "crush" splitters in subpanels when the top-level window is shrunk in size.  I find myself having to write code that, on pane resize, tries to update the splitter position to pop it back into its non-crushed state.

---

Yeah that can be a real issue.  I made an idea for improving it but I don't have much hope in seeing it get implemented.  After making some complicated UI I usually then need to move around the splitters, and resize the window in ways to attempt to break it, then adjust sizes to make sure it works right.  Good UIs in LabVIEW often do use lots of splitters, and subpanels, and at some point it can feel like badly written code.  My only suggestion is to try to modularize it as best you can, with clearly defined roles.  Passing around a pane reference for example all over the place can lead to the similar problems of global variables being written and read all over the place.  You want something like a queue or user event that can perform the work of sizing or moving in one place.  Also be sure and check out PaneRelief by Hope, it is pretty useful in editing these types of UIs.

[brentjustice]

Thanks for your thoughts on the topic.

PaneRelief by Hope is absolutely amazing.  I've already Kudo'd that code.  The ability to create 0px splitters is icing on the cake.

That idea exchange and forum thread were a good read.  Thanks for linking.