Notably mention that showing modal dialogs won't work in this case.
Also link to this explanation from wxListCtrl documentation as
wxEVT_LIST_ITEM_SELECTED is one of the perhaps less expected cases in
which this problem arises.
See #9973.
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
Check that adding a window to either the same, or different, sizer the
second time asserts -- but that it can still be moved to another sizer
if it is detached from the first one first.
Also document that SetContainingSizer() should never be called from
outside the library.
See #17166.
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.
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().
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
