ellipsize in wxStaticText (Re: wxStaticText GTK woes)
Francesco Montorsi
f18m_cpp217828 at yahoo.it
Wed Jan 10 07:08:54 PST 2007
Vadim Zeitlin ha scritto:
> On Tue, 09 Jan 2007 19:23:02 +0100 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:
> FM> Currently however I'm not using a wxST_ELLIPSIZE style but rather the
following
> FM> ones:
> FM>
> FM> #define wxST_DOTS_START 0x0004
> FM> #define wxST_DOTS_MIDDLE 0x0008
> FM> #define wxST_DOTS_END 0x0010
>
> Do we really need all 3, especially the first one? Is it ever useful?
well, Pango supports it and since on older windows / other ports != wxGTK &&
wxMac we need to have a "generic" support for ellipsization, I thought to just
add all 3 of them since Pango has all of them and then fallback to the generic
code for platforms not supporting it.
Also, a dummy thought: isn't wxST_DOTS_START indispensable for RTL issues?
> FM> this is because I've found the (undocumented) wxST_DOTS_MIDDLE and wxST_DOTS_END
> FM> were already there and used only by the Mac port.
> FM> I'd say they should be renamed to wxST_ELLIPSIZE_START/MIDDLE/END...
>
> In my experience non native English speakers tend to understand better
> the meaning of "dots" than "ellipsis" so while I personally prefer
> "ellipsis", maybe "dots" has the merit of being more clear to more people.
> I could live with either...
well, so I'd still go with wxST_ELLIPSIZE_START/MIDDLE/END since
wxST_DOTS_MIDDLE is not very precise IMHO (i.e. it doesn't explicitely say that
it will remove contents from the middle of the string and replace it with dots).
> FM> Also I've found that win32 supports natively ellipsization:
> FM>
> FM> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/staticcontrols/staticcontrolreference/staticcontrolstyles.asp
> FM>
> FM> MSDN says that the
> FM>
> FM> SS_ENDELLIPSIS
> FM> SS_PATHELLIPSIS
> FM> SS_WORDELLIPSIS
> FM>
> FM> styles are available for Windows NT or later.
>
> Yes but I never know the difference between END and WORD ones, do you know
> it?
I tried both using SS_ENDELLIPSIS and SS_WORDELLIPSIS and the results are: I
don't see any difference :)
MSDN say END version may sometime miss the dots. But the description of the
style is very obscure, since adding it makes it also impossible to create
"multiline" labels (newlines are disabled) I don't understand how could a "a
word that is not at the end of the string go beyond the limits of the rectangle".
Anyway it's not that much important as in the single-line case they behave
identically.
> FM> Unfortunately I've found that MSDN forgets to say that adding
> FM> SS_WORDELLIPSIS or SS_ENDELLIPSIS "disables" the correct newline
> FM> handling in static texts: the newlines in the labels are shown as
> FM> square.
>
> Pity. We'd have to switch to owner drawing for multiline labels with this
> style then (I don't say this would need to be done immediately, it's just
> the only solution that I see).
I don't think we need it - see below.
> FM> So I currently add the SS_ENDELLIPSIS style only if the label does not
> FM> contain newlines.
>
> Provided that it's documented I think it's a quite acceptable solution.
> Most of the time you don't want to use this style with multiline labels
> anyhow.
It does not need to be documented since the logic in wxMSW's wxStaticText is to
use SS_ENDELLIPSIS if and only if wxST_DOTS_END is given, OS is WinNT or higher,
and the label does not contain newlines.
In all other cases generic code is used for ellipsization.
So it's completely transparent to the user.
> The only additional question I have is how these styles are going to
> affect the best size computation: the min size of a label using such styles
> is not really defined, so what will GetBestSize() return? If it just
> returns the same thing as now, the ellipsis will never appear...
well, I haven't touched GetMinSize and it works (ellipsis do appear if needed)
because the following happens:
wxStaticText::DoGetBestSize uses GetLabelText(), which in turn uses GetLabel().
Now (in my local wx) GetLabel() has been overloaded (in wxStaticTextBase) to
return a m_strOriginalLabel. That string is set by SetLabel() and differs from
the displayed text when ellipsization and/or markup is given to the static text.
Since the original (full lenght) string is used in DoGetBestSize() calculations,
the behaviour is well defined. The only modification I did about size handling
is in DoSetSize:
void wxStaticText::DoSetSize(int x, int y, int w, int h, int sizeFlags)
{
// we need to refresh the window after changing its size as the standard
// control doesn't always update itself properly
wxStaticTextBase::DoSetSize(x, y, w, h, sizeFlags);
// do we need to ellipsize the contents?
long styleReal = ::GetWindowLong(GetHwnd(), GWL_STYLE);
if ( (styleReal & SS_WORDELLIPSIS) == 0 )
{
// we don't have SS_WORDELLIPSIS style:
// we need to do ellipsization ourselves.
UpdateLabel();
}
//else: we don't have ellipsization turned on or the OS will do it for us
Refresh();
}
the middle block is new and needed to update the label (shrinking or expanding
it) on user's resize.
At first I thought I had to intercept the wxSizeEvent for the static text window
but then I tried and the code above seems to work well.
Francesco
More information about the wx-dev
mailing list