There is no need to check that the rectangle fits as it's done by wxGrid
itself, so just use a single wxRect::CenterIn() call instead of several
lines doing it manually.
No real changes.
Don't make it larger than 150% than its normal width and also don't make
it larger than its normal width at all if it's not going to be large
enough to cover the entire cell anyhow -- this just looks strange, as
the editor is both too wide and not wide enough.
The existing logic for adjusting the editor window position by moving it
was flawed as it didn't take into account the fact that the editor could
decide to use a different (and usually bigger) rectangle than the one we
provided it with, if it doesn't fit into the given one. Fix it to ensure
that the editor window is fully inside the grid client area by moving it
only after letting it choose its own size.
The existing code was also inconsistent as CalcDimensions() didn't take
any adjustment to the cell rectangle done in ShowCellEditControl() into
account at all and always just blithely assumed it was positioned at the
cell top left corner, which resulted in wrong virtual size calculation
and could make scrollbars appear when starting editing, as happened in
the "Bugs table" example of the grid sample when showing any comboboxes
in the last grid row. Fix this code to use the actual editor rectangle
instead.
This is another attempt to get rid of the flicker when using the native
header control with wxGrid under MSW and avoid calling UpdateColumn(),
which is currently implemented in a very inefficient way in wxHeaderCtrl
under MSW, during interactive resizing.
See #18794.
Clicking on (or near) the grid column or row edges was handled specially
to allow dragging them in order to resize the column or row, but this
doesn't need to be done if drag-resizing the columns or rows is not
allowed in the first place and resulted in surprising user-visible
behaviour: e.g. when using row selection, clicking mostly anywhere in
the row selected it, except if the click happened to be between the two
columns, in which case it didn't.
Fix this and always select the row in such scenario now.
Unfortunately, doing this required adding yet more CanDragXXX()
functions in addition to the already impressive panoply of them in
wxGrid, but we need CanDragGridColEdges() as none of the existing
functions checked for m_useNativeHeader (there was instead an ad hoc
check for it directly in the mouse handling code) and the row version
had to be added for symmetry.
Although the native (single line) text control understands Alt-Backspace
as an accelerator for "Undo", using it was not really practical because
it resulted in an annoying beep due to Alt-anything trying to find an
item with matching mnemonic in the menu.
Work around this native (mis)feature by pretending to handle this
particular Alt-combination ourselves when the currently focused control
is text-like, as indicated by it overriding WXGetTextEntry() -- this is
not ideal, but seems to be the best we can currently do. An alternative
could be to just mark Alt-Backspace as handled unconditionally.
Not being able to use space for starting editing the values of the
numeric columns was inconsistent with most (if not all) the other ones
and so surprising and inconvenient. Make space work for these columns
too, but just ignore it, i.e. in particular do not erase the current
cell contents when it's pressed, to avoid changing the old behaviour too
much.
wxOSX's wxApp::MacReopenApp() previously contained logic to unhide
hidden windows, but this code was commended out since 2013 as
problematic - it was showing windows like closed, but not yet
destroyed, non-modal dialogs.
Unfortunately while this part was commented out, the rest of the code
that handled existence of hidden windows was not, resulting in a bug
where nothing happened after clicking app icon in the Dock if the
application didn't have any visible window at the moment, but had a
"technical" hidden one, e.g. after opening and closing
wxPreferencesEditor.
Fixed by simplyfing and removing all (functionally commented-out) code
related to hidden windows. Instead, the logic is now:
1. do nothing if some window is already visible
2. restore an iconized window if there's one
3. call MacNewFile() if neither happened
The new method allows to set the zoom level more precisely than the
existing SetZoom(wxWebViewZoom).
Also improve the webview sample by using radio menu items instead of
check items and manually resetting them.
Closes https://github.com/wxWidgets/wxWidgets/pull/1894Closes#18769.
We need to ensure the configure arguments to disable features
are passed in immediately before calling, because the builtin
is the fallback if the system library is not found.
Fixes#18791
Optimize wxGrid::AutoSizeColumns() for big grids.
This includes an optimization of wxDC::GetTextExtent() at the price of
slightly reduced precision in wxMSW.
See https://github.com/wxWidgets/wxWidgets/pull/1893
It turns out that wxEnhMetaFileDC doesn't have any valid font in wxMSW,
so the changes of 70768a33d2 (Dramatically speed up measuring text
extent in wxMSW, 2020-06-10) broke its GetTextExtent().
Fix this by checking if we have a valid font explicitly, although
perhaps a better fix would be to ensure that wxEnhMetaFileDC also always
has a default font, as the other wxDC classes.
Previously, we ensured that the combobox was tall enough, but not that
it was wide enough, which could result in truncation of its contents if
the cell rectangle was too small.
Fix this by increasing the size in both directions, if necessary.
Also make the code simpler by using higher-level wxSize and wxRect
methods instead of fiddling with the coordinates directly.
This allows to make computing the best width of numeric columns an O(1)
operation instead of O(number-of-rows), which can make a huge difference
for big grids.
Previously columns using a set of predetermined values used plain
wxGridCellStringRenderer, which didn't allow to determine their best
size efficiently, as wxGrid had to iterate over all the rows of the
table, even if they only took a couple of possible values.
Add wxGridCellChoiceRenderer (refactoring wxGridCellEnumRenderer to
extract the common code from it in the process) which implements
GetMaxBestSize() by just finding the best size of all of these values,
which is much faster for large grids.
This does result in a change in behaviour, as the column now adapts to
its "theoretical" best size and not just the size of the values actually
shown in it, but this seems to be a worthwhile trade-off and could even
be seen as an advantage, as editing a cell won't make its value overflow
the auto-sized column width any more, as it is wide enough to show any
of the column values.
This is another optimization, useful for the renderers that are used
with the values of a fixed form or part of a limited set, as it is much
faster to compute the best size for all values of the set rather than
computing them for all the cells in the column.
The wxMDIParentFrame::Create() function simply called
wxApp::GetRegisteredClassName(wxT("wxMDIFrame")) without providing
apropriate flags parameter depending on the presence/absence of the
wxFULL_REPAINT_ON_RESIZE flag in style. Thus, the MDI parent frame was
always created using the window class with the CS_HREDRAW | CS_VREDRAW
style flags set. Choosing the appropriate value for the flags parameter
of the wxApp::GetRegisteredClassName() function (like in the
wxWindowMSW::GetMSWClassName() function) fixes the flicker issue. The
wxApp::GetRegisteredClassName() call in wxMDIChildFrame::Create()
is adapted as well just for the sake of consistency.
See #18213.
Closes https://github.com/wxWidgets/wxWidgets/pull/1892
We need to explicitly call SetInitialSize() after setting the value of
the control (if it's not empty), as the first call, done from inside of
PostCreation(), doesn't take the initial control contents into account
and so doesn't allocate the height correctly for multiline text controls
containing more than 2 lines of text, for example.
Closes https://github.com/wxWidgets/wxWidgets/pull/1891
Skip correction for the under/overhang for non-italic fonts: it seems to
be pretty small for them and avoiding the calls to ::GetCharABCWidths()
makes GetTextExtent() 7-8 times faster, which seems to be a worthwhile
compensation.
If we decide to restore these calls in the future, we will need to
implement some kind of cache for them, as they're just too slow
otherwise.
Handle the case of a single line string specially, it's faster to do
this than use slow loop over all characters.
Also avoid constructing the string with the characters to measure one by
one and do it all at once instead.
Add a possibility to benchmark GetMultiLineTextExtent() rather than
GetTextExtent() in the graphics benchmark.
There is no need to reimplement the same logic in wxGrid code when we
already have a perfectly cromulent way to do it in wxDC itself (which
hadn't existed when this code was originally written, explaining why it
wasn't used here before).
This makes the code shorter and also a bit faster, as we avoid using
wxStringTokenizer unnecessarily.
No changes in behaviour.
This completes the changes of f730da3c14 (Add imm32.lib to
wxStyledTextCtrl, 2020-05-10) that didn't take care of MSW makefiles,
that need to contain the new required library as well.
Closes#18788.
Extend wxAnimationCtrl XRC handler to cover wxGenericAnimationCtrl too.
Also fix a bug with wxGenericAnimationCtrl inactive bitmap background.
See https://github.com/wxWidgets/wxWidgets/pull/1889
Fix and improve DPI handling in wxStyledTextCtrl.
Fix cursor size after DPI change.
Enable handling DPI events in wxSTCPopupWindow and other popup windows
(that do not inherit from wxTopLevelWindow).
Some cleanup of STC example, and add option to select drawing
technology.
See https://github.com/wxWidgets/wxWidgets/pull/1885
This function basically only exists in order to be used in this handler,
so extend it to allow doing it by adding wxAnimationCtrlBase argument to
it, allowing it to create wxAnimation object compatible with the given
control.
This reduces code duplication and, incidentally, makes GetAnimation()
more useful for any user-defined XRC handlers.
It contained a single function which can be defined in xh_animatctrl.cpp
instead as it's only used there anyhow, and this file has no more reason
to exist, as "adv" library itself doesn't exist any longer.
This allows to write code using this function without any preprocessor
checks.
It should arguably be added to wxBitmapBase to ensure that it's
available in all ports, but should be done together with UseAlpha(),
which is not quite trivial, so leave it for later.
