Discovered by an LLM as the result of "a targeted scan for common
misspellings, duplicated words, and nearby wording errors".
Reviewed and confirmed by a human.
Closes#27122.
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.
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.
Clarify that wxGridTableMessage notifications describe table changes
that have already happened and should be sent only after the custom
table updates its own data model.
Add an InsertRows() example showing the correct order and clarify that
insert/delete positions are the positions at which rows or columns
change.
Fixes#16508.
Closes#27081.
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.
`ON` is not valid for `wxUSE_LUNASVG` because it goes through `wx_add_thirdparty_library`. This requires: `builtin sys OFF`. In the build script, using `ON` will fail before it reaches lunasvg.cmake. So `builtin` is the only correct option.
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.
Clarify that wxToolTip::Enable() only affects tooltips set with
wxWindow::SetToolTip() under wxMSW, is not implemented in wxOSX or
wxQt, and is ineffective with GTK 3.10 and later.
Closes#27029.
When determining the size of a window, GetScrollbarSize() should be used
instead of using the metrics values because the function takes into
account the case of overlay scrollbars, which are used by default with
GTK 3, unlike the metric value.
Also update the documentation to recommend doing this.
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().
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.
Some cells may be editable but not accept text input, e.g.
wxGridCellBoolEditor handles some keys but only to set/clear/toggle the
checkbox it shows, and the IME should not be shown for them.
Avoid adding a new wxGridCellEditor::AcceptsTextInput() virtual function
by reusing the existing IsAcceptedKey() to probe for text input support:
we decide that if "a" is a valid key, then any text can be entered.
If this hack turns out to be too limiting or surprising, we can always
add AcceptsTextInput() later.
See #24558.
Add wxWindow::UpdateInputMethodCursorRect() which can be used to let the
IME know where to place its window and use it in wxGrid to show it near
the cell being edited.
See #24558.
Implement it in wxMSW, wxGTK and wxOSX.
This will be used to prevent IME window from appearing for windows that
currently don't accept keyboard input even if they accept focus.
Iterate over the animation manually to find the frame we need.
Update the sample to allow showing individual animation frames.
Closes#27009.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
Add support at wxPersistentWindow level for saving the DPI at which the
window coordinates were saved to allow rescaling the values by the ratio
of this DPI to the current one if the DPI has changed between saving and
restoring.
This allows keeping the same proportional size of the window after DPI
change on the platforms not using DPI-independent pixels (such as wxMSW)
too by just using the new {Save,Restore}Coord() functions instead of
{Save,Restore}Value() for any quantities that need to be scaled.
Do this for wxPersistentTLW to update the window size to remain
proportionally the same after DPI change.
The danger of losing data seems to outweigh any performance
considerations here, so do call fsync() before renaming the file to
ensure that the data is really on disk before overwriting the original
file.
See #25088.
The existing Flush() only called fflush() but this is not enough to
really flush the file to the disk.
We can't start calling fsync() from Flush() as this may significantly
slow down the existing code. We could add a separate Sync() but as it
almost always makes sense to flush the file before syncing it, add a new
function doing both at once instead.
Don't claim that it supports "renaming" to a directory because it does
not and never did, under any platform.
Also document the parameters to repeat that "newpath" must be a file.
Use MoveFileEx() as just about everybody else (Boost, Python etc) does
because this is the closest equivalent to POSIX rename().
This is a behaviour change compared to earlier 3.3.x series as
ReplaceFile() used until now (see #25089) preserved file attributes but
now we don't do it any longer -- but we provided CopyAttributesFrom()
which can be used in the application if it needs it.
Closes#26713.
Copy the target attributes that are easy to copy and make sense to
preserve under Windows too instead of only doing it under Unix in
wxTemp{F,}File and do it in a new wxFileName::CopyAttributesFrom()
function instead of duplicating the same code in both classes.
The new function can be potentially useful on its own, so make it public
and document it.
Add a unit test verifying that the attributes are preserved after
overwriting the file with wxTemp{F,}File.
Show "key tips", i.e. popup windows showing the key that can be used to
activate a ribbon element, and add support for using keys to do it to
improve accessibility.
Closes#26935.
This was broken by 48bf1ac (Rewrite event generation and propagation in
wxAuiNotebook, 2025-07-12), see #25634 and #25544.
Restore sending this event for the buttons and do it with the correct
page indexes now, i.e. using the logical page index and not its physical
position.
Also consistently allow the handler of this event to prevent the default
action from taking place if it doesn't call wxEvent::Skip(). This is not
100% backwards-compatible but is consistent and more useful.
Add a unit test checking that this works as expected.
Closes#26801.
This function is trivial but it's still better to have it than to
duplicate it in several different places.
No real changes, this is just a refactoring.
It does work in wxGTK3 and wxOSX now using wxOverlay, see fafc714057
(Use wxOverlay to show sash feedback in non-live resize mode in wxAUI,
2024-01-25).
See #26960.
Extra controls (including the file type filter choice) have been disabled
in sandboxed applications since the 2013-era workaround for #14906: the
native save/open panel runs out of process (Powerbox/NSRemoteView) and
inserting our views into its view hierarchy crashed.
The supported contract is to build the accessory view entirely in-process
and hand the finished NSView to -[NSSavePanel setAccessoryView:]; the
panel then hosts it safely even when remote. Do exactly that: create the
extra control and the filter panel as children of a hidden in-process
host window instead of parenting them to the (possibly remote) panel.
This makes extra controls and file type filters work in sandboxed
applications too. As a safety valve, a system option, which can be set
by the user by setting wx_osx_openfiledialog_disable_extra_controls
environment variable to 1, is provided to restore the old behaviour of
simply ignoring the extra controls.
Closes#26908.
PB
Maarten Bent
Vadim Zeitlin
Quin Gillespie
Randalphwa
Blake-Madden
Richard
ali kettab
Daniel Kulp