INVALID_POOL_ITEM in sfx2::sidebar::ControllerItem::ItmeUpdateReceiverInterface::NotifyItemUpdate

Caolán McNamara caolanm at
Fri Apr 14 11:47:20 UTC 2017

On Thu, 2017-04-13 at 18:17 +0200, Stephan Bergmann wrote:
> (svx/source/sidebar/area/AreaPropertyPanelBase.cxx) is called with 
> pState being INVALID_POOL_ITEM (i.e., -1).
> Up the call stack, SfxStateCache::SetState_Impl 
> (sfx2/source/control/statcach.cxx) is clearly documented to expect
> that pState can be INVALID_POOL_ITEM ("Slot Status, 0 or -1"), and
> seems to handle it correctly.  And ControllerItem::StateChanged 
> (sfx2/source/sidebar/ControllerItem.cxx) just passes pState through
> to NotifyItemUpdate without otherwise looking at it.
> So it looks like overrides of 
> sfx2::sidebar::ControllerItem::ItmeUpdateReceiverInterface::NotifyIte
> mUpdate (include/sfx2/sidebar/ControllerItem.hxx) would need to take 
> IsInvalidItem(pState) into account.  But upon at least a very 
> superficial audit, they seem to not do that.

sfx2/source/control/bindings.cxx:1271:20 is 
 rCache.SetState( SfxItemState::DONTCARE, INVALID_POOL_ITEM );
and the common pattern seems to be to only look at the payload of
states >= ::DEFAULT. In this consumer that's equivalent to having
bDefaultOrSet set and indeed in that handler we only dereference the
casted pState if that's set, so if we defer the cast to that point too
I presume the problem goes away. I've pushed that as
9a27902bbcfc7455d068167d8abc9645e2687ba1 so we'll find out if that

More information about the LibreOffice mailing list