This project has moved and is read-only. For the latest updates, please go here.

96,120,144 dpi issues

May 14, 2011 at 12:25 PM
Edited May 15, 2011 at 11:53 PM

Well it seems that it is very difficult to create a program that scales properly to various system display dpi's. In fact if I build the program on a 96dpi resolution & then on the same computer @ 120dpi, I get two different programs with two different layouts.

It seems that the splitters are the issue, they don't scale properly......

So, it seems that any GUI editing need to be done on a PC @ 96dpi & when a release compile is done, it also needs to be on a PC @ 96dpi. When the program is run on a 120dpi, it scales OK, not perfect, but OK.... Running on 144dpi seems to fail however, again it looks like a splitter issue.



May 17, 2011 at 7:03 AM

Looks like WPF (Windows Presentation Foundation) is the only way to resolve the dpi issues - the whole GUI has to be recoded in order to use WPF.....

May 17, 2011 at 3:55 PM

I'm up for it if you are, but we've got a lot of other steps before we could even try. A lot of the "back end" functions are dependent on the UI, some may even require functionality of WinForms versions as opposed to WPF. Maybe a long term goal? Fused with an effort to move the back end out to libraries  where possible might make it easier to do up a whole new interface.

May 18, 2011 at 12:01 AM

Yes I agree, its just frustrating at the moment cause I can't just change something when I see it, i have to change dpi & reboot & my PC. It is, lets say, ancient & really slow to boot.... I can see other developers being put off if its not as easy as possible to work with..... 

I noticed yesterday that a couple of buttons loose there text when run @ 120dpi, so I will fix those up today....

May 18, 2011 at 5:24 AM
Edited May 18, 2011 at 5:31 AM

Playos, I may have found a temporary solution to some of the dpi issues, basically I have been playing with the font selection in the general preferences by adding a reset button so you can return to the default. This got me thinking, how is the font actually being changed? Well it turns out that the font is stored in the preferences & on reload it is applied to a whole list of items in the setupfont class. Now I think I can detect what the dpi of a system is on startup & apply our own font size to all our buttons & text items to make them smaller perhaps by 1 size so they fit.



May 19, 2011 at 8:10 PM

My development system is down for a few days so I can't really look at the code, but from what your describing this sounds like a decent preformance sink at startup... but it's already there and not affecting much.

It it solves a problem for you, and doesn't effect any of the rest of the code base, then absolutly sounds like a good short term solution.

After I reformat and reinstall I'm guna be commiting my latest changes which include a NFO class library and a supporting project that I think will extend to the scrapper later on. It seems to work like a charm but as I was getting into heavy testing my HDD started acting like it was on crack.

May 20, 2011 at 2:30 AM

No worries Playos, I will be concentrating on the bug list first. It won't be every control that needs overriding I don't think, especially for 120dpi, but 144 I think will be another matter. 144 seems to be the default on windows 7 if the screen is over a certain size & resolution. Eventually I want to run @ 144 on mine....

Cheers, look forward to your updates, I will put out this weeks release in about 9 hours....when I get home....