To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=49631
------- Additional comments from [EMAIL PROTECTED] Mon May 23 06:34:00 -0700 2005 ------- The merge messages don't indicate any real problem. The layer service supports an *optional* property 'URL', which is used to identify the layer being merged in the log and for the error recovery UI when the layer returns invalid data. I added that property rather late and did not add the property for layer implementations I don't own, so the gnome and system backends don't have it. Because of that, the logging code can only report an unknown layer type - but this is in no way an error. One remark for the setting you added: - The OOo configuration does support a 'boolean' data type, which would be strongly preferred over a string containing 'true' or 'false'. I don't know whether the VCLSettings getValue function supports that easily. Some more remarks about the notification handling: - The attempt in the first patch is very wrong architecturally. The configuration services - this includes backends - should function in an UNO environment without a full office and in UNO applications that re not the full OOo. Good thing you pulled that. - It is an unfortunate fact (partly for historical reasons), that (many of) the 'ConfigItem' classes, which wrap the generic configuration API with special accessors for the applications, keep their own copy of the configuration data. These copies are redundant with the data kept in the configuration cache and so may get out of sync. The ConfigItem base class provides a mechanism to enable a listener on the API level for the affected components. But this needs to be invoked explicitly. Only few config items make use of this so far. Combined with the private copy of the data kept by the ConfigItems, backend- (or API-) generated notifications don't work any more. AFAICT one of the reasons for the reluctance to activate API notifications is thread (un)safety in the applications. Configuration notifications usually occur asynchronously in a special thread. Many application components don't handle configuration change events from threads that don't own the global 'solar mutex' properly. Another reason is that there simply wasn't sufficient time to enable such notifications (with proper testing and all). If no listeners are found in broadcaster.cxx, that means that no listener(s) were registered with the configuration API. Up to that point everything is internal propagation of changes and notifications within the API implementation. --------------------------------------------------------------------- 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]
