This method doesn't really have to be virtual and this change will allow to
backport the commit adding wxIconizeEvent generation to 3.0 branch.
See #16718.
Explicitly disable rich text content and automatic quotation marks replacement
in normal multiline text controls to make them behave closer to single line
ones and also multiline ones on other platforms.
See #16805.
For such controls (e.g. wxButton, wxChoice, wxGauge), their initial position
was different from the one specified when creating them, even though calling
SetPosition() later did position them at exactly the position passed as
argument.
See #16780.
Try to show as much useful information as possible for the available width,
notably show the time fully, including seconds, which was never done before.
Also add a date column to the dataview sample to allow seeing how this works
in practice.
See #16640.
Controls with wxTE_PASSWORD style didn't send wxEVT_TEXT_ENTER even if they
also had wxTE_PROCESS_ENTER. Fix this by checking for the latter style before
mapping the enter presses to default button activation.
See #14930.
Contrary to an old comment, using it seems to work, while using
secondarySelectedControlColor results in incorrect appearance, different from
the other disabled controls and, worse, makes the labels unreadable as their
colour is too close to that of the background inside nested panels.
See #10524.
If creating a sound object fails, delete it to ensure that it is recreated
later.
This fixes a minor bug: previously, if an invalid file was used as sound file,
only the first attempt to play it resulted in an error and all the subsequent
ones were just silently ignored. Now every attempt to play an invalid file
results in an error message, as expected.
Don't pretend that we created wxSound object successfully without actually
doing it: this means that now passing an invalid (e.g. non-existent or using
wrong format) file to wxSound::Create()/ctor will return false/result in
IsOk() returning false later, just as in the other ports.
It also means that playing a successfully created wxSound object won't give
any error messages, as unexpectedly happened before.
wxPG_NULL_BITMAP macro is not useful because is used only once. In the rest of wxPG code wxNullBitmap is used explicitly many times so for the sake of consistency we can resign from using this macro.
Document that the current value of the control is adjusted if it doesn't lie
in the newly set range and add a unit test to check for this, now that it
actually passes under all platforms, after the previous commits.
Ensure that the current value remains between the lower and upper range
boundaries in the generic implementation, as it was already done by the MSW
one.
If the old value didn't lie inside the new range, it was changed by the native
control internally but the value stored by wxDatePickerCtrl itself remained
unchanged, resulting in asserts later when the mismatch between them was
detected.
Closes#13189.
This parameter is a face name, not a family name, and should be handled as
such, it was totally broken before due to a lot of confusion between face
names and family names in the code.
Closes#4715.
This fixes the sample compilation with default configuration when using MinGW
as it uses wxUSE_GRAPHICS_CONTEXT=0 by default and so wxUSE_ACTIVITYINDICATOR
is turned off by default for it too.
Correctly declare SHStrDupW() as always producing a wide char string on output
and pass a wide string to wxStrlcpy() using a wide char buffer.
Closes#17033.
This helps to detect the situation when HTML tag handlers are not linked in at
all, as it can happen with MSVC when using static libraries, as this doesn't
prevent wxHTML from parsing HTML, it just doesn't render it correctly at all
and it can be difficult to understand why exactly does this happen, so try to
detect this situation and provide a hint.
The fix to the length allocated for the buffer (which was off by 1) in
wx2stc() in 9f81ac16f0 exposed another bug,
which used to compensate for that one, in wx2stclen(), so fix it too.
See #16776.
WM_CLOSE was not processed at all for native windows wrapped by
wxNativeContainerWindow because we don't handle it ourselves at wxWindow level
but still mark it as processed in order to prevent DefWindowProc() from
destroying the window. Unfortunately this also prevented the original handler
for this message in the native window from being called.
Calling just the original handler and not the wxWidgets one is not ideal
neither but is much better as it allows to e.g. close MFC frames wrapped in
wxNativeContainerWindow whereas before this didn't work at all as WM_CLOSE was
completely ignored.
Also call the original handler for WM_DESTROY to avoid similar potential
problems with this message, even if it doesn't seem to create any with MFC.
Extend the mfc sample to show how a wxPanel can be embedded into the existing
CFrameWnd.
They are relatively important, especially the origin-related ones as
SetUserScale() can (should?) be used instead of SetLogicalScale(), but
SetLogicalOrigin() can be more convenient than SetDeviceOrigin(), so provide
at least skeletal documentation for them.
Comparing wchar_t with int doesn't compile under OpenVMS because of
%CXX-E-AMBIGUOUSOPRFUN, more than one operator ">=" matches these operands:
built-in operator "arithmetic >= arithmetic"
function "operator>=(wchar_t, const wxUniChar &)"
operand types are: wchar_t >= enum <unnamed>
Try to work around this by explicitly casting wchar_t to int.
