I often have the problem that label text looks fine on one system but when starting the same program on another machine the font is suddenly huge and text is therefore too long so that it is covered by other elements (buttons etc.). For example, we use WinXP professional at work and my forms look good. On my home machine (also with WinXP) all text is unreadable large. Even anchoring the labels on left and right does not change anything.

Can this be managed somehow (easily)?
How can I make sure that text fits within the available space?

Have you specified a Font.Name and Font.Size? If not, it will use the default Font for the system it is running on.

On Fri, Mar 15, 2013 at 7:43 PM, J?rgen Hestermann <

J?rgen Hestermann wrote

I often have the problem that label text looks fine on one system but when starting the same program on another machine the font is suddenly huge and text

This sounds like a classic DPI issue. One system having 96 dpi, and the other maybe 74 or 120 etc.

What DPI setting did you design your forms in?

Regards,
- Graeme -

I always use Autosize + Nested Panels to avoid this.

2013/3/15 Graeme Geldenhuys

sending this again since the list was down...

that's exactly what i was thinking but got sidetracked all day and have only just returned to finish reading the posts :?

Sorry for the late answer, I was away from any computer for 2 days.

I am not sure I understand what you mean.
What I just found is that this is influenced by the Windows font size settings. It is "big" on my machine and "normal" on the I change it to normal on my machine everything looks okay. Do you mean this too?
If that's the reason then how is it possible to create graphical UI that look correct in all cases? I don't know which Windows setting someone will have if he uses my program. So the "write once, compile anywhere" is not even valid for one single OS. ;-)

Avishai wrote

Have you specified a Font.Name and Font.Size? If not, it will use the default Font for the system it is running on.

No, I have used it with default font settings (I wasn't aware that this will not work). Can I be sure that a predefined font is available on all machines the program will be run on?

You must design the UI taking multi-platform in account. Default font is a safe bet; other fonts may be missing in some setup. Use autosize and nested panels to make sure the widgets don't get cropped. http://port2laz.blogspot.com.br/2012/02/new-screenshots.html

2013/3/18 J?rgen Hestermann

Using the anchor editor is a more lightweight and flexible approach than using nested panels. You only need nested panels for very complex layouts. The only problem is the anchor editor itself obscures the form you're editing more often than not - i'd prefer to see anchor editing to be done inside the form editor (possibly with the help of small context-sensitive popups like those in Visual C#'s form editor) instead of using a big separate window.

(btw in case you haven't used anchor editor, it isn't the same as editing the anchors property in the object inspector - it something way more flexible and configurable that i wish all GUI toolkits had)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130318/525f50ed/attachment.html>

J?rgen Hestermann wrote

What I just found is that this is influenced by the Windows font size settings. It is "big" on my machine and "normal" on the machine at work. If I change it to normal on my machine everything looks okay. Do you mean this too?

Yes, that is exactly what I meant. Kylix (and I believe Delphi) had a DPI setting stored in the form file (*.xfm). This was then used to automatically scale the form and its content if another system had a different DPI value.

Incidentally, this is also why popular toolkits like GTK2+, Qt and Java have layout managers - the prevent such dip issues with great ease.

How this is handled in LCL is beyond me. I think I say a article in the wiki, where somebody developed 2-3 functions ScaleDpi() etc that helps with this problem. It wasn't perfect, but much better than nothing.

Regards,
- Graeme -

That does not work well, because of rounding errors and different fonts/themes.

Incidentally, this is also why popular toolkits like GTK2+, Qt and Java have layout managers - the prevent such dip issues with great ease.

Yes, layout managers are a solution, although IMO "great ease" is an exaggeration.

How this is handled in LCL is beyond me. I think I say a article in the wiki, where somebody developed 2-3 functions ScaleDpi() etc that helps with this problem. It wasn't perfect, but much better than nothing.

Mattias

Mattias Gaertner wrote

That does not work well, because of rounding errors and different fonts/themes.

I used it for years (at least with CLX, and especially so under Linux where each system's dpi value could be different - though these days Linux seem to default to 96 - which I consider bad practice). Anyway, for years I had no problems with the scaling ability.

Yes, layout managers are a solution, although IMO "great ease" is an exaggeration.

Qt and Java makes it dead simple, and yes I consider that "with great ease".

@Jurgen:
Here is the wiki page I remember seeing.
http://wiki.freepascal.org/High_DPI

Regards,
- Graeme -

settings.

It would at least be nice (if it doesn't exist already) that a readonly DesignDPI property is added to the forms and frames? For a WinCE application where I need to support different DPIs I'm hardcoding my own DPI value into the code, but this will break if a colleague should edit or add one form/frame on a computer with different DPI settings... So it would be nice if I could rely on the form/frame telling me in which DPI setting it was last edited...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130319/ef44d440/attachment.html>

Forms are often just opened to look something up. Then a tiny wag and the form is modified and will be saved. So this DPI property will change often, polluting the vcs diffs.
This property should be optional.

One solution is to define a TForm descendant with this property. Once this is registered in the IDE, existing forms can be easily changed.

Mattias