It causes a warning with MSVC code analysis:
"warning C26437: Do not slice (es.63)"
It's unclear if this function even needs to exist, but at least
move it out of line so the warning does not occur for user code.
Use wxString::StartsWith() instead of comparing the result of Find()
with 0: this is shorter and more clear (and marginally more efficient).
No real changes.
This ensures that they are always available and can be used in
wxLaunchDefaultBrowser() in all build variants, whereas before this
function didn't handle file:// URLs correctly when the library was built
with wxUSE_FILESYSTEM==0.
Closes https://github.com/wxWidgets/wxWidgets/pull/1469Closes#10414.
The various arrays containing row/column coordinates (m_rowHeights,
m_rowBottoms, m_colWidths, m_colRights) must not be accessed directly as
they are empty by default, and are only initialized if any rows/columns
have non-default width/height.
Use safe accessor functions instead.
See https://github.com/wxWidgets/wxWidgets/pull/1417
This updates/replaces 6c59a4e7af which
fixed the problem with auto-resizing of wxStaticBitmap with borders, but
broke auto-resizing of wxStaticBitmap that previously used an invalid
bitmap, as they still have a non-null (currently hard-coded as 16x16)
size in this case and the size updating logic didn't take it into
account.
Instead of trying to make it even smarter, get rid of it completely and
just set the control size to its best size, as the other ports do. This
is simpler and should be less error-prone -- and won't require updating
when the constant 16x16 will be changed to something else (which will
happen soon as part of better high DPI support).
See #18398.
Commit 91aa6ba36e introduced a
regression causing this to crash. We need to validate that the color
is valid before attempting to call OSXGetNSColor; if it is not, we
should clear any previously-set background color.
Closes#18470.
Closes https://github.com/wxWidgets/wxWidgets/pull/1503
wxComboCtrl consists of several controls (text entry, button, popup) and therefore should be implemented as a wxCompositeWindow to prevent problems with generating spurious events when e.g. focus is transferred between the sub-controls.
Closes#18394.
MSW-specific scaling was done for the initial maximum value in Create(),
but not if the maximum was changed later in SetMaximum(). Now do it
there as well.
Closes https://github.com/wxWidgets/wxWidgets/pull/1497
Use the same logic for wxGTK (and other platforms using double
buffering) as was already used for wxMac, it seems to result in less
flicker.
Closes#18017.
This could have been unexpected even if it worked as designed and,
unlike with direct calls to Normalize(), there was no way to prevent
this from happening.
Worse, even when no expansion was done, the simple fact of calling
wxExpandEnvVars() could result in replacing "dir\$file" with "dir$file"
as the backslash is considered as an escape character by this function
and hence break the file name structure.
Closes#17977.
This is simpler to use than wxDisplay(window).GetPPI() which was used
instead of it so far in all ports and can be implemented more
efficiently for wxMSW.
Remove wxGetWinTLW, GetDPI already tries to get the top window.
This is similar to 228cd926e2, but extends
the fix to v1 strings, as even though they have the "point size" field,
this field may still contain 0, resulting in the same problem as with v0
strings, i.e. 0-sized fonts.
Closes#18467.
This is a better fix for the problem with NSOpenGLView having wrong size
after resizing the window under 10.14.5 (only): reset the context when
making the context current, to ensure that the up-to-date size is used.
See #18402.
Explicitly use the white brush when erasing background of the bitmap
used for print preview, to match the printed page appearance. Somehow it
worked even without this under other platforms before, but logically
resulted in black background under wxGTK 3.
Closes https://github.com/wxWidgets/wxWidgets/pull/1476Closes#18371.
