Lifetime of wxPrinterDC created in BeginPrint() handler (associated with
"begin-print" signal) is limited to the current print job and therefore
this object should be destroyed when the actual printing is finished.
See #14233.
GetPrintDC() should return a new device context created by the print
dialog, not the duplicate of existing context passed from the caller
(e.g. from wxGtkPrinter) through SetPrintDC(). Therefore SetPrintDC() is
no longer useful and can be removed.
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.
