When compiling with g++ or clang in C++11 mode, the use of std::auto_ptr<>
triggers warnings about its deprecation, so replace it with wxScopedPtr<> as
this is simpler than choosing between auto_ptr<> and unique_ptr<>.
Not doing this prevented the tooltips from working correctly if the library
was shut down and reinitialized again, so add a module ensuring this is done.
Closes#17360.
When resizing a wxAuiToolbar, the overflow button always showed up, and the
SetOverflowVisible() doesn't work as expected. E.g.
tb->SetOverflowVisible(!tb->GetToolFitsByIndex(tb->GetToolCount()-1));
tb->Refresh()
This was caused by the logic in OnPaint() ignoring the m_overflowVisible flag
and always drawing (or not drawing) the overflow button.
Add a check for it to fix this.
Closes https://github.com/wxWidgets/wxWidgets/pull/212
Such strings are not really URIs as they should have been encoded if they were
but we can obtain them from e.g. wxFileSystem::FindFirst(), so handle them
correctly here as it's simpler than checking all the places where Unescape()
is called.
Add a unit test checking that decoding an URI containing both Unicode and
percent-encoded Unicode characters works correctly.
Since minimal.vcxproj file is shared by VS 2010-15 solution files, ToolsVersion value should be set to the value supported by all VS versions since 2010 to avoid warning messages like "Project file contains ToolsVersion="14.0", which is not supported by this version of MSBuild.".
After 4475fe36a5 there were ambiguities between
PROPERTYKEY and PROPVARIANT defined in the anonymous namespace and the global
header for the compilers that did define them, such as MSVC.
Fix this by not (re)defining PROPERTYKEY if it had been already defined and
not defining PROPVARIANT at all as it's used as PropVariantClear() parameter
in the beginning of this file, before it was defined by us, so it must work
for all the compilers already anyhow.
Some interfaces, notably IAutoCompleteDropDown, but also several other ones in
taskbarbutton.cpp, were defined inside anonymous namespace to avoid clashing
with the interfaces possibly (but not necessarily) declared in the standard
headers.
However gcc 4.9 is smart enough to realize that no classes deriving from a
class in an anonymous namespace can exist and so it devirtualizes the calls to
virtual methods of the objects of this type when compiling with optimizations
enabled. And it does it even if it means replacing the call to a virtual
method with just a call to __cxa_pure_virtual(), i.e. crashing during
run-time.
Prevent it from doing this by moving class declarations outside of the
anonymous namespace and fix the crash when using wxTextEntry::AutoComplete()
in the code compiled with g++ 4.9.
Since Windows 8 there are native toast notifications available via WinRT defined in windows.ui.notifications.h. This adds support for these notifications via wxNotificationMessage. These notifications have to be explicitly enabled via wxNotificationMessage::MSWEnableToasts() because they require a start menu shortcut to the application.
Some Windows8+ APIs are only accessible via WinRT which is based on COM. However there are a few dependencies to get to the interfaces via functions defined in roapi.h. Using RoInitialize, RoUninitialize, etc. directly from it's windows headers adds dependencies to the WinRT dlls leaving the resulting exe unable to launch on earlier Windows versions. The wxWinRT functions wrap this with dynamic loading. Additionally wxWinRT::TempStringRef adds a convenient wrapper to HSTRING which is used extensively in WinRT APIs.
wxNotificationMessage has been refactored to always use wxNotificationMessageImpl (this was previously already done in the MSW implementation)
This adds various features and fixes to wxNotificationMessage:
- OS X Notification Center implementation
- Generic "toast" notifications
- SetIcon() to specify a custom icon
- AddAction() to add actions to notifications
- Events to get notify of notification clicks, dismiss or actions
Due to recent changes in utils, stdpath and the removal of carbon, building on
OS X was broken by various compiler errors and linker issues.
Closes https://github.com/wxWidgets/wxWidgets/pull/210
MinGW-w64 (and apparently TDM too) defaults to using ANSI stdio functions
nowadays, which interpret format specifiers such as "%s" and "%c" in wide
string functions in the standard-conforming way, i.e. still expecting the
arguments of "char*" type, and not "wchar_t*" as MSVC and older MinGW did.
wxWindowID objects can be global and thus be destroyed after the library has
been uninitialized and, worse, when some of the global objects have been
already destroyed.
In particular, using wxLogTrace() in DecIdRefCount() called from the dtor
could result in using the possibly already destroyed wxConvLibc object, so
avoid this by not doing any tracing from there.
No real changes, just remove the nonsensical comment from wx/defs.h which
completely lost its meaning since wxWindowID typedef was replaced by a class 8
years ago in cf2810aa39.
In practice, almost everybody using validators also seems to use this style,
so make it the default (this hadn't been done when it was originally
introduced because of compatibility concerns, but now, 15+ years later, it's
probably safe enough to change this).
wxSYS_COLOUR_LISTBOXHIGHLIGHTTEXT is usually used on a darker background provided by wxRender::DrawItemSelectionRect so a light color makes sense. While wxSYS_COLOUR_HIGHLIGHTTEXT is used on a lighter blue shade where the dark color makes sense.
This adds an additional screen to the drawing sample showing all available wxSystemColour values. It makes sense for testing these values but also provides a convenient overview of available colours for the library user.
This seemed like a good idea many years ago when plenty of code (inside and
outside of wxWidgets) couldn't deal with the real alpha correctly, but this is
not the case since quite some time any more and producing an image without
alpha channel when loading a PNG image with transparency is more surprising
than useful now, so don't do it any more.
Closes#3019.
The implementation file for this control somehow wasn't used in wxGTK build,
fix this and, in fact, include it in common sources as there is only a generic
implementation of this control so far.
Closes#17309.
