Community
Participate
Working Groups
This is kind of like bug 219136 which I opened before, but is a little more general. Often when an async error is reported (such as at the end of a job) there may be some alternate task/suggestions to make to the user to fix the problem. An example from the p2 world is an error like "Error reading update site." We might wish to offer the user to: - edit the location (in case it was just a typo) - remove the site from their site list - try again etc... It would be nice for the status handling framework to somehow support this, so that the error could be reported and the suggestions made in the same place. Right now we end up special casing the error and offering some suggestions in a message prompter, and sometimes the error details are not reported because we do it this way. Bug 219136 was closed because I suggested an option that said "continue anyway" and that didn't make sense with non-blocking status handling. I'm wondering if this more general suggestion is worth considering. In the case of StatusManager.SHOW (or BLOCK), when an error dialog is shown, what if there was a common area of the dialog that listed possible fixes/actions the user could do. The error dialog wouldn't have to know what they do, just provide the common real estate and a way for the user to select/perform one of the suggestions. I don't know what would be best...links, vs. a quick fix list, etc. I'm not sure quick fix is the right analogy, sometimes it would be a link back to the originating UI component so the user could correct something. I think this is only worth doing in the framework if we made an effort across the platform to support this style of interaction. In an async error reporting world, I think this becomes more important because errors can happen long after the user did the thing that caused it, and leading the user back to a correction will help a lot. In p2, the time between the action and the error being discovered can be a long time, and the wizard/dialog that the user was in when the error occurred is long gone, so it's helpful to take the user back to the right place.
I agree this would be valuable to support, but that we'd need a concerted effort to make use of it throughout the SDK. I'm not sure if product teams have something similar. If they do then we'd need to ensure some kind of co-existance or common framework. If they don't, we'd need to understand requirements.
I will give the 2 cents from our products and let the other products based on eclipse elaborate. For us, the 'user actions' of an error live in the infocenter. The way we want to work is to provide a link between an error report and the associated task. We basically ask the developer to provide a status code which we will link to the associated task. Then we rely on 'payload' for the status to provide the extra info. We worked with the CVEException as an example and it provides some payload like the cvs server. What we want to so then is override or extend the 'properties' dialog of the ErrorLog view to provide some help like test the server and such. This is when the dialog is closed and the status is persisted in the errorLog Then, if we use the StatusManager.SHOW, we have our own extension of the Dialog that provides help. We do not have a situation where we would delegate the help to the component that sent the Status. So for instance, maybe CVS can provide a 'StatusDialog helper' in case of server situation and this could test the connection to the server. We would then need to understand who has the right to provide help to the user and how we link the different help controls :) So, in our product we use - link the error concept to the infocenter concepts so we keep the knowledge in one place - rely on payload of the Exception/IStatus to allow better explanation - do not have 'cheat sheet' in an error dialog or error property (in the error log or problem view) - like the idea of such cheat sheet but we have not tried to use what is already existing (replacing the property dialog, creating a cheat sheet) , so I cannot say that what is already existing is not enough Thoughts ?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
