Resizing Multiple Windows Controls

[MrAl]

Hi there,

Anybody have any good ideas for resizing Windows controls when the user resizes the main window?

For example, say we have a hex calculator, where we have the digits 0 to 9 and also a row of
buttons on the bottom A, B, C, D, E, F, for the upper hex digits.
When we resize the window on the right side (we want to make it wider) the buttons should get proportionally larger.

The problem is, this works out good mathematically:
button widths of 20 pixels each turn into 40 pixels each if the window is made twice as wide
and turn into 30 pixels each if the window is made 3/2 times wider, but when the division does not result in an integer it gets kind of strange because there is also spacing that might need to change.
For example, starting at 50 pixels wide each, if we resize the main window from 500 to 510 each button has to be made 51 pixels wide each, but if we resize the main window from 500 to 505 then each button has to be made 50.5 pixels wide each, which is not possible.
If we make them 51 pixels each, then we end up with an extra 3 pixels with no place to put them without increasing something.
If we keep them at 50 each, then we havent changed anything, so that would mean the window would get 5 pixels wider but the buttons would not change. I guess that may be the only option but would be interested to hear with others have to say about this.

The control resize scheme will get even hairier if the controls are not all of the same size, which is entirely possible and even likely.

I could show some screen shots to illustrate.

 

[jpanhalt]

CTRL+ (- or + ) works with my calculator. Maybe it depends on the application you are using. Here is the one I use for simple conversions -- despite its domain name: https://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html

It appears the pixels per character (or the like) is constant. The CTRL+ tool expands the character.

John

 

[MrAl]

Hi,

Sorry, i meant when you are programming under the Windows platform.
In other words, you call the Windows API function MoveWindow(...params...) for each control that needs to be resized. In that function, the new position and width and height is specified and then the control is redrawn.

In the screen shots, you'll see the windows above the keyboard have been resized, but the buttons have not yet been resized. It's easy to resize the two windows above that, but more difficult to resize the buttons and then possibly also the text.

 

[MrAl]

Hello again,

I was able to make some progress on this, but am finding that it might be a little more difficult. Right now i have it set up so every position (x,y) and every width and height of every control can be changed by a factor made up of the original position and the new window size. This makes sense, because if the window gets 2 times wider then the other controls should get 2 times wider also. With several across the screen horizontally, this means all the controls keep their relative size, relative to the parent window.

This doesnt solve the problem entirely however, as some controls we want to stay the same size either vertically or horizontally. Also what is strange is that if there is say 100 pixels to the right of all of the controls in one row, that gets increased to 200 pixels if the window edge is dragged to make the window twice as wide. Thus it might be better to specify some border too.

So it's going to take some more work, but i was hoping somebody else might have run into this too. I'll have to check around on the web a little more too i guess to get some more ideas.

It's funny the problems you run into for such a seemingly simple task. Another problem was that the window client size can not be 'gotten' programmatically until AFTER the window is actually draw on the screen. This means the value calculations have to be deferred or else i have to calculate the client size from the whole window size which included all of the non client area too which may not come out that exact. Seems like it would be simpler to do than that