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.
Remove references to concrete GUI-building programs. Such references are not necessary not to mention that most of the referred programs have not been maintained for a long time.
List of flags in the CreateButtonSizer sizer was unnecessary, some of the values were not valid flags for the methods and comment descriptions for most values did not make much sense in the given context. The section was therefore removed and the method is mentioned in the newly-added part about wxStdDialogButtonSizer.
Sizer types not mentioned in the overview before were added, the rest of changes was mostly adding @c and such.
Passing long argument to "%c" printf format specifier was correctly
flagged as invalid in 64 bit Unix builds where long != int.
Fix this by just making the "keycode" variable int in the first place,
there doesn't seem to be any reason whatsoever for it to be long and
this allows us to get rid of a couple of existing casts instead of
adding yet another one.
Fix compilation/link problems due to symbols redefinitions in user code
that could happen if it included some wx header first, then <windows.h>
(possibly indirectly, e.g. via another third party library) and then
another wx header -- in this case, the second wx header wasn't protected
from <windows.h> redefinitions resulting in all the usual problems.
Avoid this by always including winundef.h whenever any wx header is
included, not just when wx/defs.h is included for the first time.
