Using FromDIP() in wxXRC broke creating controls whose width or height was
specified as -1 as it became -2 when sufficiently high DPI was used, and so
lost the special meaning of "unspecified" that -1 had.
Avoid this problem by never scaling -1 in FromDIP(), this is unlikely to ever
be useful and could result in more difficult to debug problems in the future.
This was already mentioned in wxToolBar documentation, but mention it also in
wxToolBarToolBase and remove the modifier methods from the documentation
completely, they have nothing to do there as they are not part of the public
API at all.
See #16985.
Don't allow specifying the directory in the former and do check for the
directory existence in the latter.
Also update the file shown in the dialog in SetFilename().
Closes#16685.
Scale the (still hard-coded) border in pixels by the content scale factor for
the platforms where this needs to be done, i.e. not wxGTK nor wxOSX where the
underlying toolkit already does it.
Allow calling this method with either wxSize, wxPoint or just an int.
Also provide a static overload allowing to use it even when no appropriate
wxWindow is available.
The shadow width was only used by wxMotif and bezel face not used at all since
a very, very long time, so just remove these methods from the ports which still
had them (just doing nothing) and remove support of the corresponding XRC
attributes.
Allow overriding wxEXPAND effect in one of the directions by specifying
wxALIGN_{RIGHT,BOTTOM} or wxALIGN_CENTRE_{HORIZONTAL,VERTICAL} together with
it (unfortunately this doesn't work for wxALIGN_{LEFT,TOP} as their value is 0
and so their presence in flags can't be detected).
This is a simple animated control indicating some program activity.
Provide native GTK+ (for > 2.20) and OS X implementations as well as a generic
one used under MSW.
Update the sample and the documentation.
This method allows to scale a pixel value by a DPI-dependent factor to the
value used by the underlying toolkit only if necessary, i.e. when not using
GTK+ 3 or OS X which already do this internally.
When launching child processes it can be convenient to be able to switch to
them later, provide a method in wxProcess to do it.
Currently this is only implemented in wxMSW but could almost certainly be done
for wxOSX too (it can be done using Apple Script, so presumably there is a way
to do it programmatically as well) and could be also made to work at least
under some Unix systems by emulating what wmctrl does (or just launching it?).
Don't use NSCriticalAlertStyle for wxICON_WARNING unconditionally, this
was a violation of the OS X guidelines. According to the hig HIG,
NSCriticalAlertStyle (aka caution icon) is only appropriate in rare
cases and only if the user is performing a task that might result in the
inadvertent and unexpected destruction of data.
It therefore doesn't make sense to use it for information warnings, but
only for _questions_, and so NSCriticalAlertStyle is only used if a
combination of wxICON_WARNING with either wxYES_NO or wxCANCEL is used.
Make wxICON_WARNING and wxICON_ERROR the primary constants for their
purpose and define their visual Windows-based synonyms wxICON_HAND and
wxICON_EXCLAMATION in terms of the semantic ones, instead of the other
way around.
Currently this only really works when using the standard US keyboard layout as
we don't have information about the mapping from the characters to the keyboard
keys for the other layouts, which is not ideal but better than nothing as it
allows e.g. Text("foo_bar") to really produce "foo_bar" in the currently
focused text control instead of "foo-bar" as before.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78495 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is a simple high level helper combining an arbitrary control showing
multiple items with the buttons allowing to add items to and remove items from
this control, but using the buttons and the layout appropriate for the current
platform.
Add the implementation itself, an example of using it to the dialogs sample
and the documentation.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78462 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
LaTeX fails to handle tables nested in @param sections, and we've
only used them to expand on enums that should be documented on
their own anyway, so the docs have been extracted here.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78452 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Homogenize the behaviour of all ports when creating bitmaps with 0 width or
height: just fail always as it doesn't seem to make sense to support this.
Closes#16828.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78434 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't claim that SetPriority() can only be called before the thread is
created, this is just wrong.
Do document that it must be done after creating the thread in wxMSW (this is a
limitation of this port as POSIX implementation allows calling it at any
moment and could be lifted in the future).
Closes#16809.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78418 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
These macros are useful for functions called from other macros to allow
pretending that an assert inside such function actually happens at the point
in the sources where the macro itself appears.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78409 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Reverts r78136 (see #15727) because the multi-string values in Windows
registry are actually not "name=value" pairs at all but just NUL-separated
strings and the API provided for reading them was inappropriate.
Also see #16719.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78326 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Don't prevent people from using hints in wxMSW and wxGTK2, where they work
with multiline text controls too, even though they do not work with wxGTK3 nor
wxOSX.
Closes#14456.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78316 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This fixes formatting of the Doxygen-generated docs (maybe we should just
switch to the civilized spelling of "eg" and "ie" instead?).
See #16744.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78308 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This makes it possible to refer to the associated wxVariant types without hard
coding the string constants, i.e. instead of writing "string" (error prone as
typos are not detected) it is now possible to write wxDataViewTextRenderer::
GetDefaultType().
This will also make it simpler to write generic (in C++ templates sense) code
using renderers.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78288 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Send these events to the menu itself first, then to the menu bar containing
it or the window invoking it if it's a popup menu and, finally, to the top
level window in all of wxGTK, wxMSW and wxOSX.
In particular, this ensures that help strings are now shown in the parent MDI
frame status bar by default, even when the menus are attached to the client
MDI frame or shown as popup menus.
At the implementation level, this logic is now encapsulated in a new static
wxMenu::ProcessMenuEvent() method which can be easily modified and reused in
other ports.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78230 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
