How to adjust screen size?

[alisaif]

Hi,

We have different screen size in network, how can I set the size for each user.
The size of the screen is 14", 15.1" 18.5" 19" and 24".

Thanks

Saif

 

[Tore Bleken]

So you want your program to change the size of the monitors? I guess you mean the resolution? If not, you must buy a chain saw to cut the bigger monitors down to the size of the smaller ones.

My best advice is: Don't even consider it, unless it's a program which is really meant to be the only program running on the users' machines. People buy bigger monitors in order to have more programs visible all the time, not in order to see bigger letters. Your program should not, I repeat NOT, make any changes to the computer settings.

 

[alisaif]

Thanks for the valuable advice. Yes I mean resolution. I have developed the app on 19" screen, I would be obliged if you could provide the clue/suggestion to run the app simultaneously according to the resolution of the screen.

Thanks

Saif

 

[Tore Bleken]

If you do a quick search for "resize.vcx" here or on Google, you will find exactly what you are looking for.

 

[Mike Lewis]

I'm with Tore on this one. Your app should be independent of screen size or resolution. Leave it to the user to change the resolution through Control Panel settings if they want to. It is not good behaviour for your software to do that.

If you want to specifically cater for users with larger or smaller screens, make your forms resizable, and use the Anchor propery to resize specific controls.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Creating forms on a larger monitory and then "downsizing" them to a smaller monitor isn't the optimal approach. You should design for the lowest common denominator.

As a user, I find applications that resize based on the size of the monitor highly annoying. As Mike says, I use a 27" LCD monitor (two of them, actually) so that I can see more windows at the same time, not so each window can maximize itself and grow everything larger.

 

[mydocpro]

Resolution is a beast for me as well. Some computers (like my DEll XPS15 lappy) have proprietary resolutions that fail for different apps and printers (including Adobe PDFs).

The user simply must adjust (windows) resolution manually ... and also adjust for his/her vision.

Also, I would not trust myself with APIs on anything "Intel", "NVIDIA", or the like.

Would you consider RESIZE methods in VFP, which also resizes fonts, depending on the wrapper object or foundation class you experiment with (VFP samples and/or ffcs)? Resize is all inherent bulletproof VFP. The learning curve is mild, not difficult.

Utmost blessings!
Philip

 

[Mike Lewis]

Some computers (like my DEll XPS15 lappy) have proprietary resolutions that fail for different apps and printers

Just out of curiosity, Philip, can you explain what you mean by that? What is a "proprietary resolution"? Surely, a resolution is just a measure of the number of pixels in a given space? And how can a computer have a resolution? And how can a resolution fail?

You are no doubt trying to make a valid point, but it is a bit puzzling.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I'd say proprietary resolutions are resolutions outside of any norm, perhaps for very special form factors. They could also be resolutions higher than actual screen resolution, which means the desktop pans with mouse movements. The mentioned DELL has 4xHD resolution, you may also call that "proprieatary" as it's not very common and yes, software can have problems with such high resolutions.

On topic, alsaif, I'd also opt for designing for smallest resolution nd use anchoring for resizable forms. see the property anchor of controls.

Bye, Olaf.

 

[mydocpro]

Proprietary resolutions", Mike (and Olaf), could be my poor grammar. Please accept my apologies for that.

My go-to 2014 Dell XPS15 notebook ... while using Control Panel's 'Display' (Win 8.1):

... is 'natively' resolved at 3200 x 1600. Beyond such native resolution it rejects VFP, Adobe, and, within Win 8.1 'reasonable standards' of printing. Adobe PDF995 drivers, and, VFP report listeners (iirc), incrementally crop-out printer output ... whilst lower resolutions become selected (on this XPS-15 notebook). (I've been unsuccessful to google solutions to this hardware 'impropriety' ('mis-behavior' (if you will))).

"Proprietary = Impropriety" (I suppose) for engineers.[highlight #FCE94F][/highlight]

That "proprietary resolution", 3200 x 1600, alone 'behaves' for VFP, Adobe, in Win 8.1 ... but my 60 y/o eyes 'misbehave' at such tiny resolution ... preferring 1080p, iirc.

For the Op:

I've tried VFP Resize methods, pageframes, and Windows positioning APIs ... as tricky yet helpful workarounds for desktop/screen 'real estate' (in my peculiar EMR apps).

Workarounds to overcome screen resolution limitations:
1) Pageframes: page-tabs and auto-paging routines ... visible = .T. or .F. ... opening 'necessary' pages only
2) Resizing objects for screens and resolutions
3) Resizing fonts in fox samples
4) Visible vs. non-visible text, forms, and cmdButton objects, etc.
5) Forms that appear and disappear as necessary
6) Prioritizing objects you deem hopeful-to-necessary.
7) Windows APIs to position and close 'priority' windows.
8) Theoretically, perhaps auto-cleaning of screen and/or desktop clutter (objects, pages, text-boxes, forms, etc. using VFP and/or windows API's ... depending on what objects need to be visible ... etc.)

Sorry to ramble! Utmost blessings!
Philip

 

[Olaf Doschke]

Yes, that's called natively. If you want bigger letters, you should rather change display settings for text sizes. LCD displays, unlike old CRT monitors are only good and sharp at displaying their native resolution. If you choose a lower one, the picture is not sharp, maybe you even don't notice that and maybe that's also OK at exactly half resolution, eg 1600x800 , where each 4 Pixels make up one LCD panel pixel.

Bye, Olaf.

 

[Mike Lewis]

Thanks for that clarification, Philip. The fact that the computer in question is a laptop partly answers one of my queries. As I said earlier, a computer can't have a resolution; it's the monitor that has resolution. But it's easy to confuse them when talking about a screen built into the computer.

By the way, you twice mentioned "VFP resize methods". If you are using the word "method" in the object-oriented sense, keep in mind that Resize is not a method in VFP, it is an event. You don't resize things by calling a method, but rather by changing their Height and Width properties, either explicitly or via the Anchor property. But perhaps you are using the word in a more general sense.

You also mentioned the resizing of fonts. The aim of resizing forms (and therefore the controls within the forms) is not to make the text bigger or smaller; it is to make more or less information visible. You resize a text box to make a wider line of text visible. You resize an edit box to make wider lines or more lines visible. You resize grids to make more rows or columns, or wider columns, visible. And so on.

If you want to let the user change the font size, then that's not resizing; it's zooming. It's perfectly possible to do that within your VFP app, of course, but it's normally done on a system-side basis through Control Panel. If you do offer zooming within your app, it should be done separately from resizing.

To give an example, think of Microsoft Word. The user can change the size of the document window by dragging its edges. Doing so will show more or less text. But that doesn't change the font size. You can change the font size by using the zoom control, but doing that doesn't change the size of any of the objects within the window, such as the menu bar or any buttons. The two are quite separate.

To repeat what both I and Olaf have said several times in this thread, the underlying solution to the problem is to make your forms resizable and to use the Anchor property to selectively resize the controls within the form.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

All you say is correct, Mike, but a 15" 3200x1600 Pixel display is making a non zoomed form very tiny. Apple introduced "Retina" displays with pixel densities so high you can't see distinct pixels anymore, even when you look very near. Apple also introduced virtual pixels (I don't know the exact term), that "bundle" four pixels into one, eg in case of bitmap graphics display, while vector graphics, fonts etc. could make use of the high picel density, but the default font size also was upsized. Windows also offers that, but it's not supported from many applications. It's also known to cause some hiccups in VFP forms, eg in Tabs of Pageframes.

So while it's right to distinguish between resizing and zooming, with higher densities zooming becomes more important, not only in regard of fonts, to really have a usable display. For a long time 96dpi was the standard for displays, but today you get dpi densities, that once only were true and valuable for printers especially for color printing, as you can't mix ink colors in the same fine gradual way as you can with pixel colors.

In ver short: If the dimesnoin of a screen is still 15" a higher screen resolution can't really just be used to show more rows and columns, wider text, this get's smaller physically and thus unreadable, unsuable.

mwResizer (mw alias Markus Winhard)is a tool offering the zoom like resizing, VFP native anchoring is only doing what Mike explained. To adapt forms to high pixel densities I would rather really design for this situation and not just use a resizer class. You have more control about the outcome doing this yourself.

Bye, Olaf.