Handle "bitmap" and "bitmapposition" attributes in wxToggleButton XRC handler,
just as it's already done for wxBitmap and wxBitmapToggleButton.
Closes#17850.
Stroke the path of the shape only if pen using in drawing is
non-transparent. Otherwise, the shape would have a visible border even for
transparent pen.
Generic implementation from wxDCImpl doesn't work well with wxPrinterDC
under wxGTK.
(This implementation is adopted from wxCairoContext::GetPartialTextExtents.)
It can happen that an application using wxWidgets doesn't actually use it,
e.g. because it runs in the console mode and doesn't need the GUI stuff. In
this case, g_wxAnyValueTypeGlobals was leaked because the cleanup function of
the module, which is supposed to clean it up, was never executed.
Fix this by making this pointer a smart pointer, thus making sure that the CRT
cleans it up even if we don't. We still do it from the module OnExit() to
account for the possibility of initializing and shutting down the library more
than once.
Ensure that checking for dialog modality in wxEVT_INIT_DIALOG handler returns
true when the dialog is being shown modally in MSW and GTK.
Add a unit test checking that this is the case.
Closes#10385.
UpdateStyle() function was introduced in edccf428 to synchronize in
SetWindowStyleFlag() style of the control with new style flags just stored
in m_windowStyle.
In 9a8d75f1, storing directly a new flags in m_windowStyle was replaced by
the call to parent's SetWindowStyleFlag().
Because call to parent's SetWindowStyleFlag() updates both m_windowStyle
and actual style of the control for common flags (WS_*, LVS_* flags),
synchronizing the control again with UpdateStyles() is pointless (since
this function does nothing in this context).
Only wxSCROLL style flags need special care because wxListCtrl doesn't
have these styles but the control itself may have them. In order
to preserve them in the call to SetWindowStyleFlag(), we can do the trick
and request the same new scroll style as the actual physical style.
UpdateStyles() is useless now and can be deprecated.
See #17059.
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.
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.
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).
Since being able to access the 64 bit registry from 32 bit code and vice
versa (a5c468483d) the updated code in wxRegKey::DeleteKey hasn't worked
properly for keys that are redirected. It is for example not possible
from 32 bit code to delete keys from the 64 bit view of (parts of)
HKLM/SOFTWARE/ . And in 64 bit code it's not possible to delete keys
from the 32 bit view of HKLM/SOFTWARE/ which is at
HKLM/SOFTWARE/WOW6432Node/ . Fix by trying to call the correct DLL
function (RegDeleteKeyExW or RegDeleteKeyExA), instead of non-existing
RegDeleteKeyEx.
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.
