Old behavior:
1) Add a property of type "Date". DateField inside Value column uses
the full width.
2) Increase the width of the dialog. Now the size of DateField in
the Value column only uses the half width.
Solution:
Set a flag if the current type is of Date. So we can correct the size
after a dialog resize action.
Change-Id: I915a553b2f69aac1aea0ac5b24536db5709abfae
No need to store the position of DateField and TimeField, because this
will not change if we choose another type. The only thing what changes
is the size of the DateField, because both "DateTime" and "Date" use
this field. And for this size we just rely on the size of m_aTimeField,
because it's the same as m_aDateField (for type DateTime).
Change-Id: Ic590c62d82d8f90576479e10be9d422326032d28
Instead of a mix of sal_uIntPtr, sal_uLong, int, and so on.
Also change CONTAINER_ENTRY_NOTFOUND=ULONG_MAX to SAL_MAX_SIZE as
return value in case of failure and in the related tests.
Change-Id: Ie778a849253b4be84fbcdab9557b7c4240233927
SvMemoryStream remainingSize returned the size from current
position to internal buffer size instead to end of data. This
was not consistent with what remainingSize description says on
SvStream (and other SvStream implementations work) and what the
user expects.
Change-Id: I7ff391754a386c5f067a4bd4eed2ee7f2d7fd77e
We call the Win32 GetObject() in just one source file and there it is
the A version we mean. (As such, as we call it to get BITMAP objects,
which do not have different A and W variants, we could as well call
GetObjectW().)
Note that we have several own member functions called GetObject(), so
until those are renamed we still need to #undef the GetObject
definition (from <windows.h>).
(No, I am not working on the EasyHack fdo#82580 as a whole. It is
intended for some less mature LO contributor. I just did a few small
things because I couldn't resist.)
Change-Id: Idab79503b3d899ef19f0608677752a62b20302ff
ODF specifies that extension elements in a document are removed before
the validation. With our old implementation of the number format export
this could result in two number:text elements following each other.
According to the spec a number:text element may not follow another
number:text element.
The number:text element before loext:fill is actually not that
interesting so it makes more sense to make this one an extension
element.
Possible documents showing issues:
fdo45268-1.xlsx
fdo49150-1.xlsx
and many more
Change-Id: I3ad92b8a61a246b3dbc0132d9a2c367488a766d0
