This function is useful and there is no reason to exclude it from public
API and it should have been done back in 00224e3f30 (Add
wxGrid::RefreshBlock() helper, 2019-07-11) when it was added.
This is the same thing as bd92523bc5 (Fix use of Doxygen @addtogroup
command, 2022-08-03) except it fixes comments format for all the other
occurrences of "@{" and "@}" too, not just for those used with
@addtogroup which was the problem in #22572.
This fixes many different formatting problems due to attaching various
Doxygen commands to wrong elements because of broken grouping, e.g. all
overloaded functions were documented incorrectly and there were several
problems in wxString documentation.
See #22248.
Put Doxygen grouping constructs ("@{" and "@}") in Doxygen comments
rather than plain C++ ones to make them actually take effect. Some old
Doxygen versions (~1.8.5) did recognize them even in plain comments, but
the currently uses 1.9.1 one does not and @addtogroup didn't have any
effect as the result.
This fixes the problem with the "Functions by Category" pages being
empty in the resulting HTML documentation.
See #22572.
It has been a long-time coming, see b95a7c3144 (Allow wxThread::Wait()
and Delete() to block, even under wxMSW., 2011-03-14), but do still
document that it has finally changed.
New version of Doxygen interprets __foo__ as Markdown markup and
consumes the underscores, which mangles the identifier.
Prevent this from happening by escaping the leading underscore for all
occurrences of "__" outside of the code blocks, this seems to be the
least intrusive fix.
See #22671.
It's quite non obvious that the "FileDescription" field of the version
information defined in the resource file is used for this, so explain
it.
Co-Authored-By: Mark Roszko <mark.roszko@gmail.com>
The character "@", which can be part of the full language name, e.g. in
the case of "sr@latin", can't be reliably used as part of resource name,
so replace it with "_" in wxResourceTranslationsLoader.
Closes#22589.
Closes#22601.
Some versions consist of four parts with the last part being called the
revision or build number. wxVersionInfo is now able to save such a
fourth number.
Add another compatibility implicit constructor to allow the existing
code, directly passing XPM data to various functions that used to take
wxBitmap or wxIcon and now taking wxBitmapBundle, to work.
Closes#22566.
Don't change the window size automatically if the application handled
wxEVT_DPI_CHANGED event to allow it to choose a better size than what is
suggested by MSW itself.
Closes#19152.
Make wxINVERT logical function work in at least some circumstances with
wxGTK3/X11 and use this to make wxSplitterWindow and wxSashWindow
separator visible during resizing.
See #22546.
Closes#16890.
HasAlpha() was already available in most of them, now ensure that it's
present in all of them, especially as it has a reasonable default
implementation.
UseAlpha() was only present in wxMSW and wxOSX and still remains only
implemented there, but provide at least a stub for it elsewhere as well
to avoid problems such as that of #17393.
See #22545.
Closes#17397.
Neither of these methods was actually ever used after the changes of the
last two commits (and they hadn't been used when not using wxGTK even
before), so don't force the user-defined model classes to override them.
Also stop using them, as the stub versions don't return correct values
any longer.
Still keep the virtual functions in the base class for compatibility
however as it doesn't cost us much and avoids breaking the existing code
using "override".
This is implemented in Cairo and CoreGraphics renderers only, but this
is still useful as these renderers are used on the platforms where wxDC
wxINVERT logical function is not supported and this composition mode can
partially replace it.
Check that it consistently returns 0 in the wxLC_ICON and
wxLC_SMALL_ICON modes under all platforms.
Document the behaviour of this function in all modes.
The old code in wxToolBarBase::AdjustToolBitmapSize() forced the use of
the exact value of the requested bitmap size multiplied by the current
scale factor, which resulted in ugly bitmaps whenever fractional scaling
factor was used. It also used not immediately clear IncTo() call.
Simplify and improve it by handling the cases when we have a requested
bitmap size and we don't have it differently: if we do have it, just use
it directly, but only with an integer scale factor. And if we don't,
then simply use the bitmap size suitable for the current scale factor.
This seems to result in the most expected behaviour and, notably,
doesn't break the toolbar sample where the bitmap size can still be
toggled between small and big bitmaps on both normal and high DPI
monitors.
Also update the documentation: still recommend not to use
SetToolBitmapSize() at all, but don't claim that it forces fractional
scaling, as this is not the case any longer.
Using a section looks better and prepares for adding another one in the
upcoming commit.
Also remove a note about Motif file dialog limitation, nobody cares
about it any more anyhow.
Ensure that wxBitmapBundleImplSet and wxBitmapBundleImplRC use the same
logic for actually selecting the bitmap to upscale, and not just for
deciding the size that it must have, too.
No real changes, but this should make impossible for these functions to
diverge once again -- and also make it simpler to reuse the same logic
in any other wxBitmapBundleImpl-derived classes in the future.
Instead of taking an array of scales, call GetNextAvailableScale() to
get them.
This allows centralising the logic for returning the available scales in
a single place, where it will be reused in the upcoming commits.
Extract the logic determining the scale to use in a reusable
DoGetPreferredSize() function to allow reusing it in other places.
There are no real changes here, this commit just moved the existing
code to the new function, but because it also changed it from using
wxSize to double, even git --color-moved doesn't show it as an actual
move.
