Should work for Caret, still has a problem with the transformation matrix otherwise, too many things have changed there for me to find a quick solutions.
Using popupMenuPositioningItem leads to several problems on modal dialogs - the validation and action callbacks are not used, thefore we revert in this situation to using the older API, see #549 and https://trac.wxwidgets.org/ticket/17459
Prior to 2.9.2, if the focus bitmap was specified but current one wasn't, the focus bitmap was used for hovering as well.
This feature was entirely discarded in b4354db179 (see wxBitmapButton::DoSetBitmap) but it is still described in the documentation of wxButton's states and images. It seems it was removed unintentionally, so let's restore it.
Some current input processing flags, like DLGC_HASSETSEL, should be retained because they are in use (in wxWindowMSW::SetFocusFromKbd() for instance).
Closes#17945.
GetEntitiesParser()->GetCharForCode(NBSP_UNICODE_VALUE) in the non-unicode
build returns the value '?' as it doesn't find a match for that value. The
parser then proceeds to replace all '?' characters in the HTML document with
NBSP.
Change the type of the #define to be unsigned int rather than wxChar for
non-unicode to fix this.
Closes#17692.
Menus on Mac use automatic menu enabling, meaning that the system will enable
menu items only if the app responds to the menu item action. If I understand
correctly, the responder chain for menus in popup dialogs stop at the dialog
window, so the system thinks that the app does not handle the menu items.
This fix should not affect existing code since the wxWidgets user-facing API
dictates that apps specifically disable menu items.
Fix#17459
See Apple docs on automatic menu enabling at
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/MenuList/Articles/EnablingMenuItems.html#//apple_ref/doc/uid/20000261-BAJBFGED
The latest of those checks tested for w32 API 3.3, which is older than
MinGW 3.4 released which is more than 13 years old, so we can safely
drop them (let alone checks for prehistoric 0.5 w32 API).
This incidentally fixes compilation errors due to the use of
wxCHECK_W32API_VERSION() in wx/msw/winundef.h which was now (since
the changes of 8c572c0a77) included before
this macro was defined.
If the text in the control doesn't end with a new line,
last valid position is just past the last character in the
the last line.
But if it ends with new line, last valid position
is located at the beginning of the next virtual (empty) line.
So, this case has to be also taken into account in determining
whether position is valid or not.
Take into account that last valid position is after the last character of the text.
This applies also to empty controls for which XYToPosition(0, 0) should return 0.
Display "long help" text associated with the toolbar items in the status
bar of the parent frame even if the toolbar is not a direct child of the
frame.
Closes#17897.
New line is not always marked by 2-character (\r\n) sequence. It can be
also 1-character (\r) for RichText controls or even no mark at all (for
wrapped line).
It is a synonym for wxIMPLEMENT_ABSTRACT_CLASS and not
wxIMPLEMENT_DYNAMIC_CLASS as it was wrongly stated.
Also avoid duplicating the documentation of the other macro and just
refer to it instead.
This reverts commit c4e1fb4ef9.
Last position is not necessarily the number of characters in the buffer,
rich edit controls still store the text using CR LF between lines, but
GetLastPosition() should return the position as if they used only LF to
be consistent with all the other positions in these controls and
changing this broke existing code passing GetLastPosition() to other
functions taking position.
There is a valid position after the last character of the text in
wxTextCtrl, e.g. position 0 in the empty control, so account for it and,
notably, don't return -1 from XYToPosition(0, 0) when the control is
empty.
This fixes a regression in a69ab2907c.
In addition to showing the position returned by HitTest(), also show its
return value which is not necessarily wxTE_HT_ON_TEXT if it is not
wxTE_HT_UNKNOWN under MSW.
Use wxScopedCharBuffer as we only need the buffer in the current scope.
This avoids a buffer copy done by wxCharBuffer which could be a
significant pessimization for large buffers.
Also don't call strlen() unnecessarily, we already know the buffer
length, so just use it.
This method seems completely unnecessary, the base
wxTextEntry::DoSetValue(), which delegates to Remove() and WriteText(),
seems to work just as well and avoids code duplication between this
method and wxTextCtrl::WriteText().
Notice that gtk_text_buffer_set_text() is just a trivial wrapper around
gtk_text_buffer_delete() and gtk_text_buffer_insert() anyhow, so there
is no efficiency loss in not using it neither.
This could happen if the code calling SetValue() was in a handler
invoked in response to a keyboard action as our insert-text signal
handler believed that it was called in response to this key in this
case, even when it wasn't the case.
This extends the changes of def8247c61
to WriteText() to DoSetValue(), thus fixing the same problem in
SetValue() and ChangeValue() too.
But the question of why do we have two so similar, yet different,
functions, resulting in having to fix the same bugs twice still remains
unanswered...
Remove the already described sizers from section Other Types of Sizers. Remove "See ..." sentences which are unnecessary when the class documentation is already linked right above. Also fix a typo in a sizer name that prevented doxygen linking to the class.
