The recent 07590bec33 (Use preceding label as accessibility title of
controls under macOS, 2026-09-21) started calling GetLabel() from
MacPostControlCreate() which is called before the object was fully
constructed and could (and did) result in crashes due to the use of the
not yet initialized members.
Avoid this by adding a new HasAccessibilityTitle() virtual function of
wxWidgetImpl which is fully constructed by the time this function is
used and also addresses the question of whether the preceding label
should be used as this window accessibility title more precisely.
See #27060, #27140.
Closes#27142.
wxAuiFloatingFrame could receive wxEVT_SIZE during its destruction, even
if it was already hidden, and handling these events crashed due to
dereferencing dangling wxSizerItem pointers.
Fix this by overriding wxAuiFloatingFrame::Destroy() to perform the
necessary cleanup when the frame is about to be destroyed.
Add wxAuiManager::DestroyFloatingFrame() helper which makes the code say
more clearly what it does -- this is not required to fix the bug but
affects the same code, so do it in the same commit.
Also add a unit test confirming that destroying the floating frame in
various ways doesn't crash any longer.
Closes#26264.
Originally-by: alilie <alexandru.ilie@hexagon.com>
wxAuiNotebook's wxAuiManager is only an implementation detail used for
its tab frames, plus the hidden dummy pane created during initialization.
Reject attempts to add arbitrary windows to it instead of making notebook
code tolerate such panes.
Update the AUI test to cover the narrower contract by checking that an
external non-tab pane is rejected and not registered with the manager.
Fixes#4771.
Closes#26902.
Refactor pasteboard code for reuse in dnd.
Improve setting flags for file objects.
See #27047.
Closes#27117.
Co-authored-by: Stefan Csomor <csomor@advancedconcepts.ch>
Extract code duplicated in wxWidgetCocoaImpl::SetAccessibilityLabel()
and SetAccessibilityTitleElement() into a new function.
No real changes.
See #27056, #27060.
Under MSW, screen readers use the label preceding a control without its
own label, such as wxChoice or wxTextCtrl, as its name, so dialogs are
accessible without doing anything special. Under macOS this didn't
happen, and VoiceOver only read the labels as separate texts, so users
tabbing through a dialog didn't hear what the controls were for.
Now, when a native control without its own label is created right after
a wxStaticText, the label is set as its accessibility title element,
which VoiceOver reads as the name of the control. Notice that for most
controls the accessibility element is the cell and not the view itself,
so this uses NSAccessibilityUnignoredDescendant() to link the elements
actually used by VoiceOver, and uses the document view for the controls
inside a scroll view.
Closes#27060.
The new function allows to set the name used by screen readers for any
window, e.g. for buttons showing only a bitmap or text controls without
a label before them.
Implement it for wxMSW and wxOSX and add documentation and a MSW-only
unit test.
Closes#27056.
Handle double-clicks on wxAuiFloatingFrame by docking the pane back to
its saved dock position when the pane is still dockable. On MSW, handle
the native caption double-click message so the outer title bar redocks
instead of falling through to frame default handling.
Add coverage for the MSW non-client title-bar path and the resulting
manager state transition.
Fixes#10004.
Closes#27083.
Using wxBitmapBundle means SVG files can now be used, multi-resolution
bitmap bundles can be used, scaling for high DPI now uses scaling code
for bitmap bundles which generally provides better scaling results.
Also add support for loading SVG images from wxInputStream and use to
implement support for compressed .svgz files.
Closes#26474.
Gallery items have just a bitmap, an ID and the application's client
data, so there is nothing a screen reader can announce for them and they
are read as "list item 3 of 39", which is useless.
Add Append(bitmap, id, label) and Set/GetItemLabel() and use the label
as the accessible name of the item. The label is not drawn, as the items
of a gallery are bitmaps by design, it only exists to be announced. It
could also be used for tooltips later, which the items don't have
either.
The ribbon sample already knows the names of the colours it puts in its
galleries, so it passes them as the labels now, which also makes them a
useful test case.
Closes#27100.
The search menu could only be opened by clicking the button showing it,
which doesn't accept focus from the keyboard on purpose, so keyboard and
screen reader users couldn't use it at all.
Handle Alt-Down in the text part of the control and show the menu from
there, as suggested in the comments of the original ticket.
Fixes#18457.
Closes#27093.
Use the new API, i.e. call ClaimsKeyBeforeAccelerator() and send
wxEVT_ACCELERATOR_KEY, in wxQt too.
Update wxComboBox to override ClaimsKeyBeforeAccelerator() too.
Note that wxTextCtrl and wxSpinCtrl don't need to be modified because
they already do this in the base class.
This actually simplifies the existing code as we don't need
wxWindow::m_processingShortcut any more.
Use the new API, i.e. call ClaimsKeyBeforeAccelerator() and send
wxEVT_ACCELERATOR_KEY, in wxOSX too, whenever possible, i.e. not for
Cmd-Letter used by the menu items as we never get key events for them at
all.
This probably could be worked around by overriding performKeyEquivalent:
but for now leave it like this because hopefully there should be no
conflict between menu accelerators and standard text editing keys as
Cmd+C etc act on the focused window anyhow by default, so the behaviour
should be already correct anyhow.
When deciding whether a key press should trigger an accelerator or be
handled by the currently focused window different ports behaved
differently, with wxGTK always prioritizing the focused window and the
other ports giving priority to the accelerator, and neither of them
allowed customizing this.
Change this now by introducing 2 ways to do it: first, a window can
override new ClaimsKeyBeforeAccelerator() virtual function to specify
which keys it wants to handle itself, even if they correspond to an
accelerator. And second, send wxEVT_ACCELERATOR_KEY event which can be
handled by the application, typically centrally in its wxFrame-derived
class, to decide if it wants some accelerator that it defines to not
steal the key from the window or, on the contrary, to always do it, even
if the window overrides ClaimsKeyBeforeAccelerator() as wxTextCtrl does.
Note that while ClaimsKeyBeforeAccelerator() replaces some uses of
wxMSW-specific MSWShouldPreProcessMessage(), but it's still needed to
prevent the key getting eaten by IsDialogMessage().
This is not a backwards-compatible change as it changes the default
wxGTK behaviour, but it is now compatible with the other ports and can
be easily customized if necessary.
This commit only implements this for wxMSW and wxGTK, other ports will
be updated too soon.
The list of the keys which are used for editing the text and which
shouldn't be taken by the accelerators using the same keys existed only
in wxMSW and only as a function taking a MSG, move it to the common code
as wxTextEntryBase::IsUsedForEditing() taking wxKeyEvent, as it is going
to be needed by the other ports too in the upcoming commits.
Note that this also slightly changes wxMSW behaviour because the keys
producing printable characters, as well as Backspace, are now considered
as being used for editing too and so are not passed to the accelerators
any longer, which seems more correct as typing text in a control
shouldn't trigger the accelerators using the same keys.
It was previously available only in the generic version which was used
by wxGTK and wxUniv, add it to the other ports too as it's going to be
needed in the upcoming commit.
In wxMSW this required storing the accelerators, as it is simpler than
converting them back from the native HACCEL and more consistent with the
other ports that already did this.
Add the new function checking if a (key) event and wxAcceleratorEntry
correspond to the same key combination.
This was already used in the generic wxAccelerator implementation and
wxOSX and will be used in the other ports too soon, so move this code
into common function.
It can also be useful for the applications, so document it as well.
In wxMSW, single line read-only wxTextCtrl doesn't accept focus from
keyboard, so keyboard and screen reader users can't Tab to it and read
its contents.
Add wxWindow::EnableFocusFromKeyboard(), the counterpart of the existing
DisableFocusFromKeyboard(), to let the application allow this.
Update the documentation and add a wxMSW-only unit test.
Fixes#10760.
Closes#27054.
MSW cross-builds / wxMSW 64 bits not compatible (push) Canceled after 0s
MSW cross-builds / wxMSW/Univ (push) Canceled after 0s
MSW cross-builds / wxMSW 32 bits (push) Canceled after 0s
Code Checks / Check Spelling (push) Canceled after 0s
Code Checks / Check Whitespace (push) Canceled after 0s
Code Checks / Check Mixed EOL (push) Canceled after 0s
Code Checks / Check C++ Style (push) Canceled after 0s
Code Checks / Check All Headers In allheaders.h (push) Canceled after 0s
The generic collapsible header, used by wxCollapsiblePane and so by the
generic about dialog, had two problems for keyboard and screen reader
users under MSW:
- Pressing Enter on the header activated the default button of the
dialog. In wxAboutBox this closed the dialog. Enter now toggles the
header, the same as Space.
- Screen readers could not tell what the header was or if it was open.
It now reports itself as a button with an expanded or collapsed state,
sends a state change event when it toggles, and has a default action.
This also stops screen readers from reading the label twice.
Closes#27048.
When the generic wxInfoBar showed a message, screen readers said
nothing, so their users did not know it had appeared.
The info bar now has the alert accessible role with the message as its
name, and sends an alert event every time ShowMessage() is called. NVDA
reads the message when it is shown, and also when a new message is shown
while the bar is already visible.
Closes#27053.
The generic wxInfoBar was a plain wxControl, not a container, so Tab
gave focus to the info bar window itself and never moved to the close
button or other buttons inside it.
wxInfoBarGeneric now derives from wxNavigationEnabled, the same as
wxGenericCollapsiblePane, so Tab moves to the buttons inside it.
Closes#27052.
Buttons that show only a bitmap have no label, so screen readers only
announce them as "button". This affects, for example, the buttons of
wxEditableListBox and the close button of the generic wxInfoBar.
When a button has no label but has a tooltip, its tooltip is now used as
its accessible name. Buttons with a label are not changed.
Closes#27051.
Implement DoGetBestClientWidth() so that the control can compute the
appropriate width when its height is known, as is the case when it's
used as wxTreeBook controller: this prevents the appearance of ugly
and unnecessary horizontal scrollbar in this case.
Add a unit test checking that the best size is computed correctly.
Closes#26097.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
Change wxRichTextEvent::m_char to be of type wxUniChar and not wxChar.
This is mildly backwards-incompatible but the break is arguably worth
not adding some new GetUnicodeCharacter().
wxChar can't hold all possible characters under MSW, so prefer using
wxUniChar even if it's not clear if this have any practical benefits in
this particular case.
Recombine the 2 WM_CHAR messages we receive for high and low surrogate
pair into a single Unicode character which can be retrieved using the
new wxKeyEvent::GetUnicodeChar() member function.
Update documentation and comments to recommend using the new function
instead of GetUnicodeKey().
Also update the keyboard sample to use it to be able to show events for
supplementary characters under MSW.
Closes#25135.
Vadim Zeitlin
Richard
Maarten Bent
Alexey ShelaevandStefan Csomor
Quin Gillespie
Randalphwa
Blake-Madden
Avery King
Steve Cornett
Robert RoeblingandVadim Zeitlin