To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=37020
------- Additional comments from [EMAIL PROTECTED] Mon Feb 14 06:24:42 -0800 2005 ------- Some comments: I think that it is inappropriate to install an InteractionHandler globally into the main thread, which triggers every time, when there is an attempt to instantiate a Java component. [FYI: I work on the configuration component, which also supports an interaction handler for the case when it encounters invalid configuration data. But I assume that popping up a message box for any other error I encounter might be entirely inappropriate for the context this is invoked from. Thus, if such a message - and the full recovery functionality - is desired, the code that handles the user action is responsible for activating the handler (i.e. install it into the context). This is the opposite approach to the Java one] Looking at the error message "%PRODUCTNAME% requires [Java] to perform this task.", there are several mistakes due to incorrect assumptions here: 1. This message should never occur more than once for each user-initiated action. But in fact there are actions (e.g. macro-related actions) that attempt to instantiate several services, all of which may attempt to access Java. But these are not separate 'tasks' from the user's point of view. Accordingly the message assumes that it is clear from the context what functionality is lost due to the lack of Java. But in the macro case that is not at all clear. If the user chooses 'Macros - Run...', that means he wants to run any of the *available* macros, often one he created or recorded himself. In that case it is not at all true, that the desired task can't be performed. Only if a macro he expects requires one of the failing providers he is impacted. OTOH when working more actively with macros (or when trying to find out why one expected macro is not available in the list of macros to run), the user needs the information which macro providers are unavailable (whether this is caused by the lack of Java or not). 2. This message (and this way of handling them) assumes that each service that is being instantiated is necessary to perform the task the user requested. This is not necessarily true. If a certain service is missing its client might fall back on another solution or there might be a degradation in the functionality offered. In some cases the service that can't be instantiated may even be purely optional. The macro functionality is a case of degradation of functionality. As mentioned before that degradation may or may not have impact on the user. (Less for running macros, more for authoring/configuring). Additionally there appears to be the problem that the case where the user chose 'cancel' is not handled properly by the scripting framework. This should be filed as another bug. I agree that a solution that addresses all these problems is not possible in the short run. The best solution that can be done quickly is to intercept the JavaInteractionHandler in places where this kind of problem occurs. For the macro case, the best solution would probably be to install a local, temporary wrapper for the JavaInteractionHandler. That wrapper could forward the first invocation (for a given kind of error) to the original handler and suppress any subsequent ones. As a result the message would pop up at most once for each user action, which solves problem 1. Producing a more informative error message is or isn't handled by the scripting framework anyhow and can't be the task of the Java-specific handler. @jl: Even if this InteractionHandler is not a 'published' (i.e. stable) interface, it is an interface. It really should be possible to use this to address bugs. As long as the unstable status of the interface is clear, that should not be a problem. --------------------------------------------------------------------- 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]
