About MID_FIRST_LINE_REL_INDENT (svxitems.sdi)

julien2412 serval2412 at yahoo.fr
Fri Dec 4 16:00:20 PST 2015


In svx/sdi/svxitems.sdi, I noticed that MID_FIRST_LINE_REL_INDENT was
defined as INT32 (see
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
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
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.


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.

More information about the LibreOffice mailing list