>>>>And how do you do that? A long time ago, I required my users to run at 800x600. A form might be smaller than that, but some forms take up all the available space (after you consider the menu, toolbar, etc.). They can't size the screen smaller than the design size. Allowing them to do that would be difficult and pointless, IMHO. So how can you write an app that would not care about the resolution (if they ran at 640x480, they'd need to size the forms smaller than the design size, but the app won't let them)? Naturally, 800x600 is the lowest common denominator these days, so I'm safe designing with that in mind. I never see anyone running at 640x480, but perhaps there are people that do. Now, after resisting the move for awhile (just to accomodate those running at 800x600), I've started designing with 1024x768 as the minimum required resolution (in some apps, at least). Forms can always be sized larger, but just not smaller. Still, someone running at 800x600 will have some
>>>>forms shoot off the screen and will not be able to resize them any smaller so that they fit in their screen. They will have to move to 1024x768. Ultimately, the app does care about the minimum resolution, but not about the max.
>>>
>>>In one app I'm working on, we're designing with 800x600 as a minimum, but a desired size of 1024x768 or better. I've added nDesiredHeight and nDesiredWidth properties to my base form class. In the form Init, I call a custom method, SetFormSize. It checks the resolution and if it's large enough, sets the form to the desired size. I'm using anchoring in this app, as well, but I actually turn off the anchors before resizing and then restore them because the goal is to have more of the form show, not make things bigger, in this case.
>>>
>>>Tamar
>>
>>Sounds interesting, but it ends up being a fair amount of work for not much payoff, IMHO (and, most likely, in the opinion of my clients, too <g>). Sure, once it's in your base classes, that work need not be done again. But for each form where this is necessary, you have to spend time setting it up. How will it look/display at 8x6 and how will it look/display at the desired res. When you consider the large number of LCDs out there now - which have a native resolution they look best at and it is usually 1024x768 or higher - is it really worth it to keep supporting 800x600?
>
>I'd love not to, but the client insists. They say their customers need it. For this application, which is highly graphical and where users are likely to have multiple forms displayed all the time, anything that enhances the visual experience is worth it. I have one form in this app that's designed to just get bigger, including bigger fonts, when stretched because that's what the customers need. This is also the first app I've done that uses scrollbars on forms because for this application, it makes sense.
>
>Tamar

Hmm...usually if someone says users are "likely" to have multiple forms displayed at once, I'd figure they would be more interested in having a larger minimum resolution like 1024x768 or higher. Let's face it, at 8x6, how many forms can you see at once? All my apps are multiuser and use modeless forms, so the user can open as many as they want to at once, but they tend to keep it to a minimum because they just don't need them all open at once and how much can you see at once even on large monitors? There's a point of diminishing returns, after all. But when a client talks about users being "likely" to have multiple forms displayed at once, I'd certainly think they'd want a larger minimum than 8x6. Oh well, as you point out, it's all about what the customer wants. However they may be doing what I did for a long time - I just didn't feel like pushing the users past 8x6 and hearing the "it's too small, blah, blah, blah" complaints. Usually people get used to it if they give the higher resolution a chance and then they appreciate the extra real estate, but you will have to listen to some moaning for a while. <g> Anyway, good luck with all of that!