Scaling Forms and Controls 2

[Scott24x7]

Hi All,
As part of my desire to "modernize" my application, one thing I find is that there are many screen sizes out there these days, that are beyond the 1024 x 768 that many of my forms are created to.
What I would like to do is have my controls on the forms "scale" dynamically with screen resizing (lower right corner dragging). Getting the form to change size is easy, but what to do with all the position and size of the controls is not so clear.
Does anyone have any advise on how to best tackle this? I've seen properties now in VFP 9 that mention "Anchor", but I don't know if keeping some position of the control is the right thing to do (via anchor). And do you increase white space, and keep controls the same size, or how do you decide to increase/decrease the white space and the control position and size dynamically? Is there some procedure (using PEMSTATUS?) that makes this applicable to a form, or does each control need to be approached?

I've seen some very impressive form control in other applications and some interesting stuff in Visual Studio Expression that essentially defines 2 styles of form (one for vertical like a mobile phone, and one for horizontal favor, like tablet apps), but I just want something that will work in my general PC forms. Any ideas on how to attack this?


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Tore Bleken]

Hi Scott,
there are resizer classes out there which you can dump on your form, set a few properties, and you're done. But that was the way we did it 30 years ago, not anymore. People buy big monitors in order to have more applications open at the same time, not to see bigger objects with bigger fonts. So in short, I strongly advice you against following your idea.

If you want a modern look and feel for your application, you use the anchor properties. So if people enlarge our form, the editboxes and grids will show more information, but with the same font sizes.

 

[Mike Lewis]

Scott,

The short answer to your question is to use the Anchor property. That's exactly what it is designed for. If you're not sure how to use it, see this white paper from Doug Hennig:

http://doughennig.com/papers/Pub/200306dhen.pdf

However, I suggest you think carefully about whether this is really what you want. Do you really want all your controls to grow or shrink according to the size of the usser's monitor? Think about a command button, for example. Just because the screen is twice as large, does it make sense for a command button to be twice as large? And what about the text on the button? Should you double the point size, or keep the text the same size but with more empty space around it?

The reason to resize a control is so that the user can see more information, not larger information. For example, the user might want to make a form larger so that they can see more text in an edit box or a grid without scrolling. What they don't want is for that to happen automatically, for example when they maximise the main VFP window (which is what would happen if you automatically resize a form and all its contained controls). And they don't necessarily want the point size to increase when that happens.

I agree that there might be times when a user wants to see larger text, perhaps because their eyesight is not so good. But that's catered for in the video settings in Control Panel. It's not your application's responsibility deal with that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, you have already looked into the anchor property. I suggest you play with it a little. I seldom made use of relative anchoring.

A few things to note about it: You anchor to the next higher container level, eg controls on a pageframe are anchored to that and not the whole form borders, the container class (border set to 0 width) can be a very fine invisible helper to section your form and have anchorings to this level, that work better than relative anchoring to form borders, the "secret" is of course to anchor the containers to form borders and then anchor the inner controls to the container border, which allows more complex resizing mechanics. That means a preparing step before establishing anchoring might be establishing containers as grouping controls, where you now perhaps only have put a shape around a group of controls, if at all.

Next issue are the more complex controls as the listbox and the grid with their column widths, they don't adapt themselves, so you better have not used native controls but your base class to be able to now establish the adaption to current size (width) in their resize event.

Some devices have really high resolutions with a high dpi sometimes have the OS setting for using a general 150% scale option. That makes VFP render font and borders washed out. That's a situation where I would opt to also adapt font sizes. So this really is not going like "one size fits all". The resizer Tore talked about are handling this, if configured that way, you can't limit their action to only resize grid and listbox columns, but you could look into their coding in that aspect, google mwresize or search it here in the forum, it was a topic already multiple times.

Bye, Olaf.

 

[Scott24x7]

Thanks all for the comments.
I should have been a little clearer in my objective thought.
Tore mentioned "big monitors" for more applications on the same screen, but that's only part of the equation. "Big" now doesn't mean physical size, rather pixels. We use Surface Pro for our laptops, which have a 2K+ screen resolution, (2736 x 1824) which if you run at that resolution, you near go blind, but as Olaf mentioned that can be controlled with % of fonts, but VFP can be really nasty with that, and it doesn't calculate the location of things properly then. (Try and move the command window in VFP with the resolution set to 150% and you'll see what I mean).

But even that isn't specifically the problem for us. We develop our application to run at 1600 x 1200. Then we encounter monitors that are 1920 x 1080. So width is fine, but height is a mess. And when we try to display it on projectors (which often have max resolution of 1920 x 1080, occasionally we find a 1600 x 1200), it's another problem. I thought an "elegant" answer to this would be to enable the controls to somehow shrink and grow (but retaining their resolution, instead the physical control would get smaller, like eliminate a row or two from a grid height.

It seems height is really the problem. If we have Max width of any form is 1600 wide, and that still works in the majority of cases with 1366 x 768 being the '720p' alternative, I could consider fixing the width max to that for most of our forms with not a lot of effort. (There is only 1 or 2 forms that are 1600 wide). But the height issue is really problematic. Should we instead maybe detect the max height of the display, and then lock the form with a scroll bar instead? I don't know if that would work or not, just thinking out loud here at this point.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Koen Piller]

Scott,

I have learned that anchoring is good with resizing to a bigger (size) screen but is useless for shrinking to a smaller (size) screen.
I believe the best option you have is to design your application to a minimal screen size, implent anchoring and VFP will take care of the bigger screen. Never, ever however 'play' with the fontsize, leave it at as is. Bigger screen only means 'you can see more' which is specialy good for grids and listboxes, bigger screens lesses nessesity to have scrollbars etc. You can even design your forms / grids and listboxes with scrollbars if ness to have all the data on 1 screen, you can also implent the scrollbars to be shown when screensizes make this necessary / unnecessary.
So if you donot want to 'upset' your clients with a 1900 x 1080 monitor and friends with 1600 x 1200, design your application with 1600 x 1080 as minimal and if ness. with a scrollbar on your mainform.

Regards,

Jockey(2)

 

[Olaf Doschke]

Scott, I think you still misunderstood anchoring, as it does exactly that, it does not just zoom in, but when you raise the size of a grid means more rows and columns and when you shrink the size of a grid means fewer rows and columns. The only reason I addressed resizing columns is most of my grids are designed for exact widths, so every column can be seen, in that aspect, I'd like to zoom or shrink grids but allow for more rows the higher the forms are.

And to address very high dpi you do zoom fonts, or things get tiny and unreadable. But I wouldn't support the idea to compensate the zooming and resizing in a way the physical form size is the reference you want to keep on all devices, as that doesn't work on small display devices. What compensates their smaller size is that you hold them nearer.

What would be ideal is a mix of both strategies and it's not as easy to implement as to say it, but Anchoring has the better tendency in the direction of making use of additional space.

Bye, Olaf.

 

[Scott24x7]

Jockey and Olaf,
Yeah, I had kind of reached the conclusion in the last day or so that design to the smallest size is the way to go, and that is going to unfortunately result in some big changes for me. As you know I also implemented ribbon function, first in the main form, but now I see it's use in the child forms as well, and that's been my other area, with something like Word or Excel where the "form" never really stops flowing, this isn't a big deal, as it just shifts data further down or back up the visible area. With a database form though, that means shifting the form size up or down, shifting it's contents up or down as the ribbon is exposed, or, leaving the ribbon fixed open (I don't like that idea), or having the ribbon overlap the data (which I have noticed is the behavior in a message compose windows in Outlook), so there is some precedent for it, but it looks messy to me. But I do 100% agree (and was never my intent) to change font sizes is a bad idea. It's been toughest with showing data on projectors, and I also have to account for windows taking 50 pixels or so off the bottom of the screen as well, for the task bar. (If people chose to auto-hide it, then that's up to them.)
So it seems I'll need a full screen re-design... I'll just bite the bullet and do it right now. I've been "revamping" the look and feel for a few months now, so it's just one more part to do there before I start to build new functionality. That said, I'm extremely happy with the progress the UI has undertaken, and it looks incredibly modern, which is very satisfying.
Thanks,
-S

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

@Jockey: I wouldn't say anchoring fails for shrinking down, it works in both directions. What are the additional difficulties, I don't see them.

Well, if the form is cramped with controls it surely will not nicely shrink down to very small screen resolutions, that's even true for quite sparsely populated forms, if you'd aim for 200x150 resolutions, but it's safe to have 1024x768 as a minimum, isn't it? You can disallow shrinking too small with MinWidth and MinHeight.

Bye, Olaf.

 

[Koen Piller]

Olaf,

you are correct, it does work on shrinking also. However as you state when a form is cramped with controls, on shrinking it is difficult to have them all in sight, without overlapping each other. You have two options: either, to disallow a minimum size causing this situation (set minWidth and minHeight) or implent a selfconstructed class to handle that particular situation. Jun has made a nice working class to handle such extreme crammed forms.
A form with a ribbon as menu which calls an other ribbon as submenu, as I understand Scott is building. That is a real challange to implent the native anchor method to handle the form.

Jockey(2)

 

[Olaf Doschke]

Well, you have other options, too, as I already stated: Use containers as helpers for anchoring.

Bye, Olaf.