Community
Participate
Working Groups
This is a problem with the Hyerlink in the Progress view. I'm running 3.1M6. When using Job.setProgressGroup(IProgressMonitor, int) to put several jobs in the single group, Hyperlink was generated for every single job with Hyperlink (JobItem parent, JobTreeElement info). But when I double click one of the links to run the gotoAction associated, it runs jobitem.kill(true, true) to kill the jobitem which was associated with all the Hyperlink in the same group. It should only clean up the link that was run and keep the other links unchanged. The code is org.eclipse.ui.internal.progress.NewProgressViewer.handleActivate()
This is the method in 3.1 M6 and 3.1.1 protected boolean handleActivate() { if (isLinkEnabled() && gotoAction != null && gotoAction.isEnabled()) { jobitem.locked = true; gotoAction.run(); if (jobitem.jobTerminated) jobitem.kill(); return true; } return false; } This clears out the action if it is terminated so it is not left lying around. Is this still an issue for you in the 3.1.1 version? I have tested this by doing the following 1) load the org.eclipse.ui.examples.job plug-in 2) self host 3) Open the Job Factory View 4) Make the quantity of jobs 3 5) Select Run in Group 6) Create Jobs Nothing is cleared out when you select an entry with it. The issue is that all of the entries are cleared out when one is selected if it is terminated. The workaround is to not group these jobs.
Not an enhancement
Note that this is not an issue in 3.2 as we do not keep the groups of the completed jobs.
The problem is still there. In my case, each job in the group generates a hyperlink. So when all the jobs in the group finish, there are several hyperlinks in the progress view under the group. The problem is clicking on one of the hyperlink removes all hyperlinks. I didn't see any hyperlink generated when following your test case.
Sorry - you need to select Go To Action as well. In comment 1 I mentioned the same behaviour you were seeing. This is not a bug in 3.2 BTW as there was a significant rework in M1.
When you check the check box Keep, three hyperlinks OK will be created. Click on one of them and all of them are gone. That's the problem I'm talking about. It should remove only the one that is clicked, right? And we also need the option that when the link is clicked, the user can choose not to remove the link so that he can click it again. we are still on 3.1.1 and don't have a plan to move to 3.2 yet.
Right - I agree that is the problem. The concern I have is that the grouping code in 3.1 was quite fragile - that why I reworked it in 3.2. I am reluctant to make changes in the 3.1.2 cycle as I afraid of breaking something else. How important is it that you run these actions in a group? The issue is with groups only so a workaround is to either not group or not use a goto action.
Our product supports a build action on both file and project level. A hyperlink is generated in the progress view which leads the user to the build message. In the project build, several files are built and the order of the file build is important. The file build in the project build also picks up the same settings from the project level. That's why the project build is created as a group and the file build is a member of the group. Without group, the user can't tell the difference between project build and individual file build. Without the goto action, it's not easy for the user to check the build message.
It is pretty unusual to use the progress view to give build messages. Why do you not use the console like the other builders? Are where does it take you too? I want to be sure that you have a workaround in place before I close this as this is not an issue in 3.2.
We do use console to show the build messages. But when serveral build actions run at the same time, it's hard to tell from the console who is who. We use the link in the progress view to start the filter function and display the messages associated with a specific job. I don't think this is quite reasonable use of the link. If not, what's the usual purpose of this link?
Created attachment 29865 [details] Patch This patch will not delete the group. The better solution would be to remove the hyperlink when it is selected but the code changes required to do that at this stage are too wide reaching and I would be afraid of the implications of the changes. Samuel could you please check that this prevents your problem and if so I can release it to the 3.1.2 stream.
Hi Tod, The change sounds good. We don't mind removing the links manually. Thanks.
Fixed in 3.1.2 build >20051114. Note that this does not require backporting to 3.2 as this code is now obsolete.
Verified in maintenance build 20050109
NOTE: to steps in comment #2 add the following after step 5) 5b) select "Keep" 5c) select "Goto Action"
verified on Linux Motif for Version: 3.1.2 Build id: M20060109-1200
