Allow 0pixel size splitter bars

[crelf]

We've all seen the demo that shogg did where he set the color of his splitter bars to the panel color so they disappear at run time, but what if the splitter goes over background controls that you want to persist between panels?

It look slike the smallest i can have my splitter bars is 2 pixels.  I totally want them to show up in edit mode, but I'd like them to be 0 pixels wide in run mode (selectable, of course).

[crelf]

"I discovered today that system splitter bars (at least in my current configuration) show up transparent in run mode when they are set to the smallest size."

Yeah, I can't get ti to work either. Can you maybe point us to a VI that shows an example?

[elset191]

It seems you have to have the background of your panel set to the system Panel & Object color, so I guess it's more of a camouflage splitter than a 0 pixel splitter.

Edit:  Actually It might be a 0 pixel, because when you make the splitter bigger you can see some color differentiation.  You can still grab and move the small one though. 

Also, it seems like only one of the adjoining panes has to be the system color to make it disappear.

[crelf]

That's a neat trick, and definately good to know!

Unfortunately, as you can see from the original screenshot, it doesn't help me in my use case.

[DavidZ.]

I would like to emphasize PJM_Labview's comment back in 2011, that I would be already happy to have a splitter reduced to 1 pixel. Then a splitter would also become a UI element usable in the year 2014 with reduced flat minimal visual design, no 3-D effects etc. A splitter is often also visual separator of some user interface area. Look at this NI forum webpage style, how many lines do have 2 pixels or more? I see only one larger line, the others are all 1 pixel lines. How old-school is it, to have a 2-pixel-limit for a splitter...! Or is there a workaround in the meanwhile to reduce it to 1 pixel or even 0? Decoration lines as alternative for visual separators are sometimes a pain, as they're not controls, not recolorable, not possible to set programmatically invisible, set position etc.

[Thomas_robertson]

I was disheartened to read this and then I just tried wiring Transparent color box to FG and BG in Labview 2016 and it worked!  NI must have fixed this at some point.

[Hooovahh]

I'm not seeing this fixed in 2017.  You still cannot have a zero pixel splitter.  The minimum size I could make it 2 pixels manually.  I also couldn't find any property nodes to set the size of the splitter.  And when I set the BG Color, and FG Color of a system, classic, or modern splitter to the transparent color, they all just turn black.

[wiebe@CARYA]

>I was disheartened to read this and then I just tried wiring Transparent color box to FG and BG in Labview 2016 and it worked!  NI must have fixed this at some point.

Making them transparent is possible since at least 2013. But only in certain splitter styles (not system).

Making them transparent is something completely different then making them 0 pixels however.

[Hooovahh]

> Making them transparent is possible since at least 2013.

How?  The only method I have to make it appear transparent, is to turn it classic, and then paint it the same color as the pane next to it.  This isn't making it transparent, it is making it the same color as a pane next to it, which is a good enough for my UIs but isn't transparent.

[wiebe@CARYA]

Ah. You might be right. Sorry for that. The effect is exactly the same right? (Except when you dynamically change the background colour or panes have different colours).

I made my own scaling class hierarchy (using a vert. and hor. splitter in a Vi in a dynamic visible sub panel, *sigh*), because I also need a flexible number of splitters and "fancy" (not very basic) scaling on multiple controls as well. So dynamic showing and hiding of splitters. Also allows controls to overlap splitters. It got a lot better since I made this... 

[Hooovahh]

Wow that sounds nice, any chance we can see that in the community?  I was just thinking about ways to do some basic scaling but on an unknown number of item, with unknown number of needed panes and splitters.  My idea I haven't finished with yet was recursive subpanels, or a hardcoded limit and moving subpanels and resizing with scripting.  I've already gone done the parent/child methods and those don't work well with subpanels, and likely wouldn't work in an XControl either.