For consistency with wxListCtrl under MSW (which is the only platform
where this change has any effect, as wxHD_BITMAP_ON_RIGHT is only
supported there), put the column images on the right side in
wxDataViewCtrl too.
Closes#13350.
It was unexpected that this method could only be used for horizontal
gauges, so make it work for the vertical ones if wxCONTROL_SPECIAL flag
is specified.
Update MSW and generic implementations and the render sample to show a
vertical gauge as well.
This method is used to illustrate the difference between the default and
the overridden GetHeaderButton() implementations, but doesn't need to be
used for any other methods, that are not overridden in MyRenderer.
No real changes, but just make the code shorter and less confusing.
The old wxEVT_SEARCHCTRL_{SEARCH,CANCEL}_BTN event names were unwieldy
and misleading because both of these events can be generated without
using the buttons, but by pressing Enter or Esc (the latter currently
works under macOS only, but this could change in the future).
wxMediaCtrl doesn't compute its best size correctly until a video is
available and this resulted in using the best size of (0, 0) for it and
nothing being shown at all on the screen, even after starting to play a
video.
This is almost certainly a problem on its own, as there is some existing
code for updating the best size and redoing the layout of the parent
sizer when a new video is loaded, but for now just make the control
visible in the sample again by always expanding it to fill up all the
available size, as this is the smallest possible fix and this is how it
used to behave before, until 9aaa38c7c8,
which allowed to meaningfully use wxALIGN_CENTER_HORIZONTAL and wxEXPAND
together: until then, this didn't work at all, but the sample still used
wxALIGN_CENTER_HORIZONTAL by mistake, so just remove it now to restore
the original behaviour.
Closes#17917.
Call DoUseCustomAutoComplete() function instead of using an artificial
event.
Also move the menu item in the radio group with the other
autocomplete-related commands as it's exclusive with them.
Provide an accelerator for the menu command which contains all of the
test functionality to make it simpler to test it.
Also use CreateButtonSizer() instead of creating wxStdDialogButtonSizer
manually to make the code shorter and to also ensure that the "OK"
button is correctly set up as the default one, allowing to press "Enter"
in this dialog to accept the entry on any control, which didn't work
before.
This undocumented "private" class was used for various windows UxTheme
functions which are available since WinXP. As wxWidgets 3.1 is XP+ it
does not make sense anymore to load the theme functions dynamically.
The underlying Windows TaskDialog supports adding an additional footer
to the message dialog. This makes the native functionality available
and implements it in the generic version.
See https://github.com/wxWidgets/wxWidgets/pull/573
Recent optimizations avoiding resort on item change (see
https://github.com/wxWidgets/wxWidgets/pull/642) have also optimized
away refreshing the modified item, which was done implicitly, as a side
effect of resorting, before, so the changes were not reflected on
display immediately any longer.
Fix this by simply refreshing the item explicitly and also add a way to
test for the correct behaviour in the sample.
Add missing header, source and resource files.
Add missing data files (font), remove deleted data files (help).
Fix specifying xrc sample data files.
Remove WXUSINGDLL check from dialogs sample, it is not defined in e.g. static gui build.
This does what 1c2e58cd85 tried to do
manually correctly, by updating bakefile and rebaking, and so finally
completing the changes of 961a1c2b39.
See #17962.
Allow specifying arbitrary windows as labels for the static boxes
created from XRC.
Note that wxStaticBox XRC handler itself wasn't updated to support this,
as this handler seems to be quite useless because it's impossible to
define any box children with it, so only wxStaticBoxSizer XRC handler
really matters, anyhow.
Allow reusing this functionality from outside the library, it can he
useful if an MFC window needs to be embedded into a wx application (or
vice versa).
Also use a better wxEntryStart() overload as a side effect, this should,
in particular, fix the problem with command line arguments processing in
mixed MFC/wx applications pointed out in a comment in the sample
previously.
Add CMake-based build system.
Merge the original branch without any changes except for resolving the
conflict due to moving the contents of .travis.yml to a separate file by
propagating the changes done in this file since then to the new script
and rerunning ./build/update-setup-h and ./build/cmake/update_files.py
to update the file lists changed in the meanwhile.
Closes https://github.com/wxWidgets/wxWidgets/pull/330
Make "Exit" menu item really exit the sample again instead of just
closing the main window, but possibly leaving the gestures testing
window still open and thus not really exiting the program.
Also avoid creating more than one gesture window, use the existing one
if we had already opened it.
