Nevertheless, I find, it is a little bit cheating, this is more or
less equivalent to a manual correction of the widget position.
If the font size changes, it is still necessary to correct the
botton border (4 in the above exemple). Note: it is always possible
to get the text size with a GetTextExtents() method, a make a correction
accordingly.
Nevertheless, I find, it is a little bit cheating, this is more or
less equivalent to a manual correction of the widget position.
It's the same sort of cheat, but it's a bit closer to what I
was trying to do.
If the font size changes, it is still necessary to correct the
botton border (4 in the above exemple). Note: it is always possible
to get the text size with a GetTextExtents() method, a make a correction
accordingly.
I don't think there's any way to reliably calculate the
baseline offset even if you know the bounding box dimensions.
···
On 2005-09-08, jmf <jfauth@bluewin.ch> wrote:
--
Grant Edwards grante Yow! Send your questions
at to "ASK ZIPPY", Box 40474,
visi.com San Francisco, CA 94140,
USA
I don't think there's any way to reliably calculate the
baseline offset even if you know the bounding box dimensions.
No, there isn't. Indeed, I agree with jmf that Sizers are not designed for typesetting, and a StaticText is a wx.Window, which is, by definition a simple rectangle.
I was going to suggest that you forgo sizers and StaticText and just use a DC to draw what you want. However, DC.GetTextExtent is very limited, so you're still SOL. It would be nice if wx provided a more full featured way to deal with text layout, but that would be a big project!
I suppose it might not be too big a deal to provide a DC.GetTextBaseline, but I also suspect that there would be a whole lot of other methods required to really make something useful.
I don't think there's any way to reliably calculate the
baseline offset even if you know the bounding box dimensions.
No, there isn't. Indeed, I agree with jmf that Sizers are not
designed for typesetting,
If arranging graphical objects (text and graphics) in a 2-d
space isn't typesetting, I don't know what is.
Indeed, the paradigm of nesting horizontal and vertical "boxes"
containing objects with various streachability is _exactly_ the
same paradigm use by the TeX typesetting system. LaTeX tables
are almost identical to the "grid" sizers wxWidgets. The only
difference is that by default TeX's "sizers" align text objects
vertically using the text's baseline rather than the bounding box.
The problem seems to be that the people who design the
alignment mechanisms for UI widgets just plain don't know how
text is supposed to be aligned so that it looks "right".
and a StaticText is a wx.Window, which is, by definition a
simple rectangle.
That's the problem: the fundamental assumption that the the
only reference points of interest are the four corners of the
rectangle. If the rectangle contains text (which almost all of
the non-blank ones do in my wx applications), then vertical
reference point used to align the object should be the text's
baseline, not the window's edge. That's one of the most
fundamental aspects of laying out text.
I was going to suggest that you forgo sizers and StaticText
and just use a DC to draw what you want.
That get's very, very nasty -- especially when you want text
entry and/or combo boxes.
···
On 2005-09-09, Chris Barker <Chris.Barker@noaa.gov> wrote:
However, DC.GetTextExtent is very limited, so you're still
SOL. It would be nice if wx provided a more full featured way
to deal with text layout, but that would be a big project!
I suppose it might not be too big a deal to provide a
DC.GetTextBaseline, but I also suspect that there would be a
whole lot of other methods required to really make something
useful.
--
Grant Edwards grante Yow! I want you to
at MEMORIZE the collected
visi.com poems of EDNA ST VINCENT
MILLAY... BACKWARDS!!