[VS 2008] Units Problem

[pengCC]

Dear All,

I have noticed that Visual Studio doesn't work with PIXEL as units. When editing a dialog or frame or any similar element the visual studio editor displays a size (as shown in the attached picture) which doesn't match the PIXEL system used by the monitor.

I would like to be able to work in PIXEL in order to make sure I support the minimum requirements of our clients.

Does anyone know how this works?

thanks a lot,

pengCC

[VictorN]

Dear All,

I have noticed that Visual Studio doesn't work with PIXEL as units.

Well VS2005, 2002, VC++6.0, VC++5.0, VC++4.2, ... didn't work with PIXEL as units either.
They work with dialog unit (DLU) From MSDN:

dialog unit (DLU) A

unit of horizontal or vertical distance within a dialog box. A horizontal DLU is the average width of the current dialog box font divided by 4. A vertical DLU is the average height of the current dialog-box font divided by 8.

And I couldn't understand how pixels helped you "support the minimum requirements of the clients"?

[pengCC]

Thanks Victor,

by meeting the requirements I mean that we want to develop our application in order that supports a display of 1024*768 pixel minumum. In other words we do not want to structure an interface (a CFrameWindow) with buttons and GUI elements with then dissapears if the users has a 1024*768 screen. I hope I am expressing myself properly.

Dialog Units sounds complex, so there is no direct conversion from those to pixels. I need instead to compute how many PIXELS the font we are using and then do the maths. Is that correct?

Which other approaches do you use?

Regards,

pengCC

[OReubens]

DLU's are dependant on the font used in the dialog.
the size of the dialog and all the controls on the dialog will change depending on global windows settings for display fonts. In old windows this mainly meant the "large font vs small font" issue. In newer windows versions this is scaled according to the DPI setting. This means users can accomodate the size of the windows to match ever increasing screen resolutions. Without this, your 1024x768 pixel screen on a very high DPI monitor may end up being next to unusable.

This is not an issue of the designer. it isn an issue of how resource templates work. Resource templates work with DLU's, so the editor does too. If you want to work with pixel coordinates, you will need to create the dialog yourself without a regular template (you could roll your own form of it).

In that case, you will be restricted as to what you can do with the default controls as well since many of them can only be sized relative to the font used in the dialog. You can't just use any size for editcontrols, checkboxes, comboboxes etc. that you would like. There's a reason things work the way they do. If you want very tight control over control sizes, then that may mean you need to create your own controls as well.

[pengCC]

Thank you very much..

so from what I understand would be a lot of extra work which I could not really afford. I was mentioning the 1024*768 size cause I would like to make our application compatible with as many resolutions as possible.

So basically the way around this would get an approximate idea using DIALOG units, DPI and font size and structure our program at the best it could be. Is it possible to dynamically change the font size for the entire program and thus being able to adapt the resolution dynamically at run time ? How would you do this?

In other words, without using custom controls how can I structure my windows in order to look as consistent as possible on different computers?


Many thanks and Best Regards,

pengCC

[VladimirF]

...how can I structure my windows in order to look as consistent as possible on different computers?

Were did you get this requirement from?
It sounds unreasonable. Why do I have to use the same (consistent) UI on my 1920x1200 monitor as another guy on his 640x480?

[pengCC]

For consistent I mean that if I design a CFormView with x number of buttons in my screen there will be no user not being able to display them.. do you understand what I mean? you don't want to work thinking that everyone has the same big screen and so you need to make some consideration on how your software will look like.. of course in your case you will be able to see the window maximized.

I am surprised that nobody has had the same requirement.. how do you deal with this kind of issues?

[VladimirF]

For consistent I mean that if I design a CFormView with x number of buttons in my screen there will be no user not being able to display them.. do you understand what I mean? you don't want to work thinking that everyone has the same big screen and so you need to make some consideration on how your software will look like.. of course in your case you will be able to see the window maximized.

I am surprised that nobody has had the same requirement.. how do you deal with this kind of issues?

Of course most everybody has to deal with minimum resolution requirement. That’s not what I was objecting to. Your form must be usable at all specified resolutions, but it doesn’t have to be the same. The lucky guys with large screens will have less scrolling to do
If you need to use maximum available screen real estate, I would place all your control on the form “approximately”, then at runtime, when your form is initialized, get the screen size and move your controls accordingly. Keep the height of the fixed-height items (single-line edit controls, radio buttons, check and combo boxes, etc.), the rest of them you can stretch.

[OReubens]

You should set your monitor DPI scaling to 100% which is the "normal" situation.

THen design your dialog (in DLU's) using the pixelconstraints you're faced with. If your customers requires dialogs to be usable at a certain resolution, then he should ALSO stipulate which font and DPI settign they are assuming. You can't do much of anything otherwise.

Even a very small dialog with just a few controls can be made to not fit in 1024x768 simply by setting the DPI scaling absurdly high. Similarly I can pretty much fit any absurd dialog into 1024x768 by setting the DPI scaling absurdly small.

If you design for 1024x768 at 100% scaling, and someone at that resolution insists on using 150% DPI scaling, then... well. some of the dialog won't be visible, that's just something you can't solve. You really have to ask WHY that person both insists on that resolution and DPI setting, and try to compromise.
With more work, you can even design dialogs that can be sized so users with really big screens can use all of their screen surface.

[pengCC]

Thank you very much Rubens..

I am sorry to keep asking details but is a new topic for me. Could you please tell me how you can set the scaling at run time? Is there any reference/tutorial that you would suggest?

Is it possible to set the scaling only for a specific application and not modifying the entire font of Windows? (in the control panel I have seen that is possible to change the font size, and in the graphic card is possible to change the DPI settings .., but I am sure there is some system call that you can call from a shell.. but would be nice to be able to do this only for your specific application.. without changing the rest of windows..)

Many thanks and Best Regards,

pengCC

[OReubens]

it's a global windows setting affecting your desktop and all programs.


On Windows Vista/7: Rightclick desktop and select personalize. In the menu to the left. Select "Adjust font size (DPI)"
The default is 96DPI which is what screens have been (more or less) been using since the time of CRT's.

You can set it to any custom size you want via the Custom DPI button. The default windows UI doesn't allow for anything less than 100%, but there's utilities that let you scale down.

[KieBenJ54]

Should we need to think about it like It's basically the way around this would get an approximate idea using DIALOG units, DPI and font size and structure our program at the best it could be. Is it possible to dynamically change the font size for the entire program and thus being able to adapt the resolution dynamically at run time ?