I've worked mostly with interface building tools such as xCode's Interface Builder and Visual Studio's environment to place forms and position them on screens. But I'm finding that with my latest project, placing controls on the form through a graphical interface is not going to work. This more has to do with the number of custom controls I have to create that I can't visually see before hand.

When I first tackled this, I began to position all of my controls relative to the last ones that I created. Doing this had its own pros and cons. On the one hand, this gave me the opportunity to set one number (a margin for example) and when I changed the margin, the controls all sized correctly to one another (such as shortening controls in the center while keeping controls next to the margin the same). But this started to become a spiders-web of code that I knew wouldn't go very far before getting dangerous. Change one number and everything re sizes, but remove one control and you've created many more errors and size problems for all the other controls. It became more surgery then small changes to controls and layout.

Is there a good way or maybe a preferred way to determine when I should be using relative or absolute positioning in forms?


It all depends on what your ultimate objective is.

  • Do you want to let your users resize the window?
  • Is it worth the time?

Depending on the project you'll find setting a fixed windows size is much more cost effective, especially if this is an internal tool not meant for the public.

The best solution is to allow your program to reposition items according to the window size. A good approach would be to absolutely position elements within containers, and let the actual containers expand, resize whatever. Then the individual controls inside of these containers would stretch to fill it's parent.

Some framework allow this easier than others. For Windows Forms it can be done, but it's time consuming and feels like it doesn't mesh well with the framework.

Windows Presentation Foundation has this built in, and if you have experience building websites with HTML and CSS you will see that XAML is pretty much the same principle. Some differences are there, but for the most part you will feel right at home.

Since you haven't mentioned a particular framework, I answered based on the two frameworks I use the most.


I'm not sure how IB does it, but if I need to create controls that will move or resize if the form they're on in Delphi, I can do that with the controls' Align and Anchors properties.

Align lets you set a control to take up the entire space available, or all space available along one side of its parent's client area. (For example, setting Align to alTop and giving the control a Height of 20 means that no matter how you resize things, this will always occupy a 20-pixel-high strip along the top of its parent.)

Anchors, on the other hand, is used to maintain a control's position and attributes relative to the edges of the form. It's defined as a bitset representing the four edges of the form. For example, most controls are anchored to the top and the left, but if I make a resizable dialog box, I might anchor the OK and Cancel buttons to the bottom and the right instead so they'll always appear at the same position relative to the bottom-right corner of the form. Anchoring a control to opposite edges (left + right or top + bottom) means that the control will stretch or shrink along with the form if it's resized along that dimension.

That's how it's done in Delphi, at least. See if the form designers you're using support similar properties. If so, it'll make your work a lot easier and simplify a lot of the "spider-web" work.


Well, it's not for the faint of heart, but ages ago when I was creative I came up with a mongrel way to do that called Dynamic Dialogs, based on a control structure called Differential Execution.

The basic idea is not too weird. You have a single function called Contents(), and a "global" mode variable with 3 possible values, SHOW, UPDATE, and ERASE. When Contents() is executed in SHOW mode, it creates controls and makes them visible, calculating their positions as it goes. ERASE mode just gets rid of them. UPDATE mode assumes the controls are already there, but it recalculates their positions (and other properties) and only moves or changes them if necessary. The process is quick since the controls are already there. By having one function do 3 different things, plus data binding, it obeys the DRY principle. To add or remove a control can be a 1-line code edit.

The same concept can also be used to handle events on the controls, such as button clicks or edit-change events. This avoids having to create event handler functions and allows large numbers of controls without confusion.

The trickiness comes in the bookeeping of the control handles, and what to do if the Contents() procedure contains conditional statements like "if" and "for".


You may want to look at the Morphic paper. The Morphic system does a lot of this kind of work - for example, it makes sure that various components are properly arranged on the screen automatically, based on guidelines from the designer (for example, based on alignment rules), as opposed to strict definitions layout definitions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.