Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » Draw, Display, Images, Bitmaps, Icons » does ImageCtrl position depends on dpi ?
does ImageCtrl position depends on dpi ? [message #24015] Thu, 17 December 2009 14:32 Go to next message
chickenk is currently offline  chickenk
Messages: 168
Registered: May 2007
Location: Grenoble, France
Experienced Member
Hi everyone,

I design a small app under Ubuntu.

I am currently using the Layout Designer to design the layout of my app.

I want to display three images (successfully imported in my .iml) which are 32x32 pixels each, vertically, and with no margin between them, like this:
 ----
| 1  |
|    |
 ----
| 2  |
|    |
 ----
| 3  |
|    |
 ----


On the layout designer, I create User Classes with ImgCtrl class and I make the borders touch themselves. I checked in the text content of the layout file, everything is alright, I have 32 pixels between each position.

But when launching the real app, I am disapointed to see they do not touch themselves anymore.

I then tried to change the DPI of my screen, and tada ! I can see that the relative position (in pixels) between the ImgCtrls is not the same.

I believe this is because we are dependent on the dpi when positioning images.

How can I solve my problem ?

Here is the illustration at 96 dpi (original):

index.php?t=getfile&id=2051&private=0

And at 72 dpi (images correctly touch themselves)

index.php?t=getfile&id=2052&private=0

Thanks,
Lionel
  • Attachment: at_96dpi.png
    (Size: 5.95KB, Downloaded 587 times)
  • Attachment: at_72dpi.png
    (Size: 5.41KB, Downloaded 798 times)
Re: does ImageCtrl position depends on dpi ? [message #24019 is a reply to message #24015] Thu, 17 December 2009 16:24 Go to previous messageGo to next message
chickenk is currently offline  chickenk
Messages: 168
Registered: May 2007
Location: Grenoble, France
Experienced Member
Sorry for bothering, I found the solution:

Ctrl::NoLayoutZoom()

Problem solved.

Lionel
Re: does ImageCtrl position depends on dpi ? [message #24032 is a reply to message #24019] Sat, 19 December 2009 23:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12098
Registered: November 2005
Ultimate Member
..but you better fix your GUI font size. The whole issue is to accomodate various font sizes....
Re: does ImageCtrl position depends on dpi ? [message #24033 is a reply to message #24032] Sun, 20 December 2009 08:48 Go to previous messageGo to next message
chickenk is currently offline  chickenk
Messages: 168
Registered: May 2007
Location: Grenoble, France
Experienced Member
luzr wrote on Sat, 19 December 2009 23:41

..but you better fix your GUI font size. The whole issue is to accomodate various font sizes....

Thanks, I figured this out as well. But eventually I decided to keep the scaling stuff which is IMO a better solution, but I rescale the images to the controls sizes. The circles can look bigger, it's no big deal for me.

Thanks for answering though

Lionel
Re: does ImageCtrl position depends on dpi ? [message #24036 is a reply to message #24033] Sun, 20 December 2009 13:47 Go to previous message
mirek is currently offline  mirek
Messages: 12098
Registered: November 2005
Ultimate Member
chickenk wrote on Sun, 20 December 2009 02:48

luzr wrote on Sat, 19 December 2009 23:41

..but you better fix your GUI font size. The whole issue is to accomodate various font sizes....

Thanks, I figured this out as well. But eventually I decided to keep the scaling stuff which is IMO a better solution, but I rescale the images to the controls sizes. The circles can look bigger, it's no big deal for me.

Thanks for answering though

Lionel


Exactly - that is the most correct solution.

Mirek
Previous Topic: Draw without CtrlLib [SOLVED] - see ConsoleDraw example
Next Topic: IMAGECLASS::Iml() crashes
Goto Forum:
  


Current Time: Fri Nov 15 00:56:07 CET 2019

Total time taken to generate the page: 0.03990 seconds