This is the standard and there doesn't seem to be any contemporary
systems where this is not the case. The configure check for it was
originally added in 101c20d554 (attempting to fix sa_handler signature
for IRIX, 2000-04-01), but IRIX is not supported/doesn't exist any
longer, so don't waste time on checking for this.
The real motivation for this change is that the test failed in CMake
builds, showing just
-- Performing Test wxTYPE_SA_HANDLER_IS_INT - Failed
in the log and then resulting in -fpermissive warnings when assigning
wxFatalSignalHandler to sa_handler and it's simpler to just remove the
check than to debug it.
See #23664.
Return the disabled bitmap and not the normal one.
This fixes a regression introduced in 9a5123afed (Use wxBitmapBundle in
wxAuiToolBar and wxAuiPaneInfo too, 2021-11-14).
Closes#23666.
It doesn't make sense to keep the old and almost never used alternative
wxClipboard implementation which has known fatal bugs (such as casts of
wxDataObject that could be wxDataObjectComposite to wxBitmapDataObject,
see #23564) when wxUSE_OLE is never going to be disabled anyhow.
Note that this means wxSetClipboardData() function doesn't exist at all
any longer when previously it was available in the wxUSE_OLE==0 builds.
As the official builds always used wxUSE_OLE==1, this doesn't look like
a huge loss, but if needed, we could add it back later and reimplement
it in terms of wxClipboard::SetData().
This function should be used to get the parent for the custom controls
instead of relying on them being reparented under it by the code added
in the last commit.
Change the type of m_contents to be wxWindow and not wxPanel as it
doesn't really matter, but wxPanel is not fully declared in this header
while wxWindow is.
This avoids crash if wxVSCROLL or wxHSCROLL is used with wxGLCanvas
which calls wxWindow::Create() after calling DontCreatePeer() because
the Create() tries to use the not (yet) existent peer in
MacCreateScrollBars().
Avoid this problem by moving the call to MacCreateScrollBars() to
MacPostControlCreate(), which doesn't change anything for the windows
that do not call DontCreatePeer(), but ensures that the peer already
exists by the time MacPostControlCreate() is called for those that do.
Closes#23536.
It doesn't seem like it is meant to be overridden, so don't imply that
it should be possible to do it and make it non-virtual.
Also rename to DoTranslateBorder() to make it more clear that this is a
private function and not part of the public API.
Finally, improve its comment and never return wxBORDER_THEME from this
functions if themes support is off.
This function was added back in a047aff270 (Added wxBORDER_THEME,
wxWindow::GetDefaultBorderForControl(), wxWindow::CanApplyThemeBorder(),
2007-08-07) but seems to have been made completely unnecessary by
dc797d8e1b (More border rationalisation. GetDefaultBorder is now mostly
defined in base class files., 2007-11-13) soon afterwards and never did
anything other than returning wxBORDER_THEME, with no explanation as to
when it might be useful to override it not to do it.
It also doesn't seem to be really used anywhere outside wxWidgets and
has never been documented, so make it non-virtual and deprecate it to
avoid confusion and simplify things.
Avoid implicit copy constructor warnings by using
wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN_DEF_COPY/wxDECLARE_NO_ASSIGN_DEF_COPY
instead of wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN.
Closes#23625.
Closes#23626.
This reverts commit cd637663c8 (Add wxWindow::MSWAfterReparent() virtual
function, 2022-10-16) and removes wxListCtrl::MSWAfterReparent() added
in ff629f3853 (Fix drawing wxListCtrl since enabling double buffering by
default, 2022-10-16) which is not used any more now.
The old API allowed for users to directly test the variable and find if
it was null, so recreate that API with the new system to preserve
compatibility.
Closes#23445.
These functions are more convenient to use and, arguably, more clear to
read than calls to ::GetThemePartSize(), so add these wrappers and
replace most of the uses of the Win32 function with them.
This shouldn't result in any real changes to behaviour.
This is sightly shorter/more convenient to use than providing all the
parameters to ::DrawThemeBackground() every time.
Similarly to ca5f244f15 (Add wxUxThemeHandle::GetColour() replacing
MSWGetThemeColour(), 2022-12-09), this is just a refactoring which
shouldn't result in any changes in behaviour.
Use OpenThemeDataForDpi() if necessary to retrieve the correct metrics
values for non-default DPI.
Change the existing wxUxThemeHandle ctor taking wxWindow to use the
window DPI automatically and replace the ctor taking HWND with a pair of
functions either explicitly specifying the DPI or indicating that it is
not used -- the latter can be useful to avoid unnecessary complications
when the theme is only used to retrieve some colour values that don't
depend on the DPI anyhow.
Also make wxUxThemeHandle class movable as a side, but possibly useful,
effect of these changes.
wxPG_PROP_ACTIVE_BTN and wxPG_PROP_SHOW_FULL_FILENAME can be used together
(like e.g. in wxFileProperty) so they can't share the same value
(wxPG_PROP_CLASS_SPECIFIC_1).
Closes#23565.
Initialize at least boolean members when they are declared to ensure
that we don't forget to do it later (see #23593).
The other ones are already initialized later, normally, so don't touch
them for now.
No real changes.
Move the check for multi-threaded COM apartment into a new helper
function and use it from both wxFileDialog and wxDirDialog, which should
be subject to the same problem.
Remove the Init() helper initializing all members as we can now do it in
their declarations instead which is even better.
Also drop Free() which existed mostly for symmetry with Init().
As a side effect, this change allows to include this header from outside
the library (e.g. from the tests code), while previously it would result
in the following warning from gcc:
‘void wxDIB::Init()’ redeclared without dllimport attribute after being
referenced with dll linkage
No real changes, just don't say that this function calls CoInitialize()
because this is not the case any longer, and do advise using the RAII
wrapper instead of calling it directly.
Implement wxUILocale::GetMonthName() and wxUILocale::GetWeekDayName() in
wxMSW, wxGTK, and wxOSX.
Also extend the existing wxDateTime methods to support a 3rd month and
weekday name representation (Name_Shortest) and a usage context
(Context_Formatting and Context_Standalone).
These changes make wxDateTime methods for getting the localized date and
month names use the current UI locale, as set by wxUILocale, instead of
the current C locale set by the standard C library function, which is a
change in behaviour but a desired one and notably fixes the display of
the months in generic calendar control in wxOSX where the current C
locale is not changed when the UI locale is set.
Replaces #23551.
Closes#23191.
This macro was mentioned in the docs added by 0ff1bdec09 (Add
wxFullScreenEvent for macOS, 2021-03-18), but its implementation was not
added by said commit.
Closes#23566.
Disabled static controls looked ugly as greying out the label doesn't
work at all when the background is dark, so override their drawing in
this case and just draw them using the same grey-ish colour that is
already used for the disabled menu items.
This is somewhat of a hack, but doesn't seem to have any bad effects and
is much simpler than using owner-drawn controls.
This reverts changes to one of the arrays in 39706e4db0 (Use wxBaseArray
instead of object arrays in wxAuiManager, 2023-04-11) as this array is
returned by wxAuiManager::GetPane() and the existing code relies on the
references to the elements of this array remaining stable even if the
array is modified, which would be impossible with an array storing the
objects directly, so return to storing heap-allocated pointers to it.
There should be no such problems with the other arrays changed by that
commit, so leave them unchanged.
Closes#23545.
The wxThreadSpecificInfo object created by wxThreadSpecificInfo::Get()
was only released by the wxThreadInternal's cleanup, which meant that it
was leaked if wxThreadSpecificInfo::Get() was called by a thread not
created by wxThread, e.g. when using std::async or std::thread.
Fix this by simply using C++11 thread_local and removing the entire
wxThreadSpecificInfo machinery entirely.
See #23535.
Closes#23543.
Set LIS_DEFAULTCOLORS to allow the already existing code calling
SetForegroundColour() in wxGenericHyperlinkCtrl to work.
Changing the foreground colour has an unfortunate side effect of also
changing the colour of the focus rectangle, but it doesn't seem possible
to avoid this.
