Change wxTreeCtrl style for a control used by wxGenericDirCtrl so that
wxGenericDirCtrl looks more like the folder view in File Explorer (but
still don't show expanders for root-level items).
Also update wxGenericDirCtrl screenshot in the docs.
See also 6caaf58 (Use more modern appearance for wxMSW wxTreeCtrl by
default, 2023-09-30).
Closes#23922.
Change wxTreeCtrl default style under wxMSW to make it look more
up-to-date by default: use twisting buttons and full-row highlight and
don't display connector lines.
Using wxTR_LINES_AT_ROOT together with wxTR_NO_LINES may look odd but it
is needed because without wxTR_LINES_AT_ROOT, the buttons would not be
displayed.
Also update wxTreeCtrl screenshot in the docs.
Closes#23844.
Make the wxString(std::string_view) constructor explicit.
Otherwise, when comparing a std::string_view with a const char *, the
cast to wxString will be considered as a candidate for the comparison,
ultimately causing an "ambiguous overload for 'operator=='" error.
For example, this sample only builds if the constructor is explicit:
#include <wx/string.h>
#include <string_view>
int main() {
std::string_view view = "abc";
const char *str = "abc";
return view == str;
}
However, making the constructor explicit will break assignment:
std::string_view view = "abc";
wxString s;
s = view; // Error: no match for "operator="
That we can fix by implementing operator=(std::string_view)
That, however, introduces another ambiguity:
std::string str = "abc";
wxString s;
s = str; // Ambiguous between s = wxString(str)
and s = std::string_view(str)
That we can fix by implementing operator=(std::string)
Finally, note that some rather obscure ambiguities remain, such as:
wxString s;
s = {"abc", 2}; // Ambiguous between s = wxString("abc", 2)
and s = std::string_view("abc", 2)
Avoiding them is not simple (https://cplusplus.github.io/LWG/issue2946)
and doesn't add much value.
Closes#23834.
Deprecate wxXmlResourceHandler::GetAnimation() function which returns
just a single animation and add a new GetAnimations() replacing it.
Use the new function in wxAnimationCtrl XRC handler to pass all the
animations defined in the XRC file to the control.
This reverts 5d630caabd (Make it enough to predefine only
wxUSE_DPI_AWARE_MANIFEST, 2023-08-23) and all the commits which tried to
fix the breakage caused by it.
While the original change had merit, it seems to be too difficult to fix
all our build systems to avoid embedding manifest when defining this in
the code, like samples/sample.rc does, so revert this change for now.
Maybe it can be reintroduced in the future after switching to some other
build system.
If this is predefined before including wx/msw/wx.rc, it clearly
indicates that wx manifest should be used, but this was _not_ the case
before as wxUSE_RC_MANIFEST could be predefined as 0 (which is the case
for MSVS, to avoid conflicting with the manifest embedded by it into the
executable by default).
Change this and do include the wx manifest if wxUSE_DPI_AWARE_MANIFEST
is defined.
This should help people who check out the repository without submodules.
It's a bit circular, as the target of the link links back to this page
itself, but doing anything else would require much deeper reorganization
that can't be done now.
Closes#23683.
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 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.
In the note about building wxWidgets with MinGW makefile and using
parallel build, explain that "-jN" option cannot be used when building
"setup_h" target.
Closes#23642.
Clarify that it is 1 by default in the documentation, instead of
implying that it's off by default and needs to be enabled.
Improve the description of this option in setup.h files.
And also document this compilation option in the summary page.
This symbol is similar to the existing wxNO_IMPLICIT_WXSTRING_ENCODING
and can be defined when building the application (as opposed to when
building the library) to disable implicit wxString conversions to
pointer types, i.e. char*, wchat_t* and void*.
This makes the just added wxUSE_CHAR_CONV_IN_WXSTRING library build
option unnecessary, so remove it.
wxString is always based on std::[w]string since 2c0c727f49 (Remove wx
own wxStringImpl implementation, 2022-11-16) and all containers use
standard containers by default too now -- and there is a separate
wxUSE_STD_CONTAINERS for this anyhow.
The only remaining use of wxUSE_STL was as the default value for
wxUSE_STD_STRING_CONV_IN_WXSTRING option, but it's not really needed
for this neither, and this option can just be set to 0 by default.
Also add wxUSE_CHAR_CONV_IN_WXSTRING which can now be set to 0 too to
disable all unwanted implicit conversions (even "safe" ones, to wide
strings, in addition to the unsafe ones to narrow strings that could be
already disabled with wxUSE_UNSAFE_WXSTRING_CONV) to allow people who
don't want to have any implicit conversions at all to do it.
Keep --enable-stl configure option for compatibility, but warn if it is
used to tell people that it is not needed any longer.
This is intentionally not very detailed, as we might find more container
classes to change in the future and listing all of the affected ones
here would require updating this list later.
Explain that the legacy container classes now inherit from the standard
classes by default and also how to update the existing code to compile
when using standard library-based implementations.
Add a convenient @since_wx alias which is more appropriate for
single-line comments than the standard @since, which would expand into
two paragraphs.
See #23426.
This function was not called any longer after 35a8d0f908 (Fix building
wxPropertyGrid with v3.0 compatibility enabled, 2023-03-22), which
silently broke any applications resulting on this to happen, so call it
again, even if it's rather painful and ugly to do.
Also add wxDEPRECATED_BUT_USED_INTERNALLY_MSG() and use it instead of the
plain wxDEPRECATED_MSG() for the deprecated overload of this function to
avoid warnings when calling it from wxWidgets itself.
Finally, document the change to DrawCaptionSelectionRect() as this
wasn't done back in c63b1604b3 (Use native renderer to draw rectangle
indicating that wxPG category property is selected., 2015-08-30) when
its signature was changed.
Although @see was used predominantly, a few places used @sa which is
equivalent to it but less readable, so switch to using @see everywhere.
No real changes.
This prevents wxGLCanvas from working on limited OpenGL implementations
not providing it, such as VMWare OpenGL driver, and doesn't seem to be
really necessary as multi-sampling can always be explicitly requested if
the application does want to use it.
Closes#23121.
Historically, we used to fall back on any locale using the same
language, if the exactly requested locale was unavailable. This doesn't
seem such a great idea, and results in unexpected behaviour, such as
returning true from wxUILocale::IsSupported() for locales such as
"en-FR" that are not really supported at all.
Remove this fallback and just return false if the locale with the
specified region is not supported.
Still choose any supported region if the region is omitted entirely,
however.
This is a generalization of the existing "platform" attribute and allows
to only include some XRC elements if and only if an arbitrary "feature"
is enabled by the application before loading the XRC document.
This architecture doesn't exist and is not supported since a very long
time, so stop testing for it and defining __ALPHA__ which was never used
anyhow.
It may still be supported for wxGTK, but we don't need to do anything
special for it, so we don't need to define __POWERPC__, which was never
used anyhow, neither.
This macro was documented (in its comment) and even used with a
semicolon after it, but it didn't require one and using one after it
resulted in a warning with gcc in pedantic mode.
Change the macro definition to use wxSTATEMENT_MACRO_BEGIN/END to
require (and, trivially, also allow to be used without warnings) a
semicolon after it now.
