Simplify things by putting setup.h files themselves under version
control and getting rid of setup0.h ones.
The initial motivation for using separate setup0.h files was to allow
having local changes to setup.h, but with Git there is a simple way to
do it by using "git update-index --skip-worktree include/wx/msw/setup.h"
for example, so we don't really need setup0.h any more and dropping them
makes things simpler.
This macro replaces the deprecated __Verify_noErr defined in the SDK.
It is different from assert, as the expression given to the macro is
always evaluated and then, if the result is not zero, and asserts are
on, an assert containing a human readable message with the description
of the error code is triggered.
Closes https://github.com/wxWidgets/wxWidgets/pull/1973
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
Remove a lot of Mac-specific code from wxStatusBarMac in favour of using
shared wxStatusBarGeneric:
- Now that wxFRAME_EX_METAL aka NSWindowStyleMaskTexturedBackground
doesn’t affect text placement, there’s no reason for customized
DrawFieldText(). As a side effect of this removal, ellipsizing fields
is now supported.
- Remove customized DoUpdateStatusText() code that is no longer needed.
See https://github.com/wxWidgets/wxWidgets/pull/2160#pullrequestreview-563916013
Under MSW, don't set the state to State_Cancelled as soon as Cancel()
was called, as the request was still used from the other threads
afterwards, resulting in race conditions and crashes.
Fix this by just removing the SetState(State_Cancelled) call from the
main thread, as it was redundant anyhow. This also makes the behaviour
correspond to the documentation, which indicates that Cancel() works
asynchronously.
Also ensure, for all backends, that we actually cancel the request only
once, even if public Cancel() is called multiple times. This required
renaming the existing wxWebRequestImpl::Cancel() to DoCancel().
Instead of trying to mimic native statusbar background rendering in our
own code, use NSWindow setContentBorderThickness:forEdge: to extend the
border that is drawn by the system. This is the canonical way of doing
statusbars ("bottom bar") in AppKit.
The text is still drawn generically, but that's a much smaller issue
than trying to match the border gradient.
Don't force the application code to deal with wxObjectDataPtr<> or,
worse, calling {Inc,Dec}Ref() manually by hiding it inside the wx
objects themselves and giving the value-like semantics to them.
There should be no real changes in the behaviour, but the API does
change significantly. Notably, wxWebRequest is not a wxEvtHandler itself
any longer, as this would be incompatible with the value semantics, and
an event handler needs to be specified when creating it, so that it
could be notified about the request state changes.
Having wxWebSessionFactory part of the public API implies keeping
compatibility with the possible ways of implementing it which is too
restrictive for no good reason, so move this class to the private header
and don't document it nor wxWebSession::RegisterFactory() (which is now
private).
Refactor common code and also for upcoming accessibility from
wxCocoaOutlineView.
Part of #19003.
Co-Authored-By: Dimitri Schoolwerth <dimitri@schoolwerth.com>
WKWebView replaces
WebView on macOS (available since 10.10, deprecated since 10.14) and
UIWebView on iOS (available since 8.0 deprecated since 10.0).
Using WKWebView ensures future compatiblity and unifies the interface
used for iOS and macOS.
Remove automatic definition of wxUSE_WEBREQUEST depending on whether
wxUSE_WEBREQUEST_XXX are defined and follow the same approach as with
wxUSE_GRAPHICS_XXX, i.e. define wxUSE_WEBREQUEST_XXX as wxUSE_WEBREQUEST
by default instead.
Move wxUSE_WEBREQUEST_WINHTTP to wxMSW-specific file, it doesn't need to
be in common one (unfortunately this can't be done for the Mac-specific
wxUSE_WEBREQUEST_URLSESSION yet, because macOS-specific settings are not
injected into setup.h.in currently).
Also fix test for winhttp.h availability: it seems to be present in all
MinGW64 distributions, but not in MinGW32, so test for this and not for
gcc version.
Finally remove the now unnecessary test for macOS 10.9, as we only
support 10.10+ anyhow by now.
We need to adjust the indices of the currently selected items as we need
to keep the same items, not the same indices, selected after new items
insertion.
Closes#18902.
Update the width when items are expanded and collapsed and also take the
expander width into account.
Change m_ModelNotifier type to avoid casts when calling wxOSX-specific
method on it.
Closes#14939.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
This convenient method allows to expand all children of the item
recursively.
This is directly supported by both native implementations, so it makes
sense to have this in wxDataViewCtrl itself, even if it could be also
(less efficiently) implemented in the user code.
This requires refactoring NewCloseButton() in order to extract
CreateCloseButton() from it, as XRC relies on being able to use two-step
creation which was previously impossible for this kind of buttons.
CreateCloseButton() is rather unusual, as it has to be declared in the
derived, platform-specific class, in order to be able to call its
Create(), but is defined only once in common, platform-independent,
code. However the only alternative seems to be to have a static
function, e.g. InitCloseButton(), which wouldn't be very pretty neither.
Closes https://github.com/wxWidgets/wxWidgets/pull/2118
This is useless, all still supported compilers except ancient MSVS
versions (for which configure is not used anyhow) support variadic
macros, so don't waste time testing for them.
Note that the checks for HAVE_VARIADIC_MACROS in the sources are still
left because it is still possible to explicitly disable variadic macros
support using --disable-vararg_macros for strict C++98 compatibility.
Don't make many single-item selection adjustments in SetSelections() in
wxOSX and instead implement it with a single native call to
selectRowIndexes:byExtendingSelection:
This has a dramatic, orders of magnitude effect on this call's
performance when selecting many items: selecting 10 thousand items goes
from minutes of runtime and gigabytes of RAM to unobservable impact in
both.
Use a dirty hack to accommodate wxUniv by deriving wxRadioButtonBase
from wxCheckBox, rather than wxControl, there. This is not pretty, but
should be addressed by refactoring wxUniv code and in the meanwhile all
the other ports don't have to bother with using a template class
unnecessarily.
Now that we do have wxRadioButtonBase class, declare wxRadioButton API
methods as pure virtual in it, to force the derived classes to implement
them.
Also remove the outdated comment saying that there is no base class for
wxRadioButtons in different ports, this is not true any longer.
Draw wxTextCtrl focus ring natively on Mac.
Add wxWindow::EnableVisibleFocus() to explicitly control the focus ring
visibility if necessary.
See https://github.com/wxWidgets/wxWidgets/pull/2037
Add wxWindow::EnableVisibleFocus() for changing focus ring behavior on
macOS (currently not implemented elsewhere, although GTK+ has a
discouraged option to do it).
NSTextView doesn't display focus ring by default, which is why wxOSX
did draw it manually, but this behavior can be overriden since OS X
10.3 with NSView.focusRingType property.
The HITheme-based rendering suffered from a number of non-nativeness
issues:
- didn't respect macOS 10.14+ accent colors
- not animated as the native focus ring
- subtly different shape of the outline
- noticeably different outline shape on macOS 11
Remove NeedsFocusRect() and associated workaround for manually drawing
focus ring inside NSTextView (i.e. multiline text controls). This
private interface was only used for wxTextCtrl and nothing else, so
this shouldn't have any impact elsewhere.
