Hello,
In svx/sdi/svxitems.sdi, I noticed that MID_FIRST_LINE_REL_INDENT was
defined as INT32 (see
http://opengrok.libreoffice.org/xref/core/svx/sdi/svxitems.sdi#437)
whereas
http://opengrok.libreoffice.org/search?q=MID_FIRST_LINE_REL_INDENT&project=core&defs=&refs=&path=&hist=
shows 2 uses in editeng/source/items/frmitems.cxx:
468 case MID_FIRST_LINE_REL_INDENT:
469 rVal <<= (sal_Int16)(nPropFirstLineOfst);
470 break;
526 case MID_FIRST_LINE_REL_INDENT:
527 SetPropTextFirstLineOfst ( (sal_uInt16)nVal );
528 break;
Should it be defined INT16 or should the cast be removed?
if it's correct and/or if we shouldn't change since there's no bug related
indeed, a quick explanation would be appreciated :-)
Remark: I noticed this because I wanted to understand the reason of this:
warn:legacy.osl:9040:1:editeng/source/items/frmitems.cxx:478: unknown
MemberId
I noticed these kinds of things too (sfx2/source/control/unoctitm.cxx)
895 sal_uInt16 nSubId( 0 );
896 if ( eMapUnit == SFX_MAPUNIT_TWIP )
897 nSubId |= CONVERT_TWIPS;
898 pItem->QueryValue( aEvent.Result, (sal_uInt8)nSubId
);
See
http://opengrok.libreoffice.org/xref/core/sfx2/source/control/unoctitm.cxx#895
why nSubId isn't declared sal_uInt8 instead, so we avoid the cast (knowing
that CONVERT_TWIPS=0x80) (like this since a conversion from USHORT and BYTE
to sal_uInt16 and sal_uInt8)
but of course, it's probably a different story.
Julien
--
View this message in context:
http://nabble.documentfoundation.org/About-MID-FIRST-LINE-REL-INDENT-svxitems-sdi-tp4168346.html
Sent from the Dev mailing list archive at Nabble.com.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
