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
Document the discrepancy between constructing wxGCDC from
wxGraphicsContext directly or default-constructing it and calling
SetGraphicsContext() later.
Current behaviour is somewhat inconsistent, but useful, because it
allows to draw on wxGraphicsContext using wxDC API using any kind of pen
and brush, even those not supported by this API, while remaining
backwards-compatible (i.e. we can't change SetGraphicsContext() to not
re-apply font, pen and brush, as this would break any existing code
relying on this happening), so it seems like the best alternative.
The changes of ae2cb7d347 resulted in
transformation matrix not being initialized correctly any more.
Fix this by adding yet another helper, DoInitContext(), called both when
initializing wxGCDC using an existing wxGraphicsContext in the
corresponding ctor and the just created one in the other ones.
Closes#18429.
Ensure static text fields use the alignment specified by WX on creation.
This is the second commit doing this, the first one was reverted because
it accidentally included unrelated changes, sorry for the trouble.
See https://github.com/wxWidgets/wxWidgets/pull/1381
When WXWIN_COMPATIBILITY_3_0 is on, compiling this header results in a
bunch of harmless but annoying -Winconsistent-missing-override clang
warnings, so add wxOVERRIDE to silence them.
No real changes.
Prevent wxComboBox from generating a wxEVT_KILL_FOCUS event when the
user opens the drop-down list under wxQt, as logically the drop-down is
part of wxComboBox, even if it's a separate window at Qt level.
Closes https://github.com/wxWidgets/wxWidgets/pull/1377
