About MID_FIRST_LINE_REL_INDENT (svxitems.sdi)

[julien2412]

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.