Hey everyone, I’m happy to announce that the Split Container component is now available on the nightly builds. This component has exactly two children panels that are separated by a draggable divider handle that is used to resize the panels at runtime. Like the other available containers in Perspective the Split Container will be available as a root container for views as well as a container to use as a nested container.
The default properties of the split container are as follows:
To dig a bit deeper into these properties and what they are used for:
orientation: Determines the orientation in which the container is fixed. Horizontal allows the user to resize the children panels from left to right while Vertical allows for the opposite directions of top to bottom.
split.position: Bidirectionally represents the current position of the split handle within the container. This property can be represented in one of two ways. The first, and default way, is as a string percentage value ranging from 0 to 100. Where the second is as a numeric pixel value ranging from handleSize / 2 to containerDimension - (handleSize / 2) where containerDimension represents either the width or height of the container depending on the currently set orientation.
split.size: The size of the split handle in pixels
split.visible: Determines if the split handle is visible. Something to note: regardless of the value of this property the handle is still able to be dragged.
split.draggable: Determines if the split handle is draggable or not.
The split container also currently has two component specific events:
onMinBoundReached - Fired when the minimum bound on the container is reached by the split handle
onMaxBoundReached - Fired when the maximum bound on the container is reached by the split handle
That is a general overview of the Split Container, please give this component a try and feel free to post any feedback below. Thank you!
A few features I could see being really nice to use after playing with it a bit.
Manage the styling of the resizing, so if we changed the split position programmatically we could control the movement speed in a transform, would allow for cleaner styling.
Allowing for multiple splits, you could do this with nesting the containers but then you can’t control them as one, and you increase the number of components that need to be added into a screen, therefore loading time.
Defining a min/max expansion size per-pane, would be nice if you didn’t want to make subviews responsive down to minuscule sizes.
Customizing the styling of the split would be nice, take the split in the forums for typing a draft for instance, it’s thinner and cleaner looking in a tight environment. I can’t seem to figure out how to customize it other than making it invisible and so the default highlight is blue.
Changing the default highlight through styling, I’m sure this is possible through theming (so is 4) but that’s a bit of a “super user task” still at this point.
All in all, super useful component and I look forward to augmenting builds with this!
Definitely will be nice to create pseudo-docked views that we have a bit more control over.
Ahh nice!
I’ve tried making this component myself a while ago, unfortunatly making containers is rather undocumented and hard so i had settle for “just the bar” and put it in the middle of a flex container which than manipulated the containers next to it.
It basicly works identical, but it needs a little more setup. So this is nice!
I appreciate the feedback, and those are some good ideas! Especially regarding the general styling access and the min/max size. Going to take a look into those and get some tickets made regarding potential updates.
I have noticed when using this container my CPU usage spikes when I adjust the location on the split. This causes the dragging motion to seem a bit jumpy on the lower powered computer I typically use for HMIs. Is this something IA is aware of? Are there future performance improvements for this container in the works?
Thanks for bringing this to our attention, I was unaware of the CPU spikes while the split handle is moving. Ill create a ticket to take a look into some potential performance improvements on how that is implemented
I was not aware of that, thanks for pointing this out. Is it just not working in general and not accepting any component or just the embedded view component?
I happened to see this while looking for something else today, made a mental note, then later, I thought of exactly the place where I need to use this!
I went home and tried it on 8.1.19 Maker and am having no problems dropping an embedded view to both sides. I'm looking forward to putting it into this special place I have envisioned at work.
One question: Is it possible to make either side either shrinkable or cut it off as the split is moving, as if there is a shrink = 0 or 1 when components are being used in a Flex container?
It depends on the layout of the View being embedded, but this is very easy to do with Coordinate Container layouts in the View being embedded. If your View being embedded is a Flex layout, then you're only going to get the behavior you're looking for if the flex direction is the same as the handle movement, ie: direction = row in a Split Container with orientation = horizontal.
