This cache was never updated and so could be wrong and not using it at
all is the simplest (although also the slowest) fix for this.
Notably, it could result in failures in ValNum::Interactive unit test
because the thousands separator was set to nothing during a previous
test execution, instead of the expected comma.
This commit is best viewed ignoring whitespace-only changes.
This had been done before all the recent wxUILocale-related changed and
was still done for non-Unix systems, but not there because we explicitly
skipped calling setlocale() in this case with a comment saying that the
default locale was already in use -- however this comment was wrong and
we do need to call setlocale(LC_ALL, "") in this case for compatibility
and consistency.
Closes#22212.
Ensure that the button is wide enough to show both "Next" and "Finish"
and also make all the buttons of the same size, as they look better like
this.
Co-authored-by: Vadim Zeitlin <vadim@wxwidgets.org>
Closes#22200.
Closes#22221.
This fixes the problem with inconsistent file formats in the repository
apparently introduced in e3535d6481 (Mark MSVS *.vcxproj.filters files
as using CR LF as well, 2021-11-24), which resulted in the files changed
by this commit (sometimes) appearing modified in new clones.
Closes#22214.
Define wxDataFormat::operator==(wxDataFormatId) instead of relying on
the implicit conversion from wxDataFormatId to wxDataFormat, as this
can't be done when the format ID is wxDF_INVALID because creating
wxDataFormat results in an assert failure in this case, while comparing
with wxDF_INVALID is clearly a perfectly valid operation.
Add a unit test checking for this.
Closes#22213.
This is a good idea anyhow, as these classes don't need to have extern
linkage and so shouldn't have it, and it also fixes some gcc 11
-Wsubobject-linkage warnings.
Select the bitmap of the required size from wxBitmapBundle instead of
selecting the bitmap with the default size and then possibly rescaling
it to get the bitmap of the needed size, resulting in fuzzy-looking
bitmaps.
Closes#22189.
This reverts commit b6d305e4f2 because
silently discarding images using a different scale factor is simply too
user-unfriendly: this can silently break the existing code, i.e. it can
still compile perfectly and not give any errors during run-time but not
show any images neither.
Also revert most of dc43d15cf7 (Add tests of storing HiDPI images in
generic wxImageList (wxOSX, wxGTK3), 2021-04-05) as these tests don't
pass any longer because the behaviour was intentionally changed.
See #22189.
The default size of the bitmaps created from bitmap bundles returned by
the Tango art provider for the client strings different from wxART_MENU
and wxART_BUTTON was changed from 24x24 to 16x16 in 766fefeb34 (Use SVG
instead of PNGs in tango art provider, 2022-01-27), see #22067, without
any real need and perhaps even non intentionally at all.
Restore the old default size to restore the old behaviour.
See #22189.
Accept the same kind of time zone specifiers that RFC822 timestamps
accept; most importantly the "+0200" style.
Added more tests, and changed the way tests compare dates:
Since some timestamps now specify a time zone, those need to be compared
as UTC to avoid the system's time zone affecting the tests. Others can
still be compared as local time, as before.
Out-of-bounds was already covered by the fact that the date is appended 32
zero-bytes in ParseRFC822Date() as a safety measure. But now the time zone
parsing section of the function no longer relies on those extra zeros
being present.
Added tests for RFC822 timestamps with military time zones, and more types
of truncated, invalid time zone specifiers.
Correction to the commit:
2153ffc (Test ParseRFC822Date() with truncated time zone specifiers,
2022-03-19)
The inputs failed as expected, but due to an unrelated reason (missing
comma).
Gnome uses a variant of the "log out" icon for its standard "Exit" icon,
so it should be fine for us to do it too, contrary to what the comment
from back when Tango provider was added in c1d2466a79 (Add wxArtProvider
using Tango icons., 2010-12-31) was saying.
Changing invoking window always needs to update the bitmaps because
the scale factor may need to be changed if this window is on a different
display, using different scaling, so do it automatically whenever
SetInvokingWindow() is called instead of having to remember to call
SetupBitmaps() manually everywhere SetInvokingWindow() is.
This required making the base class function virtual, but allows to get
rid of SetupBitmaps() call in wxWindow::DoPopupMenu(), as it can now
rely on this being already done by wxWindowBase::PopupMenu().
Don't crash if this function is called (which is not the case yet, but
will be after the upcoming commit, when it's going to be implicitly used
when updating the bitmaps for taskbar icon menu), but return the content
scale factor for the main screen, which should be the right thing to do
here.
This currently doesn't work there because the focus rectangle doesn't
fit into the space reserved for it (which is a bug on its own, probably)
and would look very out of place even if it did work because the native
tabs don't use focus rectangle for the selected tab.
Closes#22190.
Since the changes of 7129d2b11c (Accept multiple data formats via
drag-and-drop in wxDataViewCtrl, 2021-08-22) custom data formats were
simply ignored because CreateDataObject() helper didn't do anything for
them.
Fix this by simply continuing to handle them in the same way as before,
i.e. by creating a wxCustomDataObject for the specified format.
Closes#22112.
Using many menu commands after removing the toolbar could result in a
crash because they used the toolbar pointer without checking for its
validity.
Add wxEVT_UPDATE_UI handler disabling these commands to prevent this
from happening.
This required rearranging the menu item IDs to allow using a single
range for all of them.
Set the end iterator to the end of the actually parsed date, instead
of consuming any ultimately unparsed whitespace/delimiters possibly
following the date.
In other words, check that the unprocessed part of the input is what
we expected.
Also add some cases where a valid date or time is followed by something.
When calling GetDPI() for a window which is not created itself yet and
doesn't have any valid top level parent neither, we have no choice but
to fall back on using the screen DPI, but this doesn't always work
correctly for the systems using multiple monitors with different DPIs,
so warn when this happens -- any situations when it does indicate a
potential bug that should be fixed.
See #22193.
It doesn't make sense to use some hardcoded size for these fields and
we can't use FromDIP() for wxTabFrame which is not a real window (as
it's never created, it doesn't have a valid HWND under MSW, so FromDIP()
can't return the correct result for it), so don't initialize them at
all: they will be set later, before they're actually used, by the code
in wxAuiNotebook using wxTabFrame.
FromDIP() shouldn't be used before the window is created and
m_tabCtrlHeight was already initialized correctly in InitNotebook(),
when it can be used, so simply remove this premature and redundant
initialization.
There is no reason not to allow calling this function with const window,
so do allow it, notably to make it possible to use it with "this" from
const wxWindow methods.
It is possible to use WindowHDC as ScreenHDC by passing a NULL HWND to
its ctor and we still need to release the HDC allocated in this case in
the dtor, so do _not_ check for HWND being valid there.
This fixes a bad resource leak in wxWindow::GetDPI() when it's called
for a window without a valid handle.
Closes#22193.
Closes#22194.
Anything following the dot was mistakenly used as an extension of the
corresponding file and replaced with ".mo", breaking loading of catalogs
with the names like "wxstd-3.1", which is the standard wx catalog name
since ded4da5ce5 (Add version suffix to gettext message catalog files,
2021-02-07).
Closes#22198.
