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.
* Adapt xcodeproj for iPhone to generic imaglist.cpp
* Fix the installation error in the iPhone minimal sample
Fix "Failed to install the requested application" error.
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.
This prevented the user from dragging the items in wxTreeCtrl, which is
something that's supposed to be possible.
To allow selection by dragging, we'd need to extend wx API with a method
indicating that dragging is not used in this particular control.
Closes https://github.com/wxWidgets/wxWidgets/pull/1458
It's preferable to use code which is simpler to understand to wx
developers not necessarily familiar with Qt API and which can also be
reused with the other ports if necessary.
In this particular case, using wxString::AfterFirst() also results in
shorter and more clear code too.
See https://github.com/wxWidgets/wxWidgets/pull/1544
The previous commit fixed accelerators support in wxQt for the items
created in XRC, but not for those created directly in the code, as
wxMenuItem::SetItemLabel() is not called in this case.
Refactor the code to extract UpdateShortcutsFromLabel() from
SetItemLabel() and call the new function both from there and from
wxMenuItem ctor, to ensure that the accelerators are taken into account
in any case.
This commit is best viewed with "git diff --color-moved".
See https://github.com/wxWidgets/wxWidgets/pull/1544
Give the application code a possibility to disable or otherwise change
the menu items before the popup menu is shown, as in the other ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/1532
Doing this under all platforms results in too many false positives,
which can't be avoided currently, e.g. even if an application uses "Tab"
as an accelerator only under MSW, these messages still appear (in debug
builds, but this is more than sufficient for them to be annoying).
For now, restrict the messages to wxGTK only. In the future we could
revert to giving them under all platforms if we provide some way of
disabling them, e.g. qualifying accelerators with "[port]" or "[!port]"
string before them.
This partially reverts 6596f5a98d, see
https://github.com/wxWidgets/wxWidgets/pull/1505
Closes https://github.com/wxWidgets/wxWidgets/pull/1566
Declaring the copy ctor/assignment operator for a local class without
defining them triggers MSVC warning C4822, so don't do this to avoid
unnecessary noise in the build logs (we could disable the warning or
conditionally do this for non-MSVC compilers, but it doesn't seem to be
worth doing this for a class used inside a single function and very
unlikely to be copied accidentally).
Override DoEnable() in wxGrid instead of Enable() to ensure that the
grid is shown appropriately for its current state whenever either it or
its parent is disabled.
Note that this also fixes the bug with only the main grid window being
refreshed, but not the row/column headers, which also need to be.
It doesn't really matter whether the grid is disabled because it was
explicitly disabled itself or because it's implicitly disabled due to
its parent being disabled, it should still show its disabled status to
the user by rendering its headers in a greyed out state.
Avoid setting state to DragSelectingState unless dragging items in
wxTreeCtrl is explicitly allowed, as this this causes bad behaviour
downstream with subsequent selections when the client does anything in
the event handler beyond simply not allowing the event.
Basically, we can't be guaranteed of the mouse state on return from the
event handler, so dropping into drag selection mode is potentially
inappropriate (or just plain bad).
Closes https://github.com/wxWidgets/wxWidgets/pull/1523
