The default alignment of the text in wxSpinCtrl was changed to "right"
in 7e4952db83, which added alignment
support (see #10621), but this made it inconsistent with the native
up-down control under MSW and, perhaps more importantly, with spin
controls created from XRC as the default style was never modified there
and did not include wxALIGN_RIGHT.
Resolve this inconsistency by reverting to left-aligning the text by
default.
The horizontal static line was added to separate the button from the
child window when visible, but this didn't seem very useful and looked
bad and was inconsistent with the native GTK+ implementation as well as
similar controls commonly used under MSW (wxOSX already disabled the
static line use).
Just remove it to make things simpler and better looking.
Closes https://github.com/wxWidgets/wxWidgets/pull/804
The previous commit fixed never exiting the event loop in GUI Mac modal
loops but at the price of breaking it for Mac console applications as
Dispatch() never returns for them if there are no more events.
Finally, just don't call Dispatch() at all here, just as it wasn't done
until 9caa3d5d8e and keep only the changes
sufficient for dispatching the pending events and making CallAfter()
work in console applications.
Changes of 9caa3d5d8e resulted in never
exiting modal event loops as wxCFEventLoop::Pending() always returns
true. While this is certainly wrong on its own, for now just avoid using
it and check the return value of Dispatch() instead to allow the modal
event loops to terminate again.
Wrong pointer was used to initialize wxDataViewItem (apparently since
always, i.e. this function could never have been used successfully...).
Closes#18132.
Apply parts of the changes of 34c5aaa769
done in the common code to Mac-specific wxCFEventLoop too.
This is not ideal as we really should reuse the same common code here,
but for now it's better than nothing as previously pending events were
just not dispatched at all in console Mac applications, meaning that
CallAfter() from worker threads never executed.
Owner-drawn buttons with multiline labels were always centered.
Fix this by handling their alignment explicitly when drawing them, as
::DrawText() doesn't do it for multiline strings.
Closes#18131.
It's not possible to map the scaled integer coordinates to the exact
destination location. The inaccuracy can be (mostly) avoided by shifting
the DC origin instead. Also fixes handling of non-zero logical origin.
See #18129
Allow using positions in the entire int range for window positions under
MSW, and not just those in (slightly less than) short range, that are
supported by the native API.
Closes#4262.
Closes https://github.com/wxWidgets/wxWidgets/pull/779
VarSizedStruct buffer had a too small size in Unicode build as it forgot
to multiply the name length by sizeof(TCHAR), resulting in overwriting
memory on the stack after it when calling SymFromAddrW().
Closes#18127.
When determining if a tool is hidden, it takes the width (or height) of
the overflow sizer into account -- but when tools are overlapping, this
is 0. By setting and getting the minimum size of the overflow sizer, the
actual size of the overflow button can be used.
Closes#17960.
Closes https://github.com/wxWidgets/wxWidgets/pull/799
Multiplying 2 float values is promoted to double, which is then narrowed
to float when initializing CGPoint with it, resulting in errors in C++11
build.
Fix this by initializing the CGFloat variable, which doesn't uniform
initialization, to the correct value instead, as this also seems more
clear ("height" is the height at which the strike is drawn).
Closes https://github.com/wxWidgets/wxWidgets/pull/793
Previously, TLW geometry was implicitly defined as just its position,
size and the maximized/iconized state by wxPersistentTLW code. This
already wasn't enough for wxGTK which added the decoration sizes to the
geometry being saved/restored, but this had to be done using conditional
compilation, which was not ideal. And it didn't allow using an entirely
different geometry representation as will be done for wxMSW soon.
Change the code to use wxTLWGeometry class defining the geometry, as
used by the current port, explicitly and move wxPersistentTLW logic into
it, as wxPersistentXXX classes are supposed to be very simple, which
wasn't really the case.
Also provide public SaveGeometry() and RestoreToGeometry() methods in
wxTopLevelWindow, which can be useful even to people not using
wxPersistentTLW for whatever reason.
There should be no changes in behaviour so far.
The changes of 8d02384792 only modified
the generated file without updating the file it was generated from and
so were lost during the next regeneration.
Back-propagate them to the correct file to prevent this from happening.
See https://github.com/wxWidgets/wxWidgets/pull/782
Commit 496da2e550 removed the trailing
spaces from the generated file, but they were reintroduced whenever it
was regenerated.
Really fix this by removing the extra spaces from the script generating
the file.
See https://github.com/wxWidgets/wxWidgets/pull/787
The changes of bf418320b7 only modified
the generated file instead of modifying the file it's generated from, so
were lost during subsequent regenerations.
Fix this by back-propagating them to the correct place.
See #18085.
This will allow this code to work even when implicit conversion from
"const char*" is disabled in wxString and is already marginally more
efficient even now.
See https://github.com/wxWidgets/wxWidgets/pull/782
In certain cases (e.g., virtual machines), the XVideo extension may be
present, but there are no working adaptors. In this case, wxMediaCtrl
will select xvimagesink, but then when it tries to actually play some
media, it will fail. Fix this by attemping to set the video sink to
GST_STATE_READY in TryVideoSink(). Doing this causes gstreamer to run
some checks against the XVideo extension. If this fails, then we should
fall back to the next sink type (ximagesink).
As liblzma API is similar to zlib API, this class is also close to
wxZlibOutputStream, except that it uses reusable functions instead of
repeating their code.
Make it harder for the calltip to be invisible
* This required changes to the Window::SetPositionRelative.
* Use the Qt version as a base.
* The idea is to confine the window to the boundaries of the display the
scintilla control is at the moment of the call.
Closes#18115.
Avoid duplicating base class DoSetSelection() implementation in
wxTreebook, just extend it slightly by using DoGetNonNullPage() to allow
using a (sub-)page if the page associated to the selected item is null
and reuse it.
Also get rid of wxTreebook::m_actualSelection, it seems completely
unnecessary to bother keeping and updating it when we can just find it
whenever we need (which actually seems to only have been the case in the
now removed DoSetSelection() implementation anyhow).
As a side effect of this, wxTreebook pages should now be sizer correctly
when switching to them as DoSetSelection() in the base class does call
SetSize() on the page before showing it, unlike the previously used
version in wxTreebook, which omitted this call for some reason.
There should be no other user-visible changes.
Closes#4379.
Change m_selection in wxBookCtrlBase::DoSetSelection() itself instead of
requiring all the derived class overriding do it in their overridden
UpdateSelectedPage().
No real changes, this is just a small simplification.
No real changes, just simplify the check for whether the page change is
allowed: we can assume it is by default, which means we don't have to
test for SetSelection_SendEvent twice.
