Instantiate NumericValidation() template directly for required data type in DoValidation() and avoid this way intermediate conversions to another data types.
Duplicating the code of the entire NumericValidation() template function just for one specialization (for double value type) seems to be an overkill. Only small fraction of the code (to round the validated value) is really dependent on the value type and this part can be moved to the template function GetRoundedValue() which in turn can be specialized as required.
This doesn't seem to be actually necessary, i.e. the (implicit)
dependency on the output file is enough and using it resulted in always
redoing the custom build step with MSVS 2019 which seems to always
consider directories as missing dependencies, at least according to its
msbuild (version 16.1.76+g14b0a930a7) diagnostic build log.
The binaries-related files haven't been updated yet because we don't
provide 2019 binaries yet (build/tools/msvs/officialbuild.bat still has
to be updated too).
Use wxWindow instead of wxControl in wxGridCellEditor to allow using
any window as an editor control, as it doesn't need to be a wxControl.
Closes https://github.com/wxWidgets/wxWidgets/pull/1370
This OS update has broken resizing of NSOpenGLView, which worked
correctly up until to 10.14.4.
Work around it by preventing the default implementation of update from
being executed. It's not clear why should it help with the problem, but
it does.
Closes https://github.com/wxWidgets/wxWidgets/pull/1354Closes#18402.
It seems better to disable LZMA rather than silently building the
binaries depending on an external library when we were explicitly
requested not to do it.
The last digit was truncated as the code discarded the trailing "\n"
which wasn't really there, as ReadLine() helper function already removed
it, and so ended up removing the last digit of the line number,
resulting in mostly plausibly looking but completely wrong line
information in the assert dialog.
This was already done in the other functions, but not this one,
resulting in a crash if it was called for an object with null m_nowpeer
(e.g. before it's created or when it's not a real wxNonOwnedWindow
object as when it's a subobject of wxTDIChildFrame).
See #18423.
This notably fixes the problem with wxAuiMDIChildFrame::GetScreenRect()
returning the wrong window position since the changes of
c1bcf16eb9.
Closes#18423.
This replaces and extends the previous commit by using `$var` instead of
`$(var)` when this makes sense and using the ugly workaround for Doxygen
expanding environment variables even inside Markdown backticks elsewhere.
Also use backticks around more strings.
It turns out that Doxygen expands $(VAR) into the actual value of the
VAR environment variable on the machine where it runs, which is
definitely not what we want in the instructions telling people to use
"$wxwin" in their projects, so remove the parentheses to prevent Doxygen
from expanding it.
Another alternative would be to escape "$" with a backslash, but this
would make the source markdown file uglier.
Use print() and byte strings to make the code compatible with Python 3,
while also keeping it compatible with Python 2 (>= 2.6, at least).
Closes https://github.com/wxWidgets/wxWidgets/pull/1348
Under wxGTK, wxGauge was returning fixed values for height and width.
This meant that the gauge would not center correctly in a sizer,
particularly under GTK+ 3 where the default gauge height is just a few
pixels.
Following this change, wxGauge renders correctly on GTK+ 3 and matches
the reference widget display in the gtk3-widget-factory app.
Note, this change will also result in a slimmer widget on GTK+ 2, but
the gauge height can be forced using wxGauge::SetMinSize() on the older
toolkit.
The gauge presentation is totally theme dependent under GTK+ 3. For
example, the user can have thicker gauges by setting the following in
their ~/.config/gtk-3.0/gtk.css file:
progress, trough {
min-height: 20px;
}
Closes https://github.com/wxWidgets/wxWidgets/pull/1353
A number of object files in wxCore can end up being empty due to the
corresponding wxUSE_XXX options being set to 0. This is normal and
getting tons of warnings from MSVC during the build about it wasn't
helpful.
It turns out that these warnings can be suppressed by using the
undocumented, but described at
http://www.geoffchappell.com/studies/msvc/link/link/options/ignore.htm
"/ignore" option, so do this to finally get a clean build.
Ellipsization code was completely broken when used with the usual
control label strings containing mnemonics: it simply stripped the
mnemonics completely, losing them even if the label wasn't actually
ellipsized, and turned "&&" into a mnemonic. I.e. "&Plug && play"
appeared without underlined "P" but with underlined space before "play"
before.
Fix this by pretending that all ampersands in the string to be
ellipsized have zero width. This is not precise, as the result of
GetPartialTextExtents() for a string with the ampersands is not exactly
the same as the sum of its result for the string without the ampersands
and the width of the ampersands themselves, but it should be pretty
close and unlikely to result in any problems in practice for the
controls labels.
At the very least this fixes the completely wrong behaviour of the
controls on the "Static" page of the widgets sample, where ellipsization
is enabled by default and setting the label text with mnemonics didn't
work at all.
When processing mnemonics, the resulting string should still contain
them and they need to be stripped before measuring its width, but the
code didn't do it.
This didn't prevent the tests from passing, but only due to another bug
in ellipsization code itself, which lost the mnemonics completely. As
this bug is about to be fixed, the test needs to take mnemonics into
account properly now.
The code was confusing as it used Bind() for some handlers, event table
for some others and, for the 3 buttons in the middle column, it actually
managed to use both.
Get rid of the event table completely to make this more clear.
This resulted in wrong letter being underlined in wxGenericStaticText
when the mnemonic occurred after "&&" (i.e. an actual ampersand) in the
label.
Add unit test which passes now, but would fail before on the last check.
Clicking on the "Generic wxStaticText" box resulted in several
assertions because the markup string contained both a single "&" and
a "&" used for the mnemonic. Double the former to avoid misinterpreting
it as a mnemonic character too.
Also remove the macros used in the test to perform the same tests for
wxStaticText and wxCheckBox and use a helper function instead, making
the code more clear and extensible.
No real changes.
The names of these methods were confusing because they implied that they
were the actual implementations of the public [SG]etLabel(), while this
wasn't at all the case.
Give them then ames describing what they really do and also update the
comments to hopefully be more clear.
No real changes.
