This parameter is not modified by wxColourDialog (this might have been
the case, or at least the plan, some long time ago) and so has no reason
not to be "const".
Just add the qualifier to ctor and Create() in all ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/1421Closes#12511.
We need to wait until wxDataViewCtrl is realized for its columns widths
to be actually set, as calling gtk_tree_view_column_set_fixed_width()
just queues a resize that will take effect later, as documented in the
previous commit.
It may be surprising that calling GetWidth() after SetWidth(100) still
returns 0, so at least document this behaviour (fixing it doesn't seem
to be easily possible).
Reading native font info strings in v0 format, used by the previous
wxWidgets versions, resulted in creation of fonts with 0 point size,
which resulted in suboptimal user experience when such a font was used
to display text.
Fix this by initializing point size to the value corresponding to the
font height in pixels using the default DPI, just as we already do when
creating wxNativeFontInfo from a LOGFONT.
No real changes, just refactor the code previously present in both
wxNativeFontInfo ctor and SetPixelSize() in a single function and reuse
it in both places.
This not only cuts down on its size, but will make it simpler to skip
this test in the environments where web access is unavailable in the
upcoming commit.
These metrics can change when the DPI of a Window changes, so we can not keep a
static reference.
According to documentation, the second parameter (uiParam) should be set to the
size of the NONCLIENTMETRICS object.
For the sake of consistency with documentation of other controls like e.g.
wxGrid, the list of events should be presented on the wxPropertyGridEvent
page so it should be moved there from the main wxPropertyGrid page.
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.
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.
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.