Current wxPG_FILE_DIALOG_TITLE and wxPG_DIR_DIALOG_MESSAGE attributes can be used to customize editor dialog titles only for wxFileProperty and wxDirProperty, respectively. New wxPG_DIALOG_TITLE property is applicable to all properties derived from wxEditorDialogProperty so not only editor dialog titles for wxFileProperty and wxDirProperty can be set but also for wxFontProperty, wxLongStringProperty, etc.
wxPG_FILE_DIALOG_TITLE and wxPG_DIR_DIALOG_MESSAGE attributes are marked obsolete.
Add a new flag wxXRC_USE_ENVVARS for wxXmlResourceFlags that triggers a
call to wxExpandEnvVars() for bitmap, icon and animation paths.
This flag is not set by default to avoid silently changing the behaviour
of existing applications.
Closes https://github.com/wxWidgets/wxWidgets/pull/1445
C++20 introduces these two functions, along with some overloads, to
std::string. Add similar functions to wxString, which simply call the
already existing StartsWith() and EndsWith().
Closes https://github.com/wxWidgets/wxWidgets/pull/1452
13068d3603 introduced code for stripping
CJK mnemonics (i.e. trailing " (&X)") from the menu items, but due to
the use of wxStripMenuCodes() in wxControl::GetLabelText(), it also
applied to the control labels, resulting in wrongly measuring their size
(because the text used for measurement didn't include the "(&X)" part)
and truncating them in display.
Fix this by adding an explicit wxStrip_CJKMnemonics and using it only in
the code dealing with the menu item labels. This requires more changes
than just modifying GetLabelText() to use some wxStrip_NoCJKMnemonics
flag, but is more compatible as it's not impossible that some existing
code using wxStripMenuCodes() could be broken by this change too, while
now the existing behaviour is preserved.
Also improve wxStrip_XXX documentation.
Closes https://github.com/wxWidgets/wxWidgets/pull/1439
See #16736.
Closes#18452.
Use special values of DisplaySection() and KeywordSearch() parameters to
open the table of contents (if section is -1) or search page (if the
keyword to search for is empty) when using CHM help controller.
This is less discoverable than having separate Display{TOC,Search}()
methods, but avoids introducing special API that couldn't be implemented
in the other wxHelpController implementations.
Closes#18445.
Add wxRendererNative::GetExpanderSize(), implement it using the
appropriate theme element and use it instead of hardcoding the expander
size to 3 character widths.
Closes https://github.com/wxWidgets/wxWidgets/pull/1431Closes#18449.
In wxGTK using negative coordinates with HitTest() happens to work and
it's useful to test that it does, as this test will run when the control
is scrolled even under Travis CI, unlike the test with positive
coordinates which doesn't work under Xvfb there and was disabled in the
previous commit.
Also document that passing negative coordinates to this function only
works in wxGTK.
Adobe have announced the official EOL for flash is 2020 so we're
now at the point where support for flash just isn't interesting
any more.
It doesn't make sense to support it for the upcoming 3.2.x release
series, and the sample .swf files are lacking source code.
Closes https://github.com/wxWidgets/wxWidgets/pull/1427Closes#15886.
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.
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).
Add wxGrid::FreezeTo() method which allows to freeze the given number of
columns and/or rows at the beginning of the grid, i.e. keep them pinned
in place while the rest of the grid is scrolled.
The main wxGridWindow (m_gridWin) now corresponds to the non-frozen part
of the grid, with up to 3 new similar windows for the frozen
rows/columns and the frozen corner cells (which only exist if both rows
and columns are frozen) being additionally used.
Doing this involved adding "wxGridWindow*" parameter to many functions
that previously only worked with m_gridWin itself and addressing
additional complications, such as mouse events that can now cross
different windows.
See https://github.com/wxWidgets/wxWidgets/pull/952 for the original
version of the changes.
This method can be overridden to indicate that the scrolled window
doesn't want its children to be scrolled into view when they're focused,
which is the default behaviour.
Also reuse this method for Mac-specific scrollbar workaround.
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.
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.
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.
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.
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
This class seems to be implemented in all the major ports, so remove
note saying that it supports dragging files from the applications only
under MSW.
Closes#18437.
Tick marks were not available for wxSlider under GTK+ 2 or GTK+ 3
implementations of wxWidgets. However, tick marks have been available
for the GtkScale widget since GTK+ 2 version 2.16.
This change adds similar functionality in relation to tick marks
as was already available in wxMSW builds.
Closes https://github.com/wxWidgets/wxWidgets/pull/1355
Document the discrepancy between constructing wxGCDC from
wxGraphicsContext directly or default-constructing it and calling
SetGraphicsContext() later.
Current behaviour is somewhat inconsistent, but useful, because it
allows to draw on wxGraphicsContext using wxDC API using any kind of pen
and brush, even those not supported by this API, while remaining
backwards-compatible (i.e. we can't change SetGraphicsContext() to not
re-apply font, pen and brush, as this would break any existing code
relying on this happening), so it seems like the best alternative.
When creating wxGCDC from an existing wxGraphicsContext, it is better to
keep using the attributes (such as font, pen, brush) already configured
for it rather than overwriting them with the default values, which is
not very useful, unlike the new behaviour, which allows to configure
wxGraphicsContext using features not supported by wxDC API (e.g. alpha
channel for pens/brushes) and then use it via wxDC API only (allowing
the existing legacy code to use alpha, for example).
wxUIntProperty::DoValidation() is already declared as private and the same access level should be applied to DoValidation() in other numeric properties because these functions are helpers intended for internal use only.
