Disabling a window before actually creating it ought to work, similarly
to hiding a window before creating it which can be used to avoid showing
the window on screen at all, even briefly. However it didn't under MSW
where the window was disabled from wxWidgets point of view, but not at
the MSW level.
Fix this by accounting for the enabled state in MSWGetStyle().
Closes#16385.
In wxMSW, the value of the control was modified after executing the
user-defined wxEVT_SPINCTRL handler which meant that any calls to
SetValue() there were effectively ignored.
Fix this and add a unit test checking for the described scenario.
Closes https://github.com/wxWidgets/wxWidgets/pull/1027Closes#18187.
RandomAccessIterator requirements include LessThanComparable, so
implement the missing comparison operators for this class, as well as
for const_reverse_iterator.
This also fixes compilation problems with MSVS 2013 in debug mode, where
the CRT uses these operators to check the iterators correctness.
See https://github.com/wxWidgets/wxWidgets/pull/1048
private field 'm_dwCookie' is not used
'return' will never be executed
result of comparison of unsigned enum expression < 0 is always false
'FlushDC' overrides a member function but is not marked 'override'
potentially uninitialized local variable 'bound' used
Make wxDataViewCtrl::GetIremRect() work under all platforms and improve
tests, documentation and fix a couple of other problems in the same code
area.
See https://github.com/wxWidgets/wxWidgets/pull/1015
For some unfathomable reason IsExpanded() returns wrong value for one of
the items. This should be fixed, but for now just leave a warning in the
test but don't fail it.
Also document this bug to at least spare people some surprises.
A couple of fixes compared to the previous commit:
- Use the correct gtk_tree_view_get_cell_area() rather than
gtk_tree_view_get_background_area() which doesn't work correctly
for the items which are not shown because their parent is collapsed.
- Translate logical coordinates to physical ones using
gtk_tree_view_convert_bin_window_to_widget_coords().
With these fixes, the unit tests for this function pass and can now be
enabled under wxGTK as well.
See https://github.com/wxWidgets/wxWidgets/pull/990
This will allow reusing it in other tests too.
Also make the output slightly more readable by formatting the rectangle
as "{x,y w*h}" instead of "{x,y,w,h}".
No real changes.
No real changes, just avoid mentioning CPPUNIT_ASSERT_EQUAL() in the
comments for the operator<<() overloads as it is used with CATCH too.
Also don't duplicate the same comment 4 times unnecessarily.
This was already the case if the item was not visible because its parent
was not expanded, but now make it also true for the items which are not
visible due to the current scrollbar position.
Add unit tests checking for this and also verifying that GetItemRect()
returns the coordinates in the physical window coordinates.
Replace a redundant (because the same size was already specified in the
ctor) SetSize() call with a Layout() call which resizes
wxDataViewMainWindow to fit the parent control size when using the
generic implementation.
This is important for any tests dealing with the control geometry, i.e.
calling GetItemRect() or HitTest().
Calling GetItemRect() for an item which was not currently visible
because its parent was collapsed resulted in silently returning the
value for a wrong value before the recent fix to GetRowByItem() and in
a crash after it because GetTreeNodeByRow() returned null when passed
invalid row index.
Fix this by explicitly checking whether the item is shown and just
returning an empty rectangle instead.
Also document this behaviour and add a unit test for it.
ChangeValue() must not send events, but did in wxGTK when changing the
contents of a wxTextCtrl to be empty when it had been non-empty before.
Closes#18264.
Comment stated that InsertionPoint() didn't pass, but it was actually
already running (and passing) and the only excluded test was the
TextChangeEvents() one which really should pass for multiline controls
as well, so run it too.
This benchmark shows that wxGetDisplaySize() has only minimal overhead
compared to wxDisplaySize(), but wxDisplay().GetGeometry() is almost 3
times slower (under wxGTK).
wxTreebook is supposed to allow not specifying any valid window for the
top-level pages, but this didn't work any longer, probably since the
changes of 02a92e23f3 (see #4379), as a
possibly null page was dereferenced without checking, resulting in a
crash.
Fix this by adding a missing check.
Also rename DoGetNonNullPage() to TryGetNonNullPage() to make it more
clear that this function can return null and add a unit test checking
that calling AddPage(NULL) really works (or at least doesn't crash).
See https://github.com/wxWidgets/wxWidgets/pull/921
Complete support for fractional point sizes and font weights other than
light/bold.
Also harmonize wxFont API and implementation among all ports (fixing
compilation of those of them that were broken by recent changes).
See https://github.com/wxWidgets/wxWidgets/pull/919
This is a preliminary ARM64 platform support for wxWidgets at "it
compiles" stage. This will allow building and testing wxWidgets based
apps for oncoming Windows 10 ARM64.
Requirements:
- Visual Studio 2017 Update 4 or later with Visual C++ compilers and
libraries for ARM64 component installed
Building:
1. Open command prompt.
2. Change directory to build\msw subfolder.
3. Run "C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Auxiliary\Build\vcvarsamd64_arm64.bat" once.
4. Use `nmake TARGET_CPU=ARM64 ...` to build required flavor of wxWidget
libraries.
Notes:
1. Building of *.sln/*.vcxproj files does not support ARM64 yet. This
requires to hardcode Windows SDK to 10.0.15063.0 or later in
*.vcxproj files, which would render them non-compilable in older
Visual Studio versions. Microsoft is aware of this issue and is
planning a fix in the next version of Visual Studio.
2. wxmsw31ud_gl.dll does not build yet. Awaiting Microsoft to deliver
missing opengl32.lib for ARM64. Please, specify USE_OPENGL=0.
Closes https://github.com/wxWidgets/wxWidgets/pull/923
Check that calling SetFractionalPointSize() and SetNumericWeight() at
the very least results in the expected return values from
GetFractionalPointSize() and GetNumericWeight().
Add wxFontBase::AccountForCompatValues() and use it in all ports instead
of redoing the same comparison with wxDEFAULT in all of them.
This is done not so much to avoid the code duplication, which was
minimal anyhow, but to make the code more clear and make it easier to
remove it from all ports at once in the bright (but remote) future when
we don't need these compatibility hacks any more.
Also document that wxDEFAULT and wxNORMAL are only handled specially in
the old-style ctor taking the individual font components and not the new
one using wxFontInfo and extend the unit test to check this.
Similarly to the previous commit, verify that wxNORMAL, wxITALIC and
wxSLANT still work for compatibility (note the latter is synonymous with
wxITALIC under MSW).
This basically removes the "adv" library, even though it's still
preserved for compatibility with user make/project files referring to
it.
It is done because the distinction between "adv" and "core" was never
really clear (e.g. why wxTreeCtrl was in core but wxTreeListCtrl in
adv?) and it prevented some core classes from using adv ones.
This previously worked in wxGTK, but not in wxMSW and even under wxGTK
it could be surprising that the submenu got the event, but its parent
menu did not.
Make things consistent between the platforms and send the event to the
menu directly containing it first, but then also to its parent menu(s).
Document the new behaviour and verify that it works as intended with a
new unit test.
Closes#18202.
This seems to be the case under all still supported MSW versions, so
remove the note saying that the events might not be sent from the
documentation and add a unit test verifying that they are indeed sent.
Contrary to what the documentation stated previously, this function does
generate the wxEVT_TREE_DELETE_ITEM events for all the items being
deleted, in both MSW and generic implementations.
Update the documentation and add a new unit test checking that the
behaviour really conforms to it.
