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.
Pixel values in XRC can never be correct for high resolution displays, unlike
the pixel values passed to wxWidgets API, which could be already adjusted to
account for the resolution or obtained from resolution-dependent text metrics,
so scale them by the factor appropriate for the current resolution
automatically.
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.
This allows to give the exact line number of the error, unlike asserts that
happen in wxSizer code which don't point exactly to the error location when
sizers are created via XRC.
It also has the advantage of allowing to detect wrong use of wxALIGN_LEFT and
wxALIGN_TOP, unlike the asserts which can't do it because the value of both of
these flags is 0.
Detect using flags corresponding to the major sizer direction (which doesn't
make sense as only the proportion governs the behaviour in this direction) and
also combinations of alignment flags with wxEXPAND.
Selecting an already selected radio menu item didn't generate any events in
wxGTK nor in wxMSW with the top level (i.e. attached to a menu bar) menus but
did send them for popup menus under MSW.
Make the last case consistent with the rest of them and don't send any events
in this case neither.
Closes#16891.
The only attribute for this control is a boolean "running" which can be set to
start the indicator on load.
Update the schema, documentation and the XRC sample.
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.
Somehow more files appear as modified now, after fixing "all" of them in the
previous commit. Convert these files as well. Will there be more in the next
clone?
Use both the contents and the header width when wxLIST_AUTOSIZE_USEHEADER is
given instead of just the latter.
Also make both wxLIST_AUTOSIZE_USEHEADER and the previously implemented
wxLIST_AUTOSIZE work efficiently for the virtual list controls by reusing
wxMaxWidthCalculatorBase already used in the generic wxDataViewCtrl.
Closes#10326.
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?).
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
The table of contents is over 600 pages long with the default
settings. Now it only lists down to section, and runs 45 pages.
Section numbers were also colliding with names, so this fixes
the margins in the table of contents.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78455 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Using a custom header is an "experimental" feature since it bypasses
several Doxygen configuration options, and skips configuration
changes necessary for all automatically generated LaTeX.
This continues to use the nicer looking custom header, but brings
it up-to-date with the automatically generated one from 1.8.8.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78450 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
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
Don't use the generic focus saving/restoring code for wxMDIParentFrame in
wxMSW as it already saves and restores the active MDI child on its own and we
should let it do it, as our code could change the active child when restoring
focus if it hadn't been saved correctly previously.
The fact that it is isn't saved is another bug, but even if it is fixed, we
should let MSW MDI implementation handle activation as we can't do it any
better -- but can do worse, as the bug described in #16635 shows.
Closes#16635.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78341 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Even though this is typically the case, some strings in Windows registry are
not NUL-terminated, deal with them correctly by using the explicit length.
Closes#16719.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78327 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
Remove wxDesigner which is not offered any more and add wxCrafter.
Also use more neutral "form designer" term to avoid giving the impression that
these tools can only be used for the dialogs.
Closes#16744.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78310 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
Remove obsolete warning about gettext 0.10, add a link to Poedit instead.
Also fix Doxygen markup: @see can't be used inside a list item.
See #16714.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78257 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Correct the "pushed" state determination in our own drawn code, it didn't work
for wxToggleButton which doesn't return BST_PUSHED from BM_GETSTATE. But it
does have BM_GETCHECK returning its state directly, so add a new virtual
MSWIsPushed() method and implement it differently for it.
Closes#13755.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78251 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Windows doesn't use the correct image for checked disabled tools, at least up
to and including Windows 7, so don't put such tools in the "checked" state at
all: this doesn't matter as they are disabled anyhow, but shows the correct
image for them.
Closes#12989.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78248 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
While calling SetToolTip(wxToolTip*) overload already worked correctly for
wxCompositeWindow, using SetToolTip(wxString) did not if a tooltip already
existed, as it didn't use the virtual DoSetToolTip() in this case, resulting
in e.g. impossibility to update wxSpinCtrlDouble tooltip using this method.
Fix this by introducing DoSetToolTipText() virtual which is used by that
overload now and overriding it in wxCompositeWindow.
Also don't override DoSetToolTip() in wxSpinCtrlGenericBase any more, it is
not necessary as it's already done by its base class wxCompositeWindow.
Closes#16595.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78245 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
This means it can be now done in wxEventLoopBase itself and calls to
ProcessIdle() in the port-specific code are not needed any more, so remove
them.
This introduces a change in behaviour for wxMSW, where idle event handlers
were not invoked from inside wxYield() at all previously, and for wxOSX, where
only a single idle event is now generated from wxYield() instead of a stream
of them until no idle handler needs any more of them as before. But on the
bright side, the new behaviour seems to make most sense and is now the same in
all ports.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78222 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Modify wxPropertyGridManager::RecreateControls() to allow adding/removing categorized/alphabetic mode buttons to/from wxPG manager tool bar at any time (not only when creating the tool bar).
Modify wxPropertyGridManager::SetExtraStyle() to fully support manipulating these buttons via wxPG_EX_MODE_BUTTONS flag.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78149 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
