Fix incorrect conflict resolution between the changes of r73823 and r73850:
the first renamed wxEVT_COMMAND_DATAVIEW_COLUMN_HEADER_RIGHT_CLICKED to
wxEVT_COMMAND_DATAVIEW_COLUMN_HEADER_RIGHT_CLICK while the latter renamed it
to wxEVT_DATAVIEW_COLUMN_HEADER_RIGHT_CLICKED. The proper new name is
wxEVT_DATAVIEW_COLUMN_HEADER_RIGHT_CLICK, use it instead.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73851 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use the same short names as are used by the event table macros for the event
type constants themselves. This makes them much more comfortable to use, e.g.
Bind(wxEVT_BUTTON) compared to Bind(wxEVT_COMMAND_BUTTON_CLICKED).
The old long names are still kept for backwards compatibility and shouldn't be
removed as it doesn't really cost anything to continue providing them, but all
new event types should only use the short versions.
Closes#10661.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73850 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Amend the changes of r73839:
- Don't use covariant return type for wxHtmlWinTagHandler::GetParser() as
VC6, which we still support, doesn't like it. Besides, this seems
unnecessary.
- Don't make GetParser() virtual at all as this doesn't appear to be necessary
neither.
- Add "@since 2.9.5" to the documentation of the new method.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73849 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Add the simplest and most fool proof of chaining the pages in static wizards:
just chain several calls to the new, non-static, wxWizardPageSimple::Chain()
overload.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73806 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
By default the columns are auto-sized to fit just their label, which is fast
but not very user-friendly. Allow customizing this behaviour by handling the
(new) wxEVT_GRID_COL_AUTO_SIZE event.
Closes#15077.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73789 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't include wxBORDER_NONE in neither wxToolBar ctor and Create() nor
wxFrame::CreateToolBar() flags parameter, override GetDefaultBorder() in
wxToolBar itself instead to use the border style appropriate for the current
platform by default. This has the same effect -- the default border style is
used unless another one is explicitly specified -- but is more clear and
consistent.
Also add wxTB_DEFAULT_STYLE for consistency with the other classes.
Closes#15037.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73757 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
GTK+ applications don't use sunken status bars since many years, do don't do
it in wxWidgets neither by default any more. Add wxSB_SUNKEN style that can be
explicitly used if the old appearance is desired.
Closes#15009.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73691 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't say "is supported" when meaning "if supported" and, in fact, remove this
part entirely as these styles are supported by all implementations.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73676 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This method couldn't be overridden by the classes deriving from wxLogWindow
because it was called (indirectly) from wxLogWindow ctor itself and so was
completely useless. Just remove it to avoid confusion.
Closes#12763.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73622 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Implements native UI for preferences editing. In particular, the API
handles the differences between modal (Windows) and non-modal (OS X) preferences windows and provides platform's native look.
Currently implemented natively for wxOSX/Cocoa, wxGTK and Windows (the latter is used as a fallback generic implementation as well).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73576 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
As MSW native control centers the image, it must be entirely redrawn when the
area in which the image is centered changes, but it doesn't happen by default,
so do it ourselves explicitly.
Also explain that this centering behaviour is platform-specific and shouldn't
be relied upon.
Closes#4564.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73485 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxBU_EXACTFIT in wxMSW only affected the width of the button but not its
height, which was still made as big as the standard button size as otherwise
the button text was rendered badly. However there is no reason to do this for
the buttons without any text, so let wxBU_EXACTFIT be really exact, in both
directions, in this case.
Also document this rather non obvious wxBU_EXACTFIT behaviour.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73461 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
