No real changes, just explain the real reason why we can't create the windows
with the correct sizes and need to set them later (it's not because of the
font but because UDM_SETBUDDY changes them) and also use a helper
"effectiveSpinWidth" variable.
wxSpinCtrl created at the given position was always placed at (0, 0) instead
since 05b980aba1 ("Fix wxMSW wxSpinCtrl
appearance: show arrows inside the control").
Fix this in the minimally intrusive way for now by just putting it at the
right position instead of using hard-coded (0, 0) which was done before for
some reason.
See #12297.
Follow up to 60bd6842e4. Apply equivalent
changes to wxMarkupToAttrString, add a new wxItemMarkupToAttrString
class for mnemonics-less strings and use it in wxDataViewTextRenderer.
Also, remove the other calls to PKG_PROG_PKG_CONFIG which are then no longer
necessary.
This ensures that all PKG_CHECK_MODULES() calls work correctly and, in
particular, fixes detecting cppunit under macOS and, due to this, Travis CI
build.
IUnknown interface is used sometimes (e.g. in WinRT implementation of
wxNotificationMessage) alone, without other OLE routines, so it is
helpful to have its code in the separate file to avoid coupling with main
OLE code when only IUnknown implementation is required.
When using -jN, setup_h needs to be created first to avoid a bug due to
missing dependencies in the current makefiles which breaks the build
otherwise.
Use dedicated macros to declare and define IUnknown interface in the helper
class of wxNotificationMessage implementation.
Now dependency on wxUSE_OLE is more visible, since these macros are defined
in oleutils.h (see f2e707f095).
WinRT implementation of wxNotificationMessage requires wxUSE_OLE because
one memeber variable is of type wxAutoULong which is defined in the OLE
utilities collection (oleutils.h).
Library itself can be built successfully when wxUSE_DRAG_AND_DROP==1 and
wxUSE_OLE==0 but several wxDropTarget functions (referred in wxWindowMSW,
wxTextDropTarget, wxFileDropTarget) are reported as missing during linking
the application.
Dedicated wxDataObject::SetData() function can be used to import raw
clipboard data to the corresponding instances of wxDataObject and hence
there is no need to duplicate data retrieval code.
When HBITMAP is assigned to wxBitmap with SetHBITMAP(), internal data
member representing wxBitmap's color depth should be set afterwards to
the bitmap color depth, not to the number of planes.
wxRect to draw the background was prepared in a wrong way if wxDataView had
vertical or horizontal rules.
Fix this by adjusting the correct component of the rectangle when using
horizontal rules and by fixing an off by one bug when using vertical ones.
Reorganize the code by putting OLE-dependent code into the blocks
controlled by wxUSE_OLE and by sharing remaining code (like implementation
of wxDataFormat, wxBitmapDataObject, wxFileDataObject, etc.) to allow
building wxDataObject and its specializations also without OLE support.
Since wxDataObject no longer requires OLE support, corresponding check in
checkconf.h can be removed.
Thanks to this additional flexibility, it is possible to use wxClipboard
whether OLE support (wxUSE_OLE) is enabled or not, either with OLE-based
wxDataObject (OLE clipboard) or with wxDataObject decoupled from OLE (Win
clipboard API).
wxMetafileDataObject is a specialization of wxDataObject and its
compilation should be controlled directly by wxUSE_DATAOBJ (like it's done
under wxOSX, see e.g. include/wx/osx/metafile.h), not by
wxUSE_DRAG_AND_DROP.
Some wxWindowBase functions were marked deprecated prior to wx 3.0 release
and therefore they should be inserted into WXWIN_COMPATIBILITY_2_8 blocks
to mark them for removal in a future wx version.
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.
