Community
Participate
Working Groups
When I need to update my project I usually follow: right click over the project in 'Package Explorer' -> Team -> Update. When it turns out that my workspace is unsynchronized then I am presented a pop-up 'Problem Occurred' saying: 'CVS Update' has encountered a problem. There is also an advice: 'Perform a Refresh'. Fair enough, but this is a bit annoying to seek for a refresh while a dedicated button should be available for a user in the pop-up (next to 'Show CVS console' 'OK' 'Details' buttons). Well, for me this would improve a user experience a lot.
Szymon, is there a way to add a custom button to the Problem Occurred dialog? It is part of the error handling facility, isn't it?
(In reply to comment #1) > Szymon, is there a way to add a custom button to the Problem Occurred dialog? > It is part of the error handling facility, isn't it? We're able to add a button with a custom action to the status/error dialog. However AFAIK this would work only in some cases. Krzysztof is the right person to elaborate. We need to know if the "Problem Occurred dialog" is our new status dialog and how the problem is reported to the status handling facility.
There can be only one action associated with a job. In case of CVS job, the place is already used by "Show CVS Console". Currently there is no technical possibility to add more recovery actions, however it would be a nice thing to have.
(In reply to comment #3) > Currently there is no technical possibility to add more recovery actions, > however it would be a nice thing to have. Too bad. Is there a request for such a feature in status handling facility already?
No, there is not. You can open one ;-).
Krzysztof, told me offline that I could simply configure the job with job.setProperty(IProgressConstants.ACTION_PROPERTY, new RefreshAction()). I've taken a closer look at how it works and it appears that only two team operations override getGotoAction() method and use it display CVS Console. These operations are CheckoutOperation and RepositoryProviderOperation. Overriding the same method in UpdateAction and providing a refresh action should do the job.
Created attachment 137183 [details] Patch v01 Patch implementing the idea mentioned above, haven't test it yet. Dominik, would you like to give it a try? :)
Created attachment 137184 [details] mylyn/context/zip
(In reply to comment #7) > Created an attachment (id=137183) [details] > Patch v01 > > Patch implementing the idea mentioned above, haven't test it yet. > > Dominik, would you like to give it a try? :) > Hi Tomasz. I am glad that this little feature did not turn out a mission impossible :) And yes, I would like to see it in action unless you ask me to make a build on my own. If so, I will wait for a (nightly/dev) build. Best regards and thank you!
(In reply to comment #9) > unless you ask me to make a build on my > own. If so, I will wait for a (nightly/dev) build. I must admit this was my intention :) In this case we will have to wait til 3.5 ships.
*** Bug 279714 has been marked as a duplicate of this bug. ***
Created attachment 141506 [details] Patch v02
Created attachment 141507 [details] mylyn/context/zip
Before releasing the patch I would like to find out if "Refresh" is an appropriate "recovery" action for any exception that can be handled this way and thrown during an update. I'm not 100% sure of that so I will need extra time to double check this, which unfortunally I haven't found during 3.6M1. Help wanted...
We haven't got time to verify safety of the fix, removing the target milestone to better much the reality. Still, any help would be appreciated.
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.
