In the class description mention that in addition to RGB, an alpha value
is stored as well. Remove incorrect description of operator=(), clarify
meaning of "on" parameter in MakeMono(), and make few minor text edits.
Closes https://github.com/wxWidgets/wxWidgets/pull/1411
If the window has no valid font, GetFont() returns a temporary font.
Extend this font lifetime, so the HFONT remains valid till the end of
the function.
Using the window DPI resulted in returning a twice bigger size in points
than the size really used for the windows on high-DPI monitors as,
apparently, RichEdit always uses DPI of 96 internally (tested with both
wxTE_RICH and wxTE_RICH2 in 192 DPI under Windows 10.0.16299.785).
This will be useful elsewhere too and makes SetFractionalPointSize()
implementation less fragile as we don't have to be careful about
changing pointSize member before setting lf.lfHeight any more.
These functions are not really useful as converting between wxFont and
LOGFONT can be done trivially by passing via wxNativeFontInfo and, in
fact, wxCreateFontFromLogFont() managed to do the conversion wrongly by
forgetting to update wxNativeFontInfo::pointSize member when changing
wxNativeFontInfo::lf.
This fixes one unit test failure after the latest changes, although not
yet the other one, see the upcoming commit for this.
Free() is already called from wxFontRefData::SetFractionalPointSize(),
so there is no need to call it from wxFont too and doing this makes this
method gratuitously inconsistent with all the other setters.
No real changes.
This function is a just a very thin wrapper for WM_SETFONT, but it's
still better to have it rather than write casts to WPARAM and
MAKELPARAM() in several different places.
Note that this removes the assert for font validity from
wxWindow::SetFont() which really doesn't make much sense (and if we
wanted to have it, it would be better to have it for all ports in
wxWindowBase instead) and was never triggered since more than 20 years
of its existence.
The "Native" menu item actually only toggled drawing native-lookalike
labels, but didn't use wxHeaderCtrl as could be expected. Rename the
existing menu item to "Native-like" and add the new "Native" one which
really enables the use of wxHeaderCtrl.
For consistency with the other platforms, coalesce multiple wxEVT_TEXT
events resulting from a single user action into a single one in wxGTK
too. For example, when pressing a key in a control with some text
selected, wxGTK previously generated 2 wxEVT_TEXT events: one
corresponding to the removal of the selection and another one to the
addition of the new text. Now only a single event with the new text is
generated, as in the other ports.
Doing this requires delaying sending wxEVT_TEXT until GTK itself ends
handling the key press, however we delay it as little as possible, so
hopefully this shouldn't have any visible effects at wx API level.
Closes#10050.
Scrolling the item into view to make it visible didn't work since the
changes of badf6bc300, which suppressed
scrolling completely while frozen, any longer.
Work around it by remembering the item to make visible and actually
doing it when the control is thawed.
Also add menu item to call Freeze()/Thaw() on wxTreeCtrl in the sample
to make testing this and similar problems easier.
Closes#18435.
This class seems to be implemented in all the major ports, so remove
note saying that it supports dragging files from the applications only
under MSW.
Closes#18437.
There was confusing with the method GTKIMFilterKeypress() in wxGTK
wxTextEntry: it was called the same as wxWindow virtual method of the
same name, but didn't override it, of course, as wxTextEntry doesn't
derive from wxWindow.
It also wasn't called for wxComboBox which inherited from wxTextEntry
but didn't override wxWindow::GTKIMFilterKeypress() to actually call its
method.
Fix this and rename the wxTextEntry to use a different name for clarity.
And reuse EnableTextChangedEvents() between these classes as well.
No real changes so far, this is just a refactoring to centralize the
code in a single place before modifying it.
Check whether we should ignore the event and mark the control as being
dirty if necessary in a virtual method, which can be defined in
wxTextEntry and overridden by wxTextCtrl, instead of doing it in GTK
callback itself.
This will allow to reuse wxTextEntry callback for wxTextCtrl too in the
upcoming commits.
No real changes so far.
Add IsUsingLogWindow() that can be used to check if the log messages go
into the listbox instead of being shown in a message box, which was
annoying when starting or quitting the sample.
This is a bit more complicated than the hack previously used in
TextWidgetsPage::OnText(), but more general and can be easily reused for
the focus loss messages, for example.
This is useful for quickly checking that we're getting expected events
when modifying the control and/or not getting any unexpected ones and
was already done on wxComboBox page, but not for wxTextCtrl.
With the generic hint support (used in pre-Vista wxMSW, wxGTK2, ...),
defining a wxEVT_TEXT handler not skipping the event completely broke
the control functionality as it was cleared, i.e. replaced the
user-entered text with the hint, whenever it lost focus.
This happened because wxTextEntryHintData::OnTextChanged() was never
called in this case, as the user-defined wxEVT_TEXT handler preempted
it. Work around this by pushing an event handler to the front of the
window event handlers chain instead of just binding to the window events
directly -- this could still potentially result in the same problem if
the user code pushes their own event handler, but this should be much
more rare and, in any case, there is not much we can do about this (the
only solution would seem to be to modify all platform-specific code to
update wxTextEntryHintData explicitly whenever the text changes).
This function is almost exclusively called from IsLevelEnabled() which
doesn't get inlined (at least by MSVS) when wxString is passed by value
to it, and so had to be updated to take a const reference instead, which
means that a copy is always going to be made anyhow, so don't try to be
smart and avoid it -- it doesn't work anyhow and just results in unusual
code, requiring explanatory comments (not needed any longer) and
upsetting static code analyzers.
No real changes.
See https://github.com/wxWidgets/wxWidgets/pull/1387
Tick marks were not available for wxSlider under GTK+ 2 or GTK+ 3
implementations of wxWidgets. However, tick marks have been available
for the GtkScale widget since GTK+ 2 version 2.16.
This change adds similar functionality in relation to tick marks
as was already available in wxMSW builds.
Closes https://github.com/wxWidgets/wxWidgets/pull/1355
