Else (on 64bits platform) the driver smashes our stack: SQL_ULEN is 64 bits
Widen result type of getQueryTimeOut, getMaxFieldSize and getMaxRows so that it will always fit
When entering pass count 2 it is expected that the breakpoint is
passed two times before breaking not to break the second time.
Also fixed a crash due to dangling pointers of breakpoints.
It is puzzling that Executable_soffice.bin.mk contains the line
$(eval $(call gb_Executable_set_targettype_gui,$(sofficebin),YES))
yet, in the build log we see -SUBSYSTEM:CONSOLE among the linker flags.
I added -SUBSYSTEM:WINDOWS flag exlicitely, and it comes later so it
prevails. I guess MinGW will be still affected. It really should be
fixed correctly by a gbuild expert.
I added that as a convenience method while working on implementing
multi-value filtering. But we need to stick with the plural version
GetQueryItems() from now on for clarity.
+ IsValidDate() checks only day and month regarding the year, not Gregorian
cut-off date as now does IsValidAndGregorian().
+ Normalize() carries over invalid day and month values to next months and
years.
* All methods that return or internally use a day count now internally
normalize the date values, without modifying the actual Date instance. So,
if the date is not valid you may get unexpected results.
* Previously, a date with month>12 would had accessed the days-of-month
array out of bounds on all such methods. So you would had gotten
unexpected results anyway..
* Affected methods are:
GetDayOfYear()
GetWeekOfYear()
GetDaysInMonth()
static DateToDays()
* Read dates with years consisting of less than 4 digits.
ISO 8601 specifies that years are to be written with a minimum of 4 digits.
However, be lenient in what we accept.
* Write years < 1000 with leading zeros to comply with ISO 8601 YYYY.
+ IsValidDate() checks only day and month regarding the year, not Gregorian
cut-off date as now does IsValidAndGregorian().
+ Normalize() carries over invalid day and month values to next months and
years.
* All methods that return or internally use a day count now internally
normalize the date values, without modifying the actual Date instance. So,
if the date is not valid you may get unexpected results.
* Previously, a date with month>12 would had accessed the days-of-month
array out of bounds on all such methods. So you would had gotten
unexpected results anyway..
* Affected methods are:
GetDayOfYear()
GetWeekOfYear()
GetDaysInMonth()
static DateToDays()
- introduce first two basic tests (to be improved)
- rewrite of UpdateInformationProvider::load() to use comphelper
- smaller splitting of functions to be able to unit test
i.e.
mnOutWidth = maPaperSize.Width() - 2*maPageOffset.X();
mnOutWidth = maPaperSize.Width() - 2*maPageOffset.Y();
might possibly be intended to be
mnOutWidth = maPaperSize.Width() - 2*maPageOffset.X();
mnOutHeight = maPaperSize.Height() - 2*maPageOffset.Y();
either way, its behind a special getenv, so ditch the lot
