Add preliminary support for per-monitor DPI awareness to wxMSW.
Individual controls still need to be fixed, so this support is still
experimental/unfinished for now.
See https://github.com/wxWidgets/wxWidgets/pull/1499
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.
wxNativeFontInfo constructor calculates the pointSize using the main screen DPI.
But lfHeight returned by GetNonClientMetrics is based on the window DPI.
Update the documentation to reflect change to the GetMenu event
working for all 3 menu events. Also update the sample to give the
menu for the highlight event.
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
React to the WM_DPICHANGED event and update the size of the child windows and
the top-level window. Scale the minimum and maximum window size to the new DPI.
Only react to WM_DPICHANGED when DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 is
used.
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.
We could end up with 0 max total width because we could assign the value
of the child max total width, which could have been 0, just because the
child "width", which is actually the total available width for the
container cells (and a child of a container cell can, of course, be
another container cell), was greater than our own total width so far.
This is confusing because it might be expected that "width" is always
less than "max total width", but actually this is (almost) never the
case for the container cells.
Closes#10263.
This makes it easier to see which cell is which one when debugging.
Also use GetMaxTotalWidth() instead of GetWidth(), as the former is more
useful for container cells (and the same for the other ones).
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.
Explain how these methods actually work, remove a very (from wx 1.x
days?) outdated reference to wxPanel always calling Layout() and mention
the special case of wxTopLevelWindow in the overview too.
Ideal would be to completely get rid of the DoLayout() method later,
however this method seems to be used in the existing applications, so
for now it needs to be kept.
It makes sense for explicit calls to Layout() to use the same logic as
is implicitly used when a TLW is resized, so override it to use
TLW-specific logic instead of using a separate DoLayout() for this.
Note that DoLayout() still has to be preserved because Debian code
search finds at least a couple of examples of its use outside the
library, meaning that there are probably quite a few more of them in the
wild.
Also, wxTopLevelWindow still needs its own wxEVT_SIZE handler because
the base class only calls Layout() if GetAutoLayout() is true, while we
want it to be always called. This might be worked around by just calling
SetAutoLayout(true) in wxTopLevelWindow ctor, but it seems safer, from
compatibility point of view, to keep wxTopLevelWindow::OnSize() instead.
See #18472.
