On 15.06.2010 11:47, Björn Michaelsen wrote:
Well, the implementation in new_itemsets only checks for the which id
being 0 and never checks for the type being an SfxVoidItem (outside
assertions). So an disabled item is consistently defined as any item
returning an which id of 0 in the new itemset implementation.
That's an improvement and it allows to use the "API" consistently. OTOH
it is still ugly. :-) I consider the way how the ItemSet codes the
"disabled" status an implementation detail.
Now the interesting part is finding the clients of the itemset that
rely on void items being interpreted as "disabled" by the itemset and
fixing those ....
Question is if that is more effort then replacing all code that puts
items with ID = 0 with code calling "DisableItem" instead. That would
make putting an item with ID=0 an invalid action.
BTW: I don't remember if any of the two ItemSet implementations returns
an VoidItem in a GetItem call for a disabled item or if NULL is returned
then. IMHO it always should be the latter.
Back to your primary topic. If we identify the places where a VoidItem
with ID != 0 is put, and if the developers state that this is by intent,
we can remove that assertion and make putting VoidItems with ID != 0 a
valid action that does not disable that item.
The question why ItemSet::Put must allow that nWhich differs from the
item's which is still open. I assume that it's related to different
pools having different WhichIds for the same item. But knowing it for
sure would perhaps allow us to define a less fuzzy interface.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
