When running under Wayland and using two-finger scrolling, GTK seems to only
emit "smooth" scrolling events. The code was already setup to handle
GDK_SCROLL_SMOOTH events - we just needed to add GDK_SMOOTH_SCROLL_MASK to the
event mast of the window in order to receive the events.
Fixes#17734.
Checking whether alpha info flag contains one of
the constants representing image/bitmap with alpha
channel is done more than once in the code so this
check can be moved to a dedicated function.
This makes the collapsible pane allocated exactly its best size better
looking, as the header is centered now, instead of having a border on
the left side, but not on the right one.
See #18515.
DoGetBestSize() actually calculated the best client size and not the
full size, as it didn't take the pane border into account.
Fix this in the simplest possible way, by just renaming the function to
DoGetBestClientSize() instead.
This ensures that the pane is actually big enough to show its contents,
without cutting off the text shown in its header.
Closes#18515.
Make it more clear that we do what we do in DoGetBestClientSize()
because of what our OnPaint() does.
Incidentally fix off by 1 (or 2 under non-MSW platforms) mismatch
between the 2 methods: the gap between the button and the text is
actually just 2 DIPs, not 4, but we need to add another 1 DIP for the
focus rectangle under MSW.
Since wxBitmap can have both alpha channel values and mask we have to use
alpha channel (if required) in the sub-bitmap even if the mask is provided
too.
See #18513.
In the function wxMask::OSXCreate() to create a mask image, data copying
from the supplied memory buffer was not actually implemented and therefore
created mask was invalid.
Closes#18513.
Use setCurrentText(), which works for non-editable combo boxes as well
as for editable ones, instead of setEditText(), which only works for the
latter ones.
Closes https://github.com/wxWidgets/wxWidgets/pull/1542
Do not use DateTime_GetIdealSize or DTM_GETIDEALSIZE. They return
incorrect sizes after the DPI of the window has changed. For every DPI
change, the returned size is 4 pixels higher, even if the DPI is
lowered.
Improve the existing method to also take the minimum height of the
scroll-arrows into account.
Fix the row heights after a DPI change and adjust the column widths.
Use DPIChangedEvent instead of MSWUpdateFontOnDPIChange because the child
controls (m_clientArea, m_headerArea) need to update their font sizes first.
These control are drawn using a wxDC. When the DPI changes, call SetFont
to update the font of the wxDC. First call wxListBoxBase::SetFont() so
m_font is updated to the new DPI, then use this font in the wxDC.
For wxCheckListBox update the margins to fit the changed checkbox size.
The control seems to somehow react to DPI changes on its own (which is
rather mysterious as we don't forward WM_DPICHANGED to it, so it's not
really clear how does it do it, but it does) and changing its font is
worse than useless, as it's not just redundant, but also resets all the
styles used inside the control and so is really undesirable.
Hence override the just added MSWUpdateFontOnDPIChange() to do nothing
for rich edit controls, while still updating the font for the plain EDIT
ones (which is required as they don't scale correctly on their own).
Fix position of spin control in wxSpinCtrlDouble after DPI change
The old size of the control was used to determine the position. Use GetBestSize
instead, which will return the correct size.
Some native dialogs do not scale correctly (color picker, font picker,
open file with custom controls). ALl other native dialogs do scale correctly
(open file, open directory, find replace, print).
Change the DPI Awareness Context temporarily to SystemAware, so Windows handles
the scaling.
As the comments in the function explain, fread() may return a shorter
buffer than expected due to CRT's implicit conversion of DOS EOLs to
\n.
The logic for handling this was however broken: it NUL-terminated the
buffer appropriately, but that had no effect when later used in
wxString constructor, which used buffer's length for string length.
This resulted in slightly larger strings with uninitialized tails that
were mostly invisible to the user as the tail would disappear anywhere
the string was handled as a NULL-terminated C string. It also caused
occassional UTF-8 conversion failures when the tailing bytes didn't
form a valid sequence.
Fixed by using wxCharBuffer::shrink() to properly truncate the buffer.
wxSTC is currently built without c++11 regex support, but the search
flag wxSTC_FIND_CXX11REGEX was included with wxSTC any way. This commit
modifies gen_iface.py so that this flag will no longer be generated or
documented. To prevent any code that is currently using this flag from
being broken, the flag is manually defined in stc.h.in.
In short, the flag will be preserved as it currently is but will be
undocumented so users won't mistakenly try to use it.
Recent versions of Windows 10 (finally!) allow to set up UTF-8 as the
system encoding, so recognize when it is returned by GetACP() in
wxLocale::GetSystemEncoding() and GetSystemEncodingName().
