Hi Bjoern, Björn Michaelsen wrote, On 06/14/10 13:34: > Hi all, > > while testing the new SfxItemSets in cws new_itemsets I came across a > few interesting uses of itemsets which I had considered to be illegal > (but I might be wrong there). I assumed: > - non-void items should only be put at the same which id in a set as the > which id on the item itself. > - void items should always have a which id of 0 and are allowed to be > put anywhere.
Who says they would need to have which ID 0 ? > > Here are a few examples where these assumptions fail: > > Opening an empty writer document for examples fires the assertion at: > http://hg.services.openoffice.org/cws/new_itemsets/file/5d3400d7452f/svl/inc/svl/itemset.hxx#l74 > > The backtrace shows the first call triggering this is coming in from > SwDoc::GetTxtCollFromPool(..), followed by calls from > SwFmt::SetFmtAttr(..). Is there any reason why a non-void, non-invalid > item is put at a different which id in the set than the which id of the > item itself? Sound like the road to perdition to me ... > > When typing in a number in a cell in calc the assertion at: > http://hg.services.openoffice.org/cws/new_itemsets/file/5d3400d7452f/svl/source/items/itemset.cxx#l98 > > The backtrace shows the call triggering this is coming in from > EditView::GetAttribs(..). Is there any reason why a void item should > have a which id > 0 set? And if yes, what is the reason for using such > semantics? E.g. how are a void item with which id 0 and a void item > with which id > 0 differing in behaviour? The EditEngine is using VoidItems for some attributes which are only markers. SW at least did the same, don't know if it still does. And because I mainly use which IDs when working with attributes, and not RTTI, they have non zero which IDs... Malte. > > Best Regards, > > Bjoern > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
