0

I am creating a widow with static text, and because of the all 96/120/180 DPI stuff, I need to create a layouting mini-engine.

The dialog is created in code, statics are created in code, fonts are created in code, everything, mostly because resources in .rc have their share of DPI related problems as well and I want a total control.

The problem with all this is that I don't know how to find the length of the text in statics. I need to calculate the initial size of the static control, and also, I need to calculate a padding between different statics in font unit sizes, but since I don't know the size of the previous static, I can't offset the next one.

The biggest problem is that static does the word wrapping, therefore I can't find a text measuring function that would calculate that and a correction for a custom font, italic, bold, oversize...

Anyone have any ideas?

Coder
  • 3,695
  • 7
  • 27
  • 42
  • Why don't you use a framework that will do all this for you? You don't need to reinvent the wheel. – David Heffernan Jan 21 '11 at 17:17
  • 2
    I have plenty of experience with MFC to say that I never ever want to see the framework to try and do something for me, and fail miserably while at it. Most of the code ends up being workarounds against the framework. And WINAPI is not very DPI aware. Of course, maybe I'm missing the DoMagic() function, but so far, most frameworks add more trouble than it's worth. – Coder Jan 21 '11 at 17:26
  • If MFC is your idea of a GUI framework, then you need to get out more! – David Heffernan Jan 21 '11 at 17:55

2 Answers2

2

The static control styles (ENDELLIPSIS,PATHELLIPSIS and LEFTNOWORDWRAP) seem to map to the DrawText flags, so calling DrawText with DT_WORDBREAK|DT_CALCRECT will probably be as close as you can get...

Anders
  • 97,548
  • 12
  • 110
  • 164
1

I can't think of any compelling reason to do this any differently then the way all other GUI class libraries do it. Just scale window sizes between the 'design' DPI setting and the target machine DPI setting. Using DPI-independent constants is pretty painful in MFC since everything is pixel based. So keep your workstation at the common 96 DPI setting, scale from there on the target machine. You do have to keep a bit of slack because of TrueType hinting.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Under some rare situations scaled text still gets truncated. Create a static with text, resize it to min width, compile run, everything is ok. Since dialog units are default font related, the app should look just fine on 120/180 DPI. But under some profiles text gets truncated. And then there is that localization stuff where text tends to grow or shrink depending on language, which is also a mess with those rc files. – Coder Jan 21 '11 at 21:19
  • And then there is no way to safely convert between DLU/pixels in winapi, so I'm really considering to switch to pixel based layout engine. So that I at least wouldn't have those weird unexplained DLU margins and adjustments to begin with. And WM_SIZE stuff is also a lot easier if the units are constant throughout the app. – Coder Jan 21 '11 at 21:23
  • Well, STATIC is the simple case. You also need to scale edit controls, combo boxes, etc. I did mention the TrueType hinting issue for a reason text can still get truncated. And yes, you leave gobs of space to localize to German. – Hans Passant Jan 21 '11 at 21:30
  • Yes, few of the controls are so bad you can't even get the SM_ attributes for them. Is it fixed on WPF/Winforms GUIs? – Coder Jan 21 '11 at 21:36
  • Winforms implements scaling as I explained. WPF strictly uses inches and points so scales automatically. – Hans Passant Jan 21 '11 at 21:40