To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=116187
User lmamane changed the following:
What |Old value |New value
================================================================================
Status|CLOSED |UNCONFIRMED
--------------------------------------------------------------------------------
Platform|All |Opteron/x86_64
--------------------------------------------------------------------------------
Resolution|WORKSFORME |
--------------------------------------------------------------------------------
------- Additional comments from lmam...@openoffice.org Sat Jan 15 04:32:00
+0000 2011 -------
r4zoli, I bet you tried on a 32-bit architecture machine. Because I nailed down
this bug, and it only happens on 64-bit architectures (and not Microsoft
Windows).
The problem is in this line in ReportController.cxx:
xProp->setPropertyValue(PROPERTY_LEFTMARGIN,uno::makeAny((sal_Int32)static_cast<const
SvxLRSpaceItem*>(pItem)->GetLeft()));
SvxLRSpaceItem*->GetLeft() returns a C/C++ long (from lrspitem.hxx):
long nLeftMargin; // nLeft oder der neg. Erstzeileneinzug
(...)
inline long GetLeft() const { return nLeftMargin; }
On a 32-bit machine, this is a 32-bit value, so a "long" in uno terms, and all
goes well.
But on a 64-bit machine, with a debug build, you get on stderr:
Error: caught an exception!
in function:void rptui::OReportController::openPageDialog(const
com::sun::star::uno::Reference<com::sun::star::report::XSection>&)
type: com.sun.star.lang.IllegalArgumentException
message: The given value cannot be converted to the required property type.
(property name "LeftMargin", found value type "hyper", required property type
"long")
That's because a C/C++ long is 64 bits, thus a "hyper" in uno terms...
setPropertyValue refuses to "downgrade" the hyper (64 bits) to a long (32 bits),
even when the actual value being presented would fit. Thus exception is raised,
the whole try block is broken, and everything that is below that line (like
saving the user-set top/bottom margin values) is not done.
The same for Right margin. You won't get this bug in Microsoft Windows, because
there, even in a 64-bit environment, a "long" is still 32 bits.
By contrast, in the lines just below:
xProp->setPropertyValue(PROPERTY_TOPMARGIN,uno::makeAny(static_cast<const
SvxULSpaceItem*>(pItem)->GetUpper()));
xProp->setPropertyValue(PROPERTY_BOTTOMMARGIN,uno::makeAny(static_cast<const
SvxULSpaceItem*>(pItem)->GetLower()));
GetUpper and GetLower are C/C++ USHORT, and hence fit in a uno long without
problem. As they are expressed in hundreths of millimeters, this also tells us
they wrap around at 65.535 cm (well, as the UI rounds at tenths of millimeters,
let's say 65.53cm)... In other words, one can't set margins bigger than that.
(One can set paper size up to 3m*3m.)
The attached patch closes the hole to fix the user-visible bug in an immediate
way, but possibly the best way to fix this is to change SvxLRSpaceItem to not
use C/C++ "long", but a type of fixed length, or fix setPropertyValue to accept
values that come in a type that is too big, but fit in the type that it wants,
or possibly something else altogether.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org
For additional commands, e-mail: issues-h...@dba.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
