Develop for 17 inch monitor on a 19 inch monitor 1

[Montezuma]

I am developing an Access 2000 database for a user group that will primarily be using 17 inch monitors. I am using a 19 inch monitor to develop this database and I use 1024x768 resolution. The 17 inch monitors also use 1024x768. My difficulty is that without switching to another monitor when I work on the forms I cannot tell exactly how large I can make my forms.

Does anyone know how to work around this problem? I have looked in to software that will resize a window to an exact size and resolution regardless of actual monitor size. All I have been able to find are programs that resize resolution but that doesn't address the whole problem. Any ideas?

Montezuma

 

[hsitz]

I'm not sure what you're referring to. If both the monitor that you develop on (i.e., the 19" one) and the target monitors (the 17" ones) are set to 1024x768 resolution, then you CAN tell how large you can make your forms. If it fills the screen on the 19" monitor, then it's going to fill the screen on the 17" monitor. If it takes up half the screen on the 19" monitor, then it's going to take up half the screen on the 17" monitors. The XGA resolution is a common denominator, no problem. There is no need for a workaround.

I develop on a 1400x1050 monitor and have target monitors of either 800x600 or sometimes 1024x768. I sometimes switch my monitor resolution to the target resolution to get a bettter idea of just how much screen real estate forms are taking up. But I could care less whether the target monitors are 10", 12", 15", 17" or 19", so long as I know what the target resolution is.

Since you seem to be having a problem, I can only imagine two possibilities: (1) your 19" monitor resolution is not set to 1024x768; instead it's set higher so that forms appear smaller on it than they do on the 17" XGA monitors. Solution: either permanently or periodically change your 19" resolution to 1024x768 to check out the size of forms.

OR

(2) your 19" monitor is set to 1024x768 so a form that takes up the whole screen on that monitor also takes up a whole screen on the target monitors, but you're having problems with readability of text on the 17" monitors, since it will be smaller than what you see on the 19" monitor. Solution: find out what point size of text works on the 17" monitors and make sure you work with that point size on your 19"er. -- Herb

 

[RickSpr]

I do get confused about this size vs. resolution thing quite often, but if I'm not mistaken, Windows and its applications don't know how big the monitor actually is. All they know is that they have 1024 pixels of width and 768 pixels of height. I think that means that, if you make your form exactly fill the Access workspace on the 19" monitor, it will exactly fill the workspace on the 17" monitor, too, as long as the resolution is the same (and the video driver is pretty nearly the same).

The confusion partly comes from the fact that Access, and in some contexts, Windows, use "inches" as a unit of measurement. But these don't really correspond to linear inches measured along the screen surface. They're more accurately called "logical inches", and their actual size is variable, depending on parameters in the video driver and on the CRT's dimensions.

The actual image on the screen will, of course, be a different size on the 17" from what it is on the 19". But in terms of what fraction of the frame is filled by the form, they should be exactly the same.

Let me repeat, though, that this is one area where my knowledge of Windows is incomplete. I can only say that I don't have any problem developing on my 17" at home and then using the database on my 15" at work, as long as they have the same resolution. The best approach would be to try an experiment in your own environment. Rick Sprague

 

[gusbrunston]

The user can change his font size to "large"...can cause the problem... Gus Brunston An old PICKer, using Access2000
padregus@attbi.com

 

[ZaZa]

Hi all,

I'm having the same problem. I developed a simple database and put it on a common drive so that it can be accessed by more than one user ( no complex security or user groups etc involved).

all the computers have the same 17" monitors and all the computers or the intended users have the same resoultion as mine - 1024 x 768.

Despite waht the previous pots suggests, on my database the forms exactly fill the screen but on the other computers, the forms are too big and the users have to adjust with the scroll bars!

Could something else be causing the problem here??

Regards,
ZaZa

 

[hsitz]

Zaza -- Several possible things: (1) You're running Access in a maximized window and the other users aren't, or (2) you have more toolbars disabled on your computer than they do on theirs, and nothing in the .mdb is set to automatically disable extra toolbars. These toolbars can take up space at the top of the screen that would make it so that a large form would fit on a computer that doesn't have the toolbars, but wouldn't quite fit on a computer that doesn't.

Come to think of it, I did have a small problem with one installation where the people complained of the forms "not quite fitting". I had designed the forms so they fit on my 800x600 monitor and they were running on the users 800x600 monitor. I never confirmed exactly what the problem was (my help was offered over the phone), but I had to make the forms very slightly smaller than full screen on my computer in order for them to display without scrollbars on the clients. If this is what you're experiencing, then I don't know of any fix for this weirdness, other than to always design screens just slightly smaller than the resolution will allow, since different machines apparently fill the screens different.

I wonder if this has something to do with the "twips" that Windows uses internally to manage form and control sizes. ("Inches" in Access are always translated into twips, for display under the Windows API, as I understand it.) If so, and I'm starting to think it might be, then a solution might be to use something like the dynamic form resizing/scaling module discussed in Chapter 8 of Access 2000 Developer's Handbook. You can download the code from their site:

http://www.developershandbook.com/

I'm not sure about any restrictions on use. I'm not sure what the problem is, but this module could be used to solve it. Would involve retrofitting all forms with the code to implement it (just a few lines) and may require a bit of tweaking beyond that, but it would work. Interesting. -- Herb

 

[hsitz]

Sorry, the link I put in has a little snafu. This link will work better:

http://www.developershandbook.com

 

[gusbrunston]

Dear Zaza:

I am not a pot.

Cheers. Gus Brunston An old PICKer, using Access2000
padregus@attbi.com

 

[ZaZa]

GUS!!


Pardon me, mate. Can't speel wery well 'pecially when fyping quickly....

ment "previous POSTS" not "POTS".

sorry about that!! :~/

ZaZa )

 

[RickSpr]

hsitz, the slight variation from one computer to another is probably related to the display driver/logical inches issue I was talking about above. Display drivers have a parameter that attempts to guess at how many pixels will fit in a logical inch, despite the fact that a logical inch isn't a deterministic measure of anything. Obviously that leaves room for interpretation, and that's why different display drivers give slightly different results.

Unless experience has shown that your particular development system tends to produce good fits on your users' monitors, your idea of designing slightly smaller than the maximum size forms is the best solution. The alternative--detecting the video hardware and adjusting to it at runtime--is way too icky for us Access programmers. If you really wanted to, though, you could probably get a lot of help from the graphics forums here at TT. My bet is that they have to cope with these issues all the time. Rick Sprague

 

[hsitz]

Rick -- I'm sure you're right. Here's what Getz, Litwin, Gilbert have to say in ADH:

"Each screen driver individually controls how large each pixel is in relation to what Windows thinks an 'inch' is. Windows provides API calls to gather all this information. . . the information of concern is the number of twips per pixel. (A twip is equivalent to 1/1440 inch.) Practical experience shows that screens at 640x480 use 15 twips per pixel, and all other VGA screen resolutions use 12 twips per pixel. . . ."

It sounds like the display driver's setting of how many pixels exist per logical inch on the monitor is accessed by Windows to determine how many twips it will allow per pixel. The twips per pixel ratio of different size screens is what the module in the ADH actually uses to automatically resize forms for different resolution displays.

It initially struck me as odd that the same form would take up slighly less or more of different displays, even when they were at the same resolution, but it's starting to make (a little) sense.

I will now design all forms a little small or (better, but a little more work and resource intensive) incorporate the automatic form scaling/resizing into my apps.

The automatic form resizing/scaling has the additional benefit that you can design at any resolution you want and your forms will automatically resize to take up the same amount of real estate even on systems that have different resolutions. For example, I could design my forms to take up 90% of the screen on my 1024x768 monitor and they would also take up 90% of the screen on an 800x600, 640x480, 1280x1024, or any other resolution monitor. What we've just found out is that really we should only be confident that it's taking up, say, between 88% and 92% of the screen on other monitors. And this is apparently caused by display driver differences in their settings of how many pixels make up a logical inch.

Is all that right? -- Herb

 

[RickSpr]

I'd forgotten all about how much coverage ADH gave this subject. I was really impressed with ADH's resize code, at least in its scope. That's probably where I picked up a lot of my understanding about the resizing issues, in fact.

But I'm sorry to say I've never actually used it. It's too much weight to carry just to adjust to the minor differences between display drivers at a given resolution. Adjusting to different resolutions would be worth it, but most often I prefer to adapt to different resolutions by selective resizing of controls. That is, rather than make everything smaller or larger in the same proportion--the balloon effect--I usually prefer to use all of the extra space to widen the large text boxes, or lengthen list boxes or subforms. The balloon effect resizes not only the controls, but the blank spaces between them, and that seems wasteful to me. Usually, anyway. Rick Sprague