Since wxDirsProperty derives from wxArrayStringProperty and new implementation of this class no longer passes this macro parameter to OnButtonClick() so wxChar* string is no longer required here.
wxFontProperty and wxMultiChoiceProperty use TextCtrlAndButton editor so they can be implemented as parents of wxEditorDialogProperty to share common functions and data.
Properties using TextCtrlAndButton editor (like wxLongStringProperty, wxDirProperty, wxFileProperty) share some features, like button triggering the editor dialog, and share a data, like dialog window attributes, so for the sake of the clear design it would be good to derive them from the common base class in which all shared functions/data are implemented. This class is not intended to be instantiated so it's an abstract class.
Explicitly mention that if no handler for wxEVT_TEXT_ENTER is defined
(or if a handler exists, but skips the event), the default handling of
"Enter" still takes place.
Verify that pressing Enter in a dialog activates its default button when
a text-like (i.e. wxTextCtrl or wxComboBox) has focus either if it
doesn't have wxTE_PROCESS_ENTER style or if it does, but its handler
skips the event, but not if the style is used and the event is handled.
This ctor just created unusable wxTimerEvent objects (all of the methods
specific to this class would just crash if called on them) and doesn't
seem to be useful at all.
It was added in e47859daeb apparently only
in order to allow using wxIMPLEMENT_DYNAMIC_CLASS() instead of the
previously used wxIMPLEMENT_ABSTRACT_CLASS() for wxTimerEvent, but there
doesn't seem to be any reason to prefer macro over another, and there
are good reasons to not allow creating objects in an invalid state.
The only place where we relied on having default ctor for this event was
in wxEvent::Clone() unit test, so update it to handle wxTimerEvent
specially now that this ctor doesn't exist any longer.
Activate the default button of the dialog containing the wxComboBox if
wxEVT_TEXT_ENTER handler didn't process the even, just as it was already
done for wxTextCtrl.
See #18273.
No real changes, just check for WM_CHAR inside the existing "switch"
instead of writing a separate "if" statement just for it.
Note that removing HasFlag(wxTE_PROCESS_ENTER) test shouldn't matter as
we should be only getting WM_CHAR for VK_RETURN when this flag is used.
This doesn't seem to change anything in practice, but it's more logical
to not pretend that we processed the message if we didn't do anything at
all with it.
The first attempt to add the wxEVT_STC_AUTOCOMP_SELECTION_CHANGE event to wxSTC
passed the data needed for the event through the constructor for the
wxSTCListBox class. Instead of mdifying the constructor for wxSTCListBox, it’s
better to store the data in the wxSTCListBoxVisualData class with accessors for
setting and retrieving the data.
The current wxSTC documentation page currently has a bare listing of the
event types defined for wxStyledTextEvent. These event types are
completely documented on the wxStyledTextEvent page. However the bare
listing on the wxSTC page can lead to the conclusion that there is no
documentation for the event types.
Remove the bare listing from the wxSTC page and replace it with a
referral to the wxStyledTextEvent page. This is consistent with other
large classes such as wxGrid and wxRichTextCtrl that separate the
documentation for their methods and events.
On macOS, the autocompletion popup maintains a pointer to its parent
control since it sometimes needs to set a cursor on the control. However
when the control is destroyed while the popup is active, the control is
destroyed before the popup because of the delayed destruction used by
the popup. This leaves the popup with a dangling pointer and can lead to
crashes.
To prevent this, let the popup handle the window destroy event for the
control. Reset the pointer to NULL in that handler so that the popup
will no longer try to access its parent control after it is deleted.
The SCN_AUTOCSELECTIONCHANGE notification was added in Scintilla 4.0 to
notify an application when a new item is selected in an autocompletion
or user list. However the version of Scintilla currently used is 3.7.2,
so this potentially useful notification is not available.
These changes allow an event corresponding to this notification to be
generated completely in the wxWidgets portion of wxSTC. If the Scintilla
library is ever updated to 4.0 or later, only one method should need to
be modified let Scintilla generate the event instead.
The wxSTC methods AutoCompSetColours and AutoCompUseListCtrl were added
in fe7b332b7b to allow some configuration
of the autocompletion popup window. Based on subsequent discussion, it
was decided that a better method of configuring the popup and getting
information about the configuration is needed. For now, simply remove
the current methods while the better solution is created.
In addition, since the configuration options are being removed, set the
popup to have the appearance of a list control since that was the
appearance before any configuration options were added.
* Copy-paste the code for OnChar in the wxTextCtrl.
* This implements two features:
1. This adds support for the wxTE_PROCESS_ENTER style.
2. Support for pressing the default button in a dialog if there is one.
* Use the same code as for wxNSTextField (copy-pasted).
* This method is used to redirect the enter key event to the OnChar
event.
* This makes it possible to implement the default button activation by
pressing the enter key (for comboboxes which doesn't have the
wxTE_PROCESS_ENTER style).
* It is the same as the code in the implementation of the wxTextCtrl, I
guess this could be extracted in a common function, but I don't know
where to put it.
In the class description mention that in addition to RGB, an alpha value
is stored as well. Remove incorrect description of operator=(), clarify
meaning of "on" parameter in MakeMono(), and make few minor text edits.
Closes https://github.com/wxWidgets/wxWidgets/pull/1411
If the window has no valid font, GetFont() returns a temporary font.
Extend this font lifetime, so the HFONT remains valid till the end of
the function.
Using the window DPI resulted in returning a twice bigger size in points
than the size really used for the windows on high-DPI monitors as,
apparently, RichEdit always uses DPI of 96 internally (tested with both
wxTE_RICH and wxTE_RICH2 in 192 DPI under Windows 10.0.16299.785).
This will be useful elsewhere too and makes SetFractionalPointSize()
implementation less fragile as we don't have to be careful about
changing pointSize member before setting lf.lfHeight any more.
These functions are not really useful as converting between wxFont and
LOGFONT can be done trivially by passing via wxNativeFontInfo and, in
fact, wxCreateFontFromLogFont() managed to do the conversion wrongly by
forgetting to update wxNativeFontInfo::pointSize member when changing
wxNativeFontInfo::lf.
This fixes one unit test failure after the latest changes, although not
yet the other one, see the upcoming commit for this.
