Using a wrong parent for the window managed by the sizer of the given
window or, alternatively, inserting a window into a wrong sizer, seems
to be a common mistake when creating sizer-based layouts and results in
hard to understand visual problems (as typically the window with the
mismatched parent/sizer just remains stuck at some wrong location).
So try to help detect it sooner and provide more information about the
problem by checking the parent of the window either when it is added to
the sizer -- if we already know which sizer the window is associated
with at that moment -- or when associating the sizer with the window
later.
This function was broken when it was called for a window which was not
the window the sizer was associated with since the recent (pre-3.1.5)
changes trying to work around the problem with the initial windows size
when using GTK 3, see 9c0a8be1dc (Merge branch 'gtk-initial-size',
2021-04-13).
Fix it by passing the sizer to use for calculating the size explicitly
to WXSetInitialFittingClientSize() when we have it, and only falling
back on the window's own sizer if we don't.
Closes#19170.
This provides a less intrusive, and also usable by the end users rather
than only by the developers, way of doing the same thing as the just
added wxSizerFlags::DisableConsistencyChecks() does.
Add wxWindow::WXSetInitialFittingClientSize() instead of handling wxGTK
TLWs specially in the common wxSizer code and override it in wxGTK to
remember that we need to reset the client size once the window is shown.
This commit shouldn't result in any changes in the observed behaviour.
This trivial function just allows to avoid checking if wxTheApp is not
null before calling GetTopWindow() on it.
Replace the existing "wxTheApp && wxTheApp->GetTopWindow()" calls with
wxApp::GetMainTopWindow().
No real changes.
Add the sizer item to the sizers items list only after calling of
wxWindowBase::SetContainingSizer() because it can throw (if it asserts
and the assert handler throws an exception, as happens in our own unit
tests) and then the sizer item would be kept in the sizers items list
but m_containingSizer wouldn't be set for the window.
Remove support for Borland C++ compiler, it wasn't tested since a long
time and probably didn't work anyhow and there was no interest in
keeping support for it since many years.
See https://github.com/wxWidgets/wxWidgets/pull/2087
This function replaces some uses of GetContentScaleFactor(), where a
factor greater than 1 must be used even under the platforms not doing
any logical/physical pixel mapping, such as MSW.
For now GetContentScaleFactor() is still unchanged, but it will return 1
for such platforms in the future and adding GetDPIScaleFactor() allows
to avoid changing the behaviour of the code which relied on its current
behaviour.
If wxSizerItem passed to Replace() contains a window, the window must be
associated with the sizer to ensure that it is uncoupled from it when it
is destroyed.
Add a simple test which resulted in a use-after-free before but passes
now.
Don't assert in wxBoxSizer when both alignment flags and wxEXPAND are
used together if wxSHAPED is also used, as such flag combinations may
make sense and so shouldn't be forbidden.
Add a unit test checking that this is allowed.
The new method takes minimal size just computed by RecalcSizes() as its
argument making it unnecessary to store it as a member variable in the derived
classes such as wx{Box,FlexGrid}Sizer.
The old method can still be overridden for compatibility and by the derived
class that don't need minimal size when updating children.
Make the code simpler and, in a couple of places where the fall back to
the primary display in case wxDisplay::GetFromWindow() returned -1 was
missing, also more correct.
InformFirstDirection() is required to let wxWrapSizer calculate its best
height from its current width (or vice versa, but usually in this
sense), but it only worked if wxWrapSizer was an immediate child of
another size doing layout but not if wxWrapSizer was inside another
wxBoxSizer which was contained in a top-level sizer.
Explicitly forward calls to InformFirstDirection() to wxBoxSizer
children to fix this and make wxWrapSizers nested in wxBoxSizer work.
Note that there are still many problems in this code, including but not
limited to:
- Doing this forwarding for the sizer minor direction only.
- Not passing the correct value of "availableOtherDir".
- Still calling InformFirstDirection() from RecalcSizes(), when it's too
late to change the min size returned by CalcMin().
- Inconsistency: wxGridSizer calls InformFirstDirection() from its
CalcMin(), wxFlexGridSizer calls it from its RecalcSizes(),
wxGridBagSizer doesn't call it at all.
All this size-in-first-direction logic really needs to be completely
reviewed, but for now at least make wxWrapSizer inside a wxBoxSizer work
as well, or as badly, as wxWrapSizer on its own.
Factor out the code from wxStaticBoxSizer dtor into a wxStaticBox method
to improve encapsulation: the static box knows better than another class
how to detach its children from it before destroying it.
No real changes yet.
In wxStdDialogButtonSizer, keyboard navigation order through the buttons
should be the same as the order they are positioned in the sizer regardless
of the order the were created or added to the sizer.
Closes#17940.
wxSizer already has m_minSize field, use m_calculatedMinSize for the field of
the derived wxBoxSizer class to avoid confusion, just as wxFlexGridSizer
already did.
Also add a new unit test checking that GetMinSize() still works after this
change.
This seems to be just unnecessary as RecalcSizes() is only supposed to
reposition the child elements and CalcMin() will be called later again if the
min size needs to be recomputed.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
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.
Complain if wxEXPAND is combined with both horizontal and vertical alignment
flags, as this doesn't make sense and, moreover, the behaviour has changed
since the last commit: now wxEXPAND is ignored instead of overriding the
alignment flags if they are combined.
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).
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.
We can't check for all the invalid combinations, but at least check for
wxALIGN_CENTER_HORIZONTAL+wxALIGN_RIGHT and wxALIGN_CENTER_VERTICAL+
wxALIGN_BOTTOM which never make sense and can be detected.
This is an incompatible change compared to 2.8 which can make the existing
code crash and it also goes against the usual rule that the windows are never
owned by sizers, only other windows.
Closes#15698.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75921 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Ensure that {Begin,End}RepositioningChildren() are called before/after
changing the positions of multiple children, whether we're using sizers or
constraints.
This fixes display corruption which could happen under Windows 7 and a child
resized first became bigger, pushing off the children resized later.
Closes#15214.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74067 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxStaticBoxSizer should be considered shown if its static box is shown, even
if it has no elements (or all of them are hidden).
Closes#14698.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73729 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxSizerItem::AddBorderToSize() added in r72344 (see #11497) didn't work
correctly as it replaced unspecified (i.e. set to -1) components of wxSize
with the small positive values that did take effect, contrary to the
intention.
Fix it to only adjust the actually set component(s) of wxSize.
Closes#14696.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@72586 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
