Order array cannot be extended both in DoInsertItems() and DoInsertOneItem()
functions because DoInsertOneItem() is invoked indirectly from DoInsertItems()
(through the call to wxCheckListBox::DoInsertItems() and DoInsertItemsInLoop())
and therefore order array would be eventually extended by two items for one
inserted list item. To avoid this duplicated actions, we should resign from
overriding DoInsertOneItem().
When CF_DIB object is placed to the clipboard, a handle to the memory
object containing a BITMAPINFO structure followed by the bitmap bits should
be passed to SetClipboardData(), not a handle to a DIB section.
Also, wxClipboard is the owner of the wxDataObject being added, so it
should release passed object.
Not all applications recognize properly 0RGB bitmap format so for the sake
of interoperability bitmaps in such format should be converted to plain
24 bpp RGB format prior to being copied to the clipboard.
Closes#17640.
The "sm_showMinMaxSizeControls" was assigned twice, while
"sm_enablePositionAndSizeUnits" was not assigned at all, apparently by
mistake.
Thanks to PVS-Studio for finding this issue (V519 The
'sm_showMinMaxSizeControls' variable is assigned values twice successively).
The "buffer" argument can apparently be null, as there is a check for this on
the next line, but it was used without checking that this is the case.
Fix this, although it's not totally clear if "buffer" can really be null at
all and maybe the check below should have been removed instead -- but prefer
to err on the side of caution.
Thanks to PVS-Studio for finding this issue (V595 The 'buffer' pointer was
utilized before it was verified against nullptr).
VARIANT_TRUE (-1) must be used with VARIANTs of boolean type, instead of TRUE
(1) which has a different value and can result in interoperability problems.
Thanks to PVS-Studio for finding this issue (V721 The VARIANT_BOOL type is
utilized incorrectly).
wxACC_STATE_SYSTEM_INVISIBLE was checked twice, by mistake, while
wxACC_STATE_SYSTEM_MARQUEED was never checked at all.
Thanks to PVS-Studio for finding this issue (V581: The conditional expressions
of the 'if' operators situated alongside each other are identical).
In wxRearrangeList implementations (like wxMSW) where DoInsertItemsInLoop()
and DoInsertOneItem() are not used to insert multiple items, DoInsertItems()
has to be overriden to do this insertion.
See #17836.
Number of indices stored in the internal order array has to be the same as
number of the items, so whenever item is added or removed, order array
has to be adjusted accordingly.
Closes#17836.
This method doesn't override any virtual method in the base class, so
wxOVERRIDE can't be used here.
In fact, this method doesn't seem to be used at all, but keep it for
compatibility and in case we want to use it later, as wxGTK does.
Labels containing mnemonic prefixes (&) and literal underscore characters
have to be converted to the proper GTK labels where underscore
characters act as mnemonic markers. If label contains mnemonic then
dedicated function gtk_radio_button_new_with_mnemonic() should be used
to create radio button item.
Closes#17419.
This notably fixes the problem with changing the year using spin control
arrows under macOS, where this control is used as part of
wxGenericCalendarCtrl, as not having the correct value in the event object
resulted in bogus events with dates in the year 0 there.
Closes http://trac.wxwidgets.org/ticket/17193
No real changes, just use DST_OFFSET constant instead of 3600 and remove the
"FIXME" comments as we're not actually going to fix anything here but will
just continue to assume 1 hour shift for DST.
This reverts commit aaddf6be7f as it broke
handling of dates when local time zone is BST, whose offset not counting DST
is 0, as for UTC, but which still should be handled as local timezone,
see #17220.
With the current wxDateTime handling of time zones, FromTimezone(Local)
doesn't make much sense anyhow, so abandon attempts to try making it work as
to really do it we need to specify the time zone being converted from too, as
explained in the second point of #10445.
See #16585.
Use wxPrintf() and remove the c_str() call which is redundant with it instead
of using printf() which can't be used with non-POD objects like wxCStrData
returned by c_str() in wx 3.0+.
Even if <xlocale.h> exists, the whole API that wx requires (specifically
strtod_l() and similar) may not be available. This is the case
on e.g. OpenIndiana (SunOS).
On OpenIndiana (SunOS) the result is different when compiled as C,
and the C++ result is what matters to wxWidgets.
Fixes compilation of src/common/strconv.cpp on OpenIndiana.
Apparently, DirectWrite fonts can be created only from TrueType fonts and
therefore only such fonts can be used with Direct2D-based wxGraphicsContext.
When unsuported GDI font is passed to CreateFont() then no graphics font is
created and this unsuccessful attempt is signalled by returning
wxNullGraphicsFont. This null object can be used in e.g. wxGC::SetFont()
to check if font was actually created.
See #17790.
Since the changes of c9a458bfe8 ("Use Win32
::CommandLineToArgvW() to tokenize command line"), this is not guaranteed any
more as this Win32 function doesn't necessarily ensure it under older MSW
versions such as XP.
Just use "argc" explicitly instead of relying on this in wxCmdLineArgsArray to
fix crashing under XP.
Drawing on the Cairo surface itself can give invalid results when source and destination regions overlap.
To avoid this problem we have to copy actual source surface to the temporary one and use this copy in drawing operations.
Closes#17666.
In order to examine real colors of pixels we need to have unmodified (aliased) edges between regions drawn with different colors.
For for wxDCs backed by wxGraphicsContext (e.g. under wxGTK3) antialiasing is enabled by default and to prevent falsifying pixel colors we have to disable it prior to drawing operations.
See #17666.
Under wxGTK3 default color depth for wxBitmap is 24 bpp and therefore wxAlphaPixelData cannot be used to get access to wxBitmap's internal data in this case.
See #17666.
One of the wxMarkupParser tests expects "&" to map to "&&" however
this, purposefully, is not the case any longer since
60bd6842e4. Fix by changing the expected
result to contain a single ampersand instead of double.
