Fix handling Enter in multiline text controls in wxMSW.
And other improvements, notably don't send wxEVT_TEXT_ENTER for controls
without wxTE_PROCESS_ENTER style.
Closes#18491.
See https://github.com/wxWidgets/wxWidgets/pull/1539
Since the changes of 04f7f1fd32 (frozen
rows/columns implementation), RefreshBlock() could call GetColPos() with
an invalid index. This didn't matter most of the time as the function
simply returned the same index as long as the columns were using their
natural order, but resulted in a crash due to an out of bound access to
m_colAt array as soon as they were reordered.
Fix this by avoiding using invalid indices in RefreshBlock() and, more
generally, improving its precondition check and making the assumptions
about the input parameters more clear. Also add a defensive check to
GetColPos() itself.
Finally, add a unit test exercising this code.
Closes https://github.com/wxWidgets/wxWidgets/pull/1536
Restore behaviour until c43e0fa123 and let
Enter presses in multiline text controls perform their default function
in the control instead of closing the dialog.
Make the unit test more discerning to check for this.
wxMSW always sent this event to multiline text controls, even when they
didn't have wxTE_PROCESS_ENTER style, contrary to what was documented.
Avoid sending this event unless wxTE_PROCESS_ENTER is used and add unit
tests checking that multiline text controls don't get it without this
style (but still do get it with it).
For once, using the event table macros is preferable because this
bypasses the (generally helpful, but not here) test done by Bind()
verifying that wxEVT_TEXT_ENTER handler is bound to a window with
wxTE_PROCESS_ENTER style.
Doing it like this will allow to check that controls without this style
really do not receive the corresponding event.
This didn't work any more since the changes done in the branch merged by
fb2c17c193 as using wxTE_PROCESS_ENTER
without actually handling the resulting event doesn't prevent Enter from
activating the default button any longer.
Add UpdateText() and UpdateLabel() updating the text (i.e. possibly
containing markup) or the label (just plain text) shown in the window.
Closes#14743.
Closes https://github.com/Kvaz1r/wxWidgets.git BusyInfoUpdateText14743
Update the font of some buddy controls when the DPI changes. Fix the
position of the statusbar after a DPI change. Add some changes that were
suggested in https://github.com/wxWidgets/wxWidgets/pull/1499 but left
out from it.
Some sizes are cached to improve the speed of the library. These sizes
become incorrect when the DPI changes. And are incorrect when a window
is created on a display with a different DPI. Fix this by checking if
the current DPI is the same as the DPI that was used when calculating
the size, otherwise recalculate the size.
Closes https://github.com/wxWidgets/wxWidgets/pull/1530
Ensure that wxPOPUP_WINDOW on Mac always sets the window level
to NSPopupWindowLevel, regardless of the wxSTAY_ON_TOP and
wxFRAME_TOOL_WINDOW flags.
As the comment for wxPOPUP_WINDOW in defs.h says,
"set this flag to create a special popup window:
it will be always shown on top of other windows"
So, that should *always* be true, even in relation to other
Windows with wxSTAY_ON_TOP, since NSPopUpMenuWindowLevel
is greater (higher) than NSModalPanelWindowLevel.
It should also *always* be true even if the window has both
wxPOPUP_WINDOW and wxFRAME_TOOL_WINDOW styles, since there's
no reason why we can't have a panel with NSUtilityWindowMask
and NSPopUpMenuWindowLevel.
For wxImage having both mask and alpha channel (it is technically possible), mask cannot be converted to alpha values and in this case resulting wxBitmap will also have both mask and alpha channel.
Due to lack of support for horizontal scrolling in the native control,
scrolling it was implementing by offsetting the entire control window.
However this didn't work correctly when the window was not positioned
at the leftmost border of its parent window, as the part of it that was
scrolled off could still be visible in this case, and this is exactly
what happened when the native header was used in wxGrid: scrolling it
overwrote the corner part of wxGrid.
Fix this by embedding the actual native control inside an outer wxWindow,
to ensure that the scrolled off part is clipped by the parent window.
Note that this commit is best viewed with "git show --color-moved" as
most of the code was just moved from the header into the implementation
file and is not really new.
Override wxHeaderColumn::GetMinWidth() to return the actual minimum
width instead of just returning 0.
Add a unit test verifying that this works as intended.
Drag-resizing the columns didn't work correctly when using the native
header and scrolling it horizontally, as the wrong offset was used in
this case.
Fix the offset in wxGrid code and add a unit test checking that this
works as intended (at least under MSW, as wxUIActionSimulator just
doesn't work reliably enough to test for this under the other platforms,
and, besides, only MSW has the native header control implementation
anyhow).
If it is not initialised, getting the screen rectangle will fail, so
don't even try doing it, but just return wxNOT_FOUND instead, so the
main display will be used -- this is the best we can do if the window
hasn't been created yet, as we don't know on which display it will
appear.
Closes https://github.com/wxWidgets/wxWidgets/pull/1527Closes#18481.
The changes of 5873ee7e4a completely broke
AUI layout as wxAUI code relies on Layout() still performing the layout
even when GetAutoLayout() returns false, but the new wxTLW::Layout()
didn't do anything in this case.
Fix the problem by checking whether we have a sizer or constraints in
this function instead of using GetAutoLayout(), which is supposed to
only be used by wxEVT_SIZE handler to determine if Layout() should be
called in the first place, but not by Layout() itself.
Closes#18486.
Since we always convert wxImage to 32 bpp wxBitmap, there is no reason to keep a separate mask for wxBitmap because alpha channel can be used directly.
Monochrome mask bitmap should have white pixels in the unmasked area and black pixels in the masked area, quite the opposite to what is implemented now.
Closes#10098.
When bitmap data are accessed with wxNativePixelData, which is designed
to handle RGB bitmaps, Alpha() function cannot be used because in this
case alpha component index is set to the default value -1 and actually
the blue component of the "preceding" pixel is accessed.
Closes#18478.
It's generally wxWidgets policy not to include platform-specific headers from our own
to avoid namespace pollution issues, in this case with names like "None" and "Window".
Getting the warnings about deprecated macros when building the library
itself is not useful, as it must continue to use them as long as
WXWIN_COMPATIBILITY_3_0 exists.
Closes https://github.com/wxWidgets/wxWidgets/pull/1510
While feacaf8714 changed the API to allow
using any wxWindow (and not only a window of a wxControl-derived class)
as the associated window of the grid editor, actually doing resulted in
an immediate crash due to dereferencing a null pointer in wxGrid code
which still expected to have a wxControl.
Fix this by replacing all calls to wxGridCellEditor::GetControl() inside
wxGrid with wxGridCellEditor::GetWindow(), to ensure that a non-null
editor window is used even in this case.
Closes https://github.com/wxWidgets/wxWidgets/pull/1509
In 8f386265dc, the width of a tree
expander is changed to the native value on the platform. But some
calculations still use guessed value (m_lineHeight) as the width. This
fixes the value, by retrieving the width using the same method as in
OnPaint().
Closes https://github.com/wxWidgets/wxWidgets/pull/1508Closes#18473.
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
