Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Foxypreviewer preview error

Status
Not open for further replies.
Dusanga, welcome to the forum.

Before posting a question here, it's always worth checking the existing posts in the forum to see if it has already been answered. In this case, the subject has come up several times recently. In particular, see thread184-1821313.

My own solution to this problem is to put the following code at the top of my main program:

Code:
DECLARE INTEGER SetProcessDPIAware IN WIN32API
SetProcessDPIAware()

In addition, one of our regulars, Atlopes, has created a useful DPIAwareManager class that will also solve the problem. For more details about both of these, see thread184-1821304.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Mike,

could SetProcessDPIAware() make a VFP application appear very small on a high DPI screen?

Thanks,
Manni

 
Because I thought you have to redesign the application when using SetProcessDPIAware(), because then Windows won't stretch forms, bitmaps etc. on high DPI screens.

 
ManniB said:
then Windows won't stretch forms, bitmaps etc. on high DPI screens
That's true, so as VFP is pixel oriented you stick to the same pixel size of control widths and heights, but that's not scaling things down, just doesn't scale things up. On the positive side that means things don't get blurred.

And then, as I said in another thread:
myself said:
If you programmed scaling of forms in your application anyway, to address different fullscreen resolutions even with the same display dpi values, I guess this simple and fast solution could be sufficient, as it means Windows won't interfere with your scaling and your scaling will also adjust font sizes, etc., if you did think about keeping the same impression of your overall forms.

So in short, if you already addresssed the ever increasing display resolutions with a resizer or your own resize code, then you can also don't need the automatisms of Windows in regard of dpi awareness, what Windows does - at least to VFP applications, is causing awful blurried looks of both graphics and text. So you should take this into your own hands anyway.

Chriss
 
Thank you fpr the explanation Chriss, I will look into the whole topic of making the application DPI aware in the future.

Manni

 
Manni,

atlopes' DPIaware manager does cover a lot, even resizing anything including fonts and reacting to OS events, so there's little left to do in terms of resizing. I even wonder what remains. I think many ActiveX controls are made DPI aware already. If you have issues left after introducing the DPIaware manager, then its code covers you with the API calls you need, specifically GetDeviceCaps() and how it's used and what information to extract from it.

Chriss
 
Chriss,
thank you for pointing me to Antonio Lopes' DpiAwareManager. Does this mean, if I include the DPI Aware Manager, then it will automatically resize the application to some extent for different screen sizes like Windows does when SetProcessDPIAware() is not used, but without blurring, or will it simply make it easier for me to make adjustments for different screen sizes? I read the description on but this wasn't clear to me.

I'll definately will have a look into it in the future, unfortunately I have not enough time at the moment.

Regards,
Manni
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top