To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=116455
------- Additional comments from [email protected] Fri Jan 21 13:57:47 +0000 2011 ------- arielch->cd: ups maybe I was too cryptic about the explanation. I debugged this down to the root of the problem, the implementation of the com.sun.star.ui.WindowStateConfiguration service: http://hg.services.openoffice.org/DEV300/file/DEV300_m97/framework/inc/uiconfiguration/windowstateconfiguration.hxx http://hg.services.openoffice.org/DEV300/file/DEV300_m97/framework/source/uiconfiguration/windowstateconfiguration.cxx As you notice, there is no problem with the configuration API. The problem is a) the ConfigurationAccess_WindowState caches the information b) and how it caches that information when the toolbar is created and there is no WindowState config. available: it only caches the properties that have been set (this information is stored in a binary field). See ConfigurationAccess_WindowState::insertByName * in http://hg.services.openoffice.org/DEV300/file/DEV300_m97/framework/source/uiconfiguration/windowstateconfiguration.cxx#l471 the WindowState is stored in the cache from the properties set in the ToolbarlayoutManager 471 WindowStateInfo aWinStateInfo; 472 impl_fillStructFromSequence( aWinStateInfo, aPropSet ); 473 m_aResourceURLToInfoCache.insert( ResourceURLToInfoCache::value_type( rResourceURL, aWinStateInfo )); * notice that impl_fillStructFromSequence stores bitwise which properties are set * then the WindowState is inserted in the OOo regsitry 475 // insert must be write-through => insert element into configuration 476 Reference< XNameContainer > xNameContainer( m_xConfigAccess, UNO_QUERY ); 477 if ( xNameContainer.is() ) 478 { 479 Reference< XSingleServiceFactory > xFactory( m_xConfigAccess, UNO_QUERY ); 480 aLock.unlock(); 481 482 try 483 { 484 Reference< XPropertySet > xPropSet( xFactory->createInstance(), UNO_QUERY ); 485 if ( xPropSet.is() ) 486 { 487 Any a; 488 impl_putPropertiesFromStruct( aWinStateInfo, xPropSet ); 489 a <<= xPropSet; 490 xNameContainer->insertByName( rResourceURL, a ); 491 Reference< XChangesBatch > xFlush( xFactory, UNO_QUERY ); 492 if ( xFlush.is() ) 493 xFlush->commitChanges(); 494 } 495 } 496 catch ( Exception& ) 497 { 498 } 499 } * impl_putPropertiesFromStruct only sets the properties marked in the mask field. Of course the configuration API takes care of default values. But the issue here is that ConfigurationAccess_WindowState does not read them back from the configuration, but retrieves the WindowState from the cache. And when the toolbar is created it has no WindowState in the OOo regsitry, so only the properties set by the ToolbarlayoutManager are cached: see ConfigurationAccess_WindowState::getByName 333 ResourceURLToInfoCache::const_iterator pIter = m_aResourceURLToInfoCache.find( rResourceURL ); 334 if ( pIter != m_aResourceURLToInfoCache.end() ) 335 return impl_getSequenceFromStruct( pIter->second ); 336 else 337 { 338 Any a( impl_getWindowStateFromResourceURL( rResourceURL ) ); 339 if ( a == Any() ) 340 throw NoSuchElementException(); 341 else 342 return a; The WindowState of the newly created toolbar is on the cache with only the properties set by the ToolbarlayoutManager. impl_getSequenceFromStruct only sets those, but no default value at all. I first thought of the solution of modifying ConfigurationAccess_WindowState::insertByName and ConfigurationAccess_WindowState::replaceByName to cache the WindowState retrieved back from the configuration. But if we go this way, then the whole way ConfigurationAccess_WindowState stores which properties are set in the mask field is completely pointless, and all the code should be simplified to write and read from the OOo regsitry, caching the whole set of properties. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
