Mid-Michigan Computer Consultants - Bay City, Michigan

CONTENTS       (old style)
Mid-Michigan Computer Consultants
509 Center
Bay City, Michigan

Sales (989) 892-9242
Support (989) 686-8860

Plb-0446.cfm v1.0


ANSI Standard PL/B Language and Visual PL/B

PL/B Sunbelt License

WINDOW Panels and Split Screen Notes

This web resource is written for our own use. But we feel strongly that the PL/B language should be shared with the software community. So feel free to use this at will! BUT PLEASE... if you find errors or omissions or have a better way to do something. TELL US! Dialog helps us all. Send e-mail to:


WINDOW Screen Splitters

The screen shot to the right shows a window with a large panel in the middle and LEFT/RIGHT ListViews with a splitter between them. Sliding the splitter left and right resizes everything!

This is totally controlled by the FORMS DESIGNER and the PL/B RUNTIME. (The feature requires version 8.7c or greater).

Although this is not difficult, there are tricks to getting it all to work together in the way that you want. In particular, this form uses multiple objects in the panels and they must be identified with proper Z-ORDERs to get them in the right positions.

Here's the steps and some notes used to create a screen similar (but simpler) than the one above.



Before Sunbelt introduced panels and splitters at the November 2003 User's Conference,
we had been doing the same thing manually. Notes on that follow.

All our screens allow resizing by draging sides and corners.

I use the RESIZE event on the window itself to trigger that. The resize routine gets the coordinates (top, left, width, height) of some key anchor points and then calculates the size and position of other objects based on these. (It's tedious work, but the results are very satisfying.)

Before the Panel and Splitter objects were added to PL/B 8.7c, we did panels manually. An example is shown below:

For the split screen I use a STATTEXT for my splitter lines or bars. In the designer I make these nice and fat then resize them to skinny and tall (or wide) when the program loads the form.

The resizing routine gets the position of the horizontal and vertical splitter STATTEXTs and sizes the basic three panel screen first. Then it continues to position other objects within those bounds.

Moving the splitter STATTEXT "bars" requires two things. First, the program must turn on dragging. You can't do that in the forms designer. Use "DRAGITEM {StatText name),ON" after the form is loaded.

Second, I use the MOVE event on the StatText to see when a user moves it. With DRAGITEM on, the move event triggers when they release the mouse button. At that time I call my resize routine which positions everything to the new coordinates.

To prevent the user from getting the screen totally out of whack, I set some minimum and maximum ranges on the splitter line positions. If they drop the thing too close to the top, bottom, left or right, I override their position with the minimum settings.

NOTE:   I've noticed a couple of behavioral aspects to this process. First, you can make the splitter stattext skinny, but not TOO skinny. It must be wide enough to allow the user to find it with the mouse.

Second, when dragging the stattext, the move event may not trigger if they move portions of the stattext outside of the window boundaries. For example, you can drag the vertical bar off the left or right side, but if the top or bottom end of that bar is off screen you may not get the move event. Or something like that... I'm not completely sure what's happening there.

On that same note, moving too fast, or without a firm finger on the button, you can lose the HAND cursor and get nothing. But a few minutes practice overcomes that problem.

(This was developed under PLBWIN 8.6.)


The ANCHOR property allows objects to be automatically resized relative to how they were positioned in the forms designer.

This is not a true Windows property. Rather it is a function of the designer and the runtime.

The anchor options in the designer are:
  • Bottom,Left
  • Bottom,Left,Right
  • Bottom,Right
  • Top,Bottom,Left
  • Top,Bottom,Left,Right
  • Top,Bottom,Right
  • Top,Left
  • Top,Left,Right
  • Top,Right
The anchor point is relative. What seems to happen is that the designer computes an OFFSET from the sides of the window. Now when the window is resized, the object is also resized to retain that relative offset.

If, for example you use TOP,LEFT, then the object won't seem to ever move as the screen is resized. That's because it will always anchor to it's top left position in relation to the window's own top left.

If, on the other hand, you anchor to the BOTTOM,RIGHT the object will retain it's original size but will always move to the bottom right corner of the screen. OR AT LEAST to it's position relative to the window's bottom right corner at design time.

Saying that another way. The object is defined by Top, Left, Width, Height properties. Using those, the designer can compute the bottom right corner and can compute position's offset within the window frame. For example: 10 pixels above the bottom of the window and 20 pixels from the right window frame. If the window is resized at runtime, the Width and Height are recalculated to come up with the same displacement from the new window frame.

The various permutation of the anchor points are all designed to produce relative spacing from the sides of the window. Top,Bottom,Left,Right scales the entire object.


Panels seem to work like a container or a collection. If an object is defined as part of a panel, then the object scaling based on the anchor are in relation to the PANEL's sides, not the window's sides.

Z-ORDER may be significant in the relationships when anchoring. This has not been confirmed.

Docking allows you to create a relationship between objects which is maintained as the screen is sized and objects are moved.

Objects are docked in relation to a "container". The basic container is the window itself. Dock to the left and the object will always slam into the left side of the window.

The container can also be a panel. In this case, the object is docked to the edge of the panel.

Objects can dock to other objects. This is done based on Z-ORDER. The object with the lowest Z-Order docks to the edge of the container and each higher Z-order objects docks to it's neighbor.

Panels can be nested. In the example above you have a master panel which contains two sub-panels with a splitter between them. The first sub-panel is docked to the left side of the master panel, The splitter docks to the side of that sub-panel, and the second sub-panel docks to the splitter.

Docking has a special relation to the SPLITTER object introduced in 8.7c. A splitter can be moved with the mouse. If objects are docked to the splitter they are moved to match.

Docking, Panels, and Anchor all work together and must be kept in mind.

An object can be docked to its container as:
  • Bottom
  • Left
  • None
  • Right
  • Top
  • Full (to all sides of the container)

(Also see Window Objects page.)


Write to MMCC Technical Support at:               Send e-mail to MMCC.
MMCC - Technical Support
600 W. Midland
Bay City, MI 48708
(989) 686-8860
© 1997 - 2022 MMCC - All Rights Reserved