In practice, almost everybody using validators also seems to use this style,
so make it the default (this hadn't been done when it was originally
introduced because of compatibility concerns, but now, 15+ years later, it's
probably safe enough to change this).
This adds an additional screen to the drawing sample showing all available wxSystemColour values. It makes sense for testing these values but also provides a convenient overview of available colours for the library user.
It's impractical to have manual projects for all the samples, but do it at
least for this one to serve as a starting point for people using these IDEs.
Contents of controls (like ListBox, Choice, ComboBox) created with wxXX_SORT flag is sorted in dictionary order and therefore reference data items used in tests in widgets sample need to be sorted in this order too.
See #15896.
Leave ownership of the native window to the user code as it may want to reuse
it for some other purpose and provide an explicit Disown() function that can
be called if the user really wants wxWidgets to take ownership of the native
window.
In particular, this avoids problems when using ARC under OS X which resulted
in a double "release" before.
Cocoa has been the default toolkit in wxWidgets for a long time. There is really no good reason to use Carbon in 2016 and this removes a lot of unused and unmaintained code.
Finish the work started in 11a5b83e2c by moving
more wxAppProgressIndicator-related parts of wxMSW wxGauge implementation into
the base class and reusing them from the wxOSX version.
Also remove MSW-specific test for wxUSE_TASKBARBUTTON from the widgets sample
which prevented this style from being taken into account at all under Mac.
See #16638.
This is similar to f74379c751 but specific to
wxMSW MDI code: also call wxMenu::UpdateUI() without any parameters from it
instead of overriding its logic for determining where to send the events.
Add code to the mdi sample demonstrating that the event handlers in the window
itself and its MDI frame parent get the events they're supposed to get.
See #17352.
Ask the user when closing the window with several MDI frames opened, if only
to demonstrate how to do it, but not if there is only one window as this is
just too annoying when using the sample for testing.
Make wxGenericListCtrl used under wxGTK and wxOSX behave the same as the
native wxMSW wxListCtrl and wxTreeCtrl under all platforms and only generate
ITEM_RIGHT_CLICK events when an item was actually clicked, i.e. don't generate
them for the clicks completely outside of the client area.
Closes#4711.
This allows a bitmap to scale with the size of the wxStaticBitmap control.
Scaling can be controlled to fill the control with or without changing the
bitmaps aspect ratio.
For some systems (like OS X, GTK+ 3) drawing with transparency is supporting by native wxDC and in this case "Alpha screen" sample can be shown even if wxGraphicsContext is not used/enabled. For such wxDC's all drawing operations can be done directly without using wxGraphicsContext.
Because graphics renderer is not only selected via menu but also directly in the application (in MyFrame::OnShow) there is necessary to update menu items responsible for selecting graphics context to represent current state of the application.
This is done in EVT_UPDATE_UI handlers where there is checked what graphics renderer is currently in use and state of the menu items is updated accordingly.
Closes#16971.
There were added two menu items (under 'Tools' menu) to modify current tool spacing.
This way is possible to test SetToolPacking/GetToolPacking methods.
Allow automatically converting lower-case letters entered into wxTextCtrl to
upper-case equivalents. Provide generic fallback and implement the method
natively for all the major platforms.
Also update the text sample to show it in action.
"%d" can't be used for size_t which may be of greater size than int, so use
"%lu" with a cast to unsigned long, as is done elsewhere because "%z" is
unfortunately not portable.
Closes#17255.
This style was unconditionally used for all multiline controls for some
reason, meaning that wxEVT_TEXT_ENTER could be received even for the controls
not using wxTE_PROCESS_ENTER explicitly, which was unexpected.
Don't do this any more to conform to the expected behaviour.
Also do use wxTE_PROCESS_ENTER for the text control supposed to allow handling
"Enter" in the text sample: surprisingly, it didn't have this style before,
although it was clearly supposed to.
Closes#1913.
This might indicate a bug with the default size being too small for wxTextCtrl
in wxOSX, but without this change the control was barely big enough to show
one line of text under OS X 10.8, so make it bigger to have a more reasonable
initial appearance.
This should have been done in d24f711f88 a year
ago but that commit only updated the makefile of the library itself and not
that of the sample.
See #16624
