writing programs for various size monitors

[shankle]

100% of my programs were written for 17"

[shankle]

Hit the wrong key on the previous message. Sorry...

100% of my programs were written on a 17" monitor.
I just got a 19" monitor.
I just got a whole LOT of problems.

If anyone else has found themselves in this predicament,
I sure would like to hear there solution.

Regards,
JPS

[chep]

Errr... the monitor size has nothing to do with it!
Perhaps the screen resolution, but definitely not the monitor size!

Imagine running a program designed for 17" 1280x960 on a 21" 640x480... it won't even fit the screen! :wink :bg


More seriously, what kind of problems are you having exactly ??


BTW, you can edit your own posts. :wink

[donkey]

Chep is right, only resolution matters in Windows. I write my apps for a minimum res of 800x600, after all who uses 640x480 since the death of Win95. My system is at 1024x768 (96DPI) but I have several virtual machines running at various resolutions and OS versions to test with.

About all I can suggest is that you write your apps with resizable windows and controls, my bigger apps all have those so they look right at all resolutions. For retro-fitting existing apps without changing them just make sure the resolutions you set for your new monitor is at least the same (or greater) than the old one.

[hutch--]

Jack,

Its simple enough to handle, just determine the screen resolution and set you windows to a percentage of the current resolution. A dialog is a bit different in that it sizes itself on the font size so if you want them to run on old boxes with lower resolutions, make sure they don't end up too big.

[thomasantony]

Yeah, hutch is right. USe GetSystemMetrics with SM_CXSCREEN and SM_CYSCREEN

Thomas

[donkey]

Well, the screen x/y is not what determines the sizing of the dialog, it is the font as Hutch said. The GetDialogBaseUnits API will allow you to calculate the eventual size in pixels of your dialog given the following formulas:

left   = (left   * baseunitX) / 4
right  = (right  * baseunitX) / 4
top    = (top    * baseunitY) / 8
bottom = (bottom * baseunitY) / 8

There is also the MapDialogRect API to do it all at once, it is particularly useful for dialogs with the DS_SETFONT style set. I think I have an example of doing it in my Res2Dlg AddIn for RadASM, can't remember if I used it or not.

[shankle]

I have attached a small program to test the resolution on a 19" and 17" monitor.
They both seemed to work.

I would appreciate any comments on the program and any comments as to the next
step I should try.
For instance text, bitmaps etc.
My resources for learning are Petzolds book. Nothing else.




[attachment deleted by admin]

[hutch--]

Jack,

It works fine on my 21 inch monitor, fits properly on the screen with no missing bits.  :thumbu

[shankle]

Thanks for all the replies.

In using the following code to resize the screen on a 19" monitor, it  leaves about a 1/2 " area
not filled by the large rectangle and then the taskbar: 

    mov rr.left,0
    mov rr.top,0
    invoke GetSystemMetrics, SM_CXFULLSCREEN
    mov rr.right,eax
    invoke GetSystemMetrics, SMCYFULLSCREEN
    mov rr.bottom,eax
    invoke CreateWindowEx, NULL, addr szDisplayname, addr AppName, WS_OVERLAPPEDWINDOW,\
      rr.left, rr.top, rr.right, rr.bottom, NULL, NULL, hInst, NULL

   Thanks for any advice,
   JPS


   

[doomsday]

I think it'd be worth mentioning that SystemParametersInfo with SPI_GETWORKAREA is IMO a better option as it gives you the area of the screen minus the bit obscured by the taskbar.

regards,
-Brent

[shankle]

Doomsday,

I tried the following code as suggested by you:

    invoke SystemParametersInfo, SPI_GETWORKAREA, 0,  RECT, 0

It compiles without errors.

It runs without creating the 1st screen.
If a debugger is used, it bombs inside  SystemParametersInfo.

JPS