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
Save both the normal window geometry and its maximized position instead
of saving just its current position. This fixes restoring geometry of
the maximized windows as previously they were always restored on the
primary monitor, as their original position was lost.
Use the native {Get,Set}WindowPlacement() functions for a MSW-specific
wxTLWGeometry implementation to achieve this.
Closes#16335.
This is similar to a recent commit adding the missing typedefs to wxList
iterators and defines the types required by the iterator concept in
wxVector::reverse_iterator and const_reverse_iterator classes (simple
iterators are just pointers and are already covered by the standard
iterator_traits specialization).
Define "pointer", "reference", "difference_type" and "iterator_category"
typedefs to ensure that wxList iterator classes are seen as iterators by
the standard library in C++11 and later, as otherwise standard container
template ctors taking iterators couldn't be used with them because
they're only available if input iterator requirements are satisfied.
This notably fixes creation of std::list from wxList iterators; add a
test which didn't compile before to show it.
Escape backslashes in wxJSScriptWrapper to allow strings with
backslashes in them to work again -- this was broken while implementing
support for returning values from JavaScript to C++.
See https://github.com/wxWidgets/wxWidgets/pull/741
Overlong (and hence invalid) 4-byte encoding was used for this character
instead of the correct 3-byte 0xEF 0xBF 0xBF sequence.
Fix this by using 3 bytes for the code points up to 0xFFFF included,
instead of excluding it as was done before.
Closes#17920.
This reverts commit 1dd102d741 as it
introduced a crash in the same method when using generic wxDataViewCtrl
implementation, e.g. under MSW, and is not necessary to avoid the crash
with wxGTK3 any longer after the few previous commits.
This undocumented "private" class was used for various windows UxTheme
functions which are available since WinXP. As wxWidgets 3.1 is XP+ it
does not make sense anymore to load the theme functions dynamically.
GTK+ 3 (but not the generic version nor even GTK+ 2, apparently) sends
"selection changed" event from gtk_tree_model_row_deleted() when
deleting the currently selected row, which resulted in sending of
wxEVT_TREELIST_SELECTION_CHANGED events with invalid wxTreeListItem,
containing a dangling pointer, and a crash in the treelist sample when
trying to dump it.
Avoid this by clearing the model (and hence generating these events)
first and deleting the items only afterwards.
Also add a trivial unit test for wxTreeListCtrl::DeleteAllItems(), which
doesn't even allow to reproduce this bug, but is still probably better
to have than not to.
Closes#18045.
Avoid showing message boxes even if we don't have the associated console
as this prevents the test from completing on its own if an unknown
exception happens.
Setting the column sizes fails with wxGTK implementation of
wxDataViewCtrl if the control is not wide enough, apparently, so make
sure it's sufficiently big when creating it to fix the unit test
failures on wxGTK build bot slaves.
This reverts commit 41f6f17d01 ("return 0
(meaning the file is not seekable, as the docs now explain) instead of
4KB for the files in sysfs under Linux") as it seems to be wrong to
return a value different from what "ls -l" or "stat" return here and the
original problem was solved in a better way in the previous commit.
See #9965.
Closes#17818.
There is nothing special about wxTextFile justifying having code for
dealing with non-seekable files in it, so put this code into wxFile
itself and just call its ReadAll() method from here.
This is a better fix than 41f6f17d01
originally applied (and which is going to be reverted next) as it
doesn't break wxFile::Length() for these files and also avoids
triggering an assert if the file we're trying to read was truncated by
another process in the meanwhile -- which can happen and doesn't
indicate a programming error and so shouldn't result in an assert.
Also add a unit test checking that this really works.
See #3802, #8354, #9965.
Calling this function with an unseekable file, such as any file under
/sys on Linux systems, would previously just hang as the loop condition
was never satisfied when length was -1.
Fix this by checking for this case and using a different approach by
extending the buffer we read the data into as we go instead of
preallocating it all at once.
See #9965.
This requires slightly more work, but ensures that we don't leave any
traces of running the tests in the system registry or file system, as we
can just call DeleteAll() on the config object after finishing with it.
It seems better to organize the tests in different files and just
provide a common fixture-like class to reuse functionality.
Also use this as an opportunity to rewrite the tests to use Catch
directly instead of using CppUnit-compatible macros.
Finally, actually build these tests as part of the test suite.
This test didn't make sense at all as it didn't actually test "C" locale
formats as calling setlocale(LC_ALL, "C") didn't actually change the
values returned by wxLocale::GetInfo(), so it still returned the values
corresponding to the French locale set in this test setUp() method and
the test only passed because it used wrong values (i.e. the same ones as
in French locale test).
We also don't have any simple way to test "C" locale formats, we can
only test them for wxLANGUAGE_DEFAULT, but this corresponds to the OS
defaults which can be customized by user (e.g. in the control panel
under MSW) and so we can't expect them to be equal to any fixed values.
The simplest solution is to just drop this test, as it's not very useful
anyhow (French locale test above already covers the same code).
This extends the changes done 01cd702ee3
to another test case and so makes as much sense as the other commit.
It's still not clear what's really going on here as, somehow, this test
passed under AppVeyor before, which shouldn't have been happening if the
explanation in that commit message was correct. And it also doesn't
explain why did it suddenly fail after a completely unrelated change,
see https://ci.appveyor.com/project/wxWidgets/wxwidgets/build/2502/job/l24gc2j0j7h7huxl
Miscellaneous fixes for time zones and DST handling in wxDateTime.
This still leaves 2 big problems:
1. We have no support for using the correct time zone offset at the
given date and always use the current time zone offset, which may,
and often is, wrong.
2. Our code for converting to/from broken down representation doesn't
handle DST at all, so support for DST is non-existent for the dates
before 1970-01-01 or after 2038-01-01 (i.e. roughly outside of the
32 bit time_t range).
See #10445 and the other tickets linked from there.
Converting to another time zone and dealing with DST is completely
useless here, ticks values are always in UTC, so we can just use UTC
values from the beginning.
This ensures that dates are printed out correctly if comparing them
fails.
It might be better to avoid always including this header, but this is
the simplest solution.
Current algorithm used to calculate the bounds of the boxes in the source
image to which the pixels in the target (rescaled) image are mapped to, has
flaws which cause a non-uniform distribution of the boxes in the source
image. And these miscalculations may result in the visible distortions
of the colours in the rescaled image.
New algorithm assures uniform distribution of the boxes in the source image
and thanks to the integer arithmetic is faster than currently used
and not prone to the problems with floating point representation.
Closes#18012.
No real changes, as this doesn't affect this test, but use the new
IsLocal() method instead of comparing the time zone offset with the time
zone, which doesn't work correctly for BST.
wxDateTime timezone-related methods always use the current timezone
offset, while other methods, using CRT, use correct value for the given
date, which may be different.
This discrepancy accounted for test failures in Europe/Minsk time zone
as Belarus has switched from UTC+2 to UTC+3 since 1999 date used in the
test.
It is impossible to really fix the problem easily, so just skip the test
in this case and also mention this bug in the documentation.
See #15370.
Show the loop variable when doing checks inside a loop to make it more
obvious for which test case the failures occur.
Also use CHECK(), instead of REQUIRE(), to which CPPUNIT_ASSERT_EQUAL
expands, to continue with the other loop iterations after failure.
No real changes, just show the variable values if any checks fail and
also continue running the test for the other data points even if one of
them fails.
Don't rely on time zone offset to check whether it is local as this
doesn't, and can't, work for the local time zone in Great Britain which
uses the same offset as UTC, but does use DST, unlike the latter.
Add a unit test (albeit disabled by default) checking that the code that
previously didn't work correctly in BST does work now (run the tests
using "TZ=Europe/London ./test wxDateTime-BST-bugs" under Unix to test).
Closes#14317, #17220.
See #10445.
