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.
Apparently a locale can be available at MSW level, so that
wxLocale::IsAvailable() returns true, but not supported by the MSVC CRT,
so that constructing the corresponding wxXLocale fails, which resulted
in wxXLocale unit test failures.
Fix them by checking that wxXLocale can be constructed directly instead
of using wxLocale::IsAvailable() as a proxy.
This is not ideal and perhaps wxLocale::IsAvailable() should check that
the locale is supported in wxXLocale too, but should at least allow unit
tests to pass on AppVeyor for now.
Simplify the test by using a single function instead of all the
machinery inherited from CppUnit.
Also provide more information in case of test failure.
Standard/Unix format strings are intentionally used when using these
compilers/environments (see d62c535d4c for
the former), so don't check for Windows/MSVC format strings in the test.
Allow wxPrintf("%1$s %1$s", "foo") to work.
Take into account the possibility that the number of format specifiers
and the number of actual arguments can be different.
Closes#9367.
Don't mix "size_t" and "unsigned" and don't use "%lu" for printing
"size_t" values as this doesn't work under Win64 where sizeof(size_t) is
8 while sizeof(unsigned long) is still just 4.
Rewrite an assert using "||" as 2 asserts to allow it compile with Catch
(this wasn't detected before as this code is only compiled when using
our own vsnprintf() implementation, which is usually not the case).
This doesn't work correctly in Catch after reverting the commit that
broke compilation with MSVC 9, so we have to live with explicitly using
the values of the correct type.
ftp.wxwidgets.org seems to have gone, breaking the existing test (thanks
chris for all the fish...), so don't hardcode this URL in the test and,
without it, don't run the test by default any more and require
specifying a working FTP host (as well as an existing directory and a
file on it) when running it manually.
Rewrite the test using normal functions instead of Java-like structure
imposed by CppUnit to make it simple to skip it.
There is no shrink_to_fit() in wxVector in this case.
Arguably, we shouldn't be building wxVector unit tests in STL build at
all as there is no point in testing the standard class, but OTOH it
could be useful for checking that the tests themselves are correct, so
keep them for now.
Output the maximal difference between the differing images pixels to
show just how far are they from each other, exactly. And show the image
file name as well, for convenience.
Also run all checks instead of stopping after the first failing one.
Also use this for wxArray::Shrink() implementation as it's more
efficient than the old swap-based implementation which requires an extra
memory allocation instead of really shrinking the existing one.
