SetIncrement() was already available in wxSpinCtrlDouble and GTK version
of wxSpinCtrl, now implement support for it in wxMSW and wxOSX as well.
In fact, in wxMSW, implement it at wxSpinButton level, so that both this
class and wxSpinCtrl inheriting from it (in wxMSW only) support setting
custom increment now.
Also add support for it to XRC, show it in the sample and add a unit
test verifying that it works.
Closes#2597.
Handle selectors corresponding to key presses, such as cancelOperation:,
ourselves because we never get the keyDown events that are supposed to
take care of generating it from the native code somehow.
This fixes cancelling editing with Escape which stopped working since
26d6f82a81 (Implement EVT_CHAR generation for wxDataViewCtrl under Mac,
2021-04-13).
Closes#17835, #2639.
Co-Authored-By: Stefan Csomor <csomor@advancedconcepts.ch>
Allow specifying multiple formats to be accepted when dragging data to
wxDataViewCtrl in the generic and Cocoa implementations.
Add wxDataViewCtrlBase::EnableDropTarget() overload taking an array of
wxDataFormats to support this at the API level.
Add new DoEnableDropTarget() used by both EnableDropTarget() overloads
and implement it in the generic and Cocoa ports. GTK implementation
still uses only a single format, as before.
Also refactor the Cocoa implementation: all operations using dragged
data are now handled by wxDropTarget and unnecessary DataViewPboardType
as removed.
Update the dataview sample to show the new functionality.
Take wxBitmapBundle in wxButton::SetBitmapLabel() and related functions
in order to be able to associate several bitmaps to be used in different
resolutions with the button, instead of just a single bitmap.
This allows each control have its own undo history, independent of the
other ones, as expected by the wx API, rather than using an undo manager
shared by all controls in the same TLW.
wxWidgetCocoaImpl injects implementation of several
NSDraggingDestination protocol methods, but never called their base
implementations, presumably on the assumption that drag and drop is
explicitly supported and not builtin into native NSView-derived
controls.
This prevented native builtin d'n'd in e.g. NSTextView (text can be
copied and inserted by dragging it to the insertion point) from
working. Fixed by always calling base implementation.
Closes https://github.com/wxWidgets/wxWidgets/pull/2320
Send a wxFullScreenEvent when the user enters or exits full screen on
macOS. EnableFullScreenView() has to be used to enable the native
full screen API.
Closes https://github.com/wxWidgets/wxWidgets/pull/2284
Calling wxWindow::SetForegroundColour() also changed the window font,
which was unexpected and unnecessary.
Add a separate peer SetForegroundColour() method and implement it to
change just the colour in Cocoa version (and leave unimplemented, just
as it was before, for iOS) and use it in wxWindow to avoid the font
change.
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.
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.
Provide API for dealing with m_lastKeyDownEvent instead of using it
directly and extend it to avoid sending duplicate events for keys which
are mapped to multiple selectors, such as Ctrl-O with the default key
bindings.
Closes https://github.com/wxWidgets/wxWidgets/pull/1928
We can't handle the accelerators (known as "key equivalents" in Cocoa)
in this function because it is called for the views in top to bottom
order, while wx semantics is for accelerators to be handled in the
accelerator table closest to the focused window.
So just remove this code and rely on accelerator handling happening in
wxWindowMac::OSXHandleKeyEvent() instead.
Closes#13937.
The advantage of using this compiler builtin instead of our own platform
checks is that the compiler will warn us (if -Wunguarded-availability is
turned on for APIs introduced before 10.13 or by default for later ones)
if a check is forgotten, which is not the case for the manual checks.
Update the code to use WX_IS_MACOS_AVAILABLE() macro, which expands to
__builtin_available() when supported, and also use API_AVAILABLE() where
it makes sense to avoid having too many checks.
No real changes, just clean up sources by removing trailing spaces from
all the non-generated files.
This should hopefully avoid future commits mixing significant changes
with insignificant whitespace ones.
NSOpenGLView is needed under 10.14 as a native view, but it doesn’t have its own native key handling, therefore use the same code we have for non-native custom views.
When wxColourDialog is shown, any changes to the colour selected in it
apparently result in broadcast messages to all currently visible text
controls, which was unexpected.
Block the changeColor: message to prevent this from happening.
Closes https://github.com/wxWidgets/wxWidgets/pull/830
The system color functions depend on the current appearance, this is not automatically set to the effective appearance (that can be changed during runtime via the system preferences), added a helper class to make sure the correct version is used for retrieval.
When having a certain creation sequence, these popup windows were not focused correctly, see https://github.com/wxWidgets/wxWidgets/pull/672 , commit d2265136e359df4d14054860a68bbc7f4910279d , revert this change if problems arise to see whether this is a recursion
This decreases the speed of access to this struct (which shouldn't
matter that much) but avoids allocating an extra and almost always
unneeded pointer for each and every window, which seems like a good
trade-off.
Don't request touch event generation for all windows by default, this
has an inherent overhead and is not needed for 99% of the application
windows, so require calling EnableTouchEvents() explicitly to do it
instead.
Note that this requires properly initializing gesture recognizers in
wxOSX now that they're not always allocated, otherwise releasing them
when destroying the window would crash.
Improve the logic for determining whether the statusbar should be
renderer as for active/key window or a background one.
wxTopLevelWindow::IsActive() is not a sufficient test because it returns
false in some situations when the statusbar need to appear as active
(another floating window) and also didn't account for window-modal
sheets (which don't change statusbar appearance either).
Allow to disable maximize and minimize buttons dynamically just as we already
allow to disable the "Close" button using EnableCloseButton().
Currently implemented for MSW and OSX only.
Closes#17133.
