Development Team Blog

In Visual DataFlex 14.0 we made a major change in the way we size dialogs. Instead setting a size based on the dialog's outer window size, we sized it based on the Client Area Size. It might be worth explaining how we came about making the Client Area Size change.

We recognized that moving Views and modal panels to Windows Vista was going to create the exact same size issues that occurred when developers moved the applications up to Windows XP. In both cases either borders or caption bars got bigger and child objects no longer fit. They were either clipped or the anchoring logic performed odd adjustments resulting in child objects that just looked misplaced. This is a known issue. We tried to find a good solution back in the XP days and we failed. Our advice to developers was to compromise and make their dialogs a little bigger. This was going to be our advice for Vista as well.

In getting ready for Vista, we took our own advice and changed all of the dialogs in our tools (Studio, Database Builder, etc.) to make them look good in Vista. This was a lot of work, but it had to be done. If we were going to tell you to do this, we had to do it ourselves. When we were finished, we were not very happy. We were now trying to create compromise sizes that looked very good in Vista, good in XP and Ok on pre-XP platforms. You can do this, but it’s time consuming and the results were not particularly satisfying. They didn’t look great anywhere.

We realized that each of our developers would have this exact same problem. You can’t ignore Vista and you can’t leave XP behind. Some customers are going to be purchasing Vista machines (no matter what you tell them) while others will insist on running on XP for a long time (now matter what Microsoft tells them). In many ways, this will probably be worse than the XP migration because XP and Vista are going to exist side by side for a long, long time.

We wanted a better solution.

We revisited the whole sizing issue to see if we could find some solution that had eluded us before. We came up with the new client sizing solution presented here. This is the solution we wish we always had. The container objects that work best when maintaining their outer size (groups, container3d, etc.) maintain that size while the container objects that work best maintaining their client area size (views, modal panels, etc.) maintain that size. This works well across platforms and it is going to work well with skinning.

However, nothing is ever that easy and there was one remaining complication (there’s always at least one). Your existing applications all use outer window sizing for your dialogs. To use client sizing, you need to change your size properties (Size, GuiSize, piMinSize and piMaxSize) to reflect the client area’s size. Without this change existing dialogs will now be too big. We do have a property, pbSizeToClientArea that allows you to either keep your current non-portable outer window sizing or use the new portable client area sizing. Which default do we set for our classes? Do we use a backwards-compatible default that requires changing your code to get good results, or do we use the best possible default, which will have backwards-compatible issues?

In the past, when we’ve asked our developers about these kinds of issues the consensus opinion is to move forward. Do what’s best for new developers and new development. If this means that there are compatibility issues with older programs, you were willing to make the change and put the issue behind you forever.



We decided to select this forward-looking approach and by default use client area sizing. Here is our reasoning:

• If we kept the outer sizing as the default, we introduce this confusion to new users and new use. If you are starting with new code, you don’t want to deal with setting a property to its best value. The best value should be the default.
• If we kept the outer sizing as the default, our existing developers will postpone making any changes and will end up using the less desirable sizing strategy. In the long run, this will be costly.
• To ease the pain of migration we’ve provided the ability to convert your size metrics as you migrate your workspace. We felt that we could provide a good migration utility that will do most of the work for you. This may not be a 100 percent solution, but it will get you most of the way there.
• Even the parts that require manual migration is easy to do and will leave you with a better result. We’ve provided new functions that let you get a dialog’s outer window area size (GuiWindowSize) and its client area size (GuiClientSize). New functions are provided that let you convert between Gui and Dialog units (GuiToDialog, DialogToGui). By using client area sizing with Gui to Dialog conversions you can manually size and locate child objects perfectly.
• If for some reason you really can’t use client area sizing, you can change a property and your dialog will behave exactly as it did before. The migration utility can do this for you and you can do this in your sub-classes.
• Using client area sizing is the only real way you will be able to design for both XP and Vista without having access to both platforms. We expect that just about every developer is already facing this issue or will be facing this within the next year.
• This is going to make the skinning experience much better. The Codejock skinning framework actually uses outer window sizing when it applies a skin. This has all of the problems we’ve discussed. Fortunately, we’ve come up with a special mechanism for maintaining client-area size when skins are applied. To make this work you have to use client area sizing.
• Client area sizing even works better in the Studio. While we support visual modeling for both sizing methods, client area sizing works better. Let’s say you change border styles to make a dialog resizable. In Vista the size of the borders change dramatically. If you use outer window sizing, you will have to reposition all of your child objects to get them right. With client area sizing, it just works.
• Even if you miss some dialogs and they now apply client area sizing with outer sizing metrics your dialogs won’t look all that bad. If you move your application to Vista and make no adjustments at all your application will actually look better with these “wrong” client area size coordinates than it would if you used “correct” outer-window sizing. The dialogs end up being longer and wider than they need to be but nothing is clipped and there are no strange anchoring side effects.

We felt that the pain of migration, which we’ve tried to reduce as much as possible, will be far outweighed by the benefits of client area sizing. As soon as you take one of your carefully crafted and sized client area sized dialogs and run them on Vista or run them with a skin, you will see exactly what we mean.