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
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.
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.
Add a helper wxLaunchBrowserParams struct with clearly distinct "url" and
"path" fields and GetPathOrURL() accessor which returns whichever is
appropriate.
This makes the code more clear and ensures that we never pass URLs (but only
file paths) to xdg-open under Unix as it doesn't handle them.
See #17227.
