Community
Participate
Working Groups
When selecting several Tasks, and then pressing the right mouse button, the quick fix option is unavailable. I'd suggest that if selecting Tasks that suffer from the same problem (ex: Local addition not under CVS control), the quick fix option should be available and the solution choosed applyed to all.
Agreed, and here's a related issue. Creating a new project in CVS, I have 40+ entries for "add to local CVS". After doing so (not using Quick Fix), the Quick Fix entries still are there. I propose (a) that the Quick Fix in this particular case should go away automatically, (b) there should be a means to delete "informational" Task list messages -- not just filter them, and (c) as this bug suggests, Quick Fix from the Task list should all multi-select, even if it prompts for each (not ideal, but better than it is today).
*** Bug 44707 has been marked as a duplicate of this bug. ***
*** Bug 45333 has been marked as a duplicate of this bug. ***
I'd like to take this a step further and not limit this to "Quick Fix". Seems like the "Go To" and possibly "Properties" functions should also work when multiple items are selected.
*** Bug 47732 has been marked as a duplicate of this bug. ***
*** Bug 50132 has been marked as a duplicate of this bug. ***
People so far in the discussion seem to prefer the "Select several problems, and if they are all the same type, still allow quick-fixes from the right click menu." I've also seen another way to do multiple in another UI, where if you select one and choose quick-fix, and if there are other items of the same type, there is an additional default unchecked checkbox in the popup of "Apply fix to all other items of same type?" I think the multiple select method is better because it allows you a finer grain control to only fix a few items of a type at once, but I think more people would stumble across the checkbox method. Personally, I'd prefer both.
*** Bug 58690 has been marked as a duplicate of this bug. ***
I would be happy to have this ASAP. Fixing 20000 "Unqualified access to member" problems in a legacy project is NOT fun right now.
*** Bug 74942 has been marked as a duplicate of this bug. ***
This bug is still present in 3.1 I20041013!!! (I think that this "bug" should get raised to a higher priority, since I'm also stuck with the "Unqualified access..." mess!)
Ok would be if user clicks and there is option in menu 'quick fix all items of this type', also possible grouping of similar items in tree. Fixing different type problems at once is too tricky and some problems can't be quick fixed. And some problems should have grouped quick fix and some shouldn't ... Interesting is that fixing this seems a probalem b/c I'm sure Eclipse has needed code editing and rebuilding infrastructure. Applying transformations in sequence and changing UI little shouldn't take much longer than couple of days for one who knows related code well?
Risking spamming the person in charge, I second tonis latest suggestions. I have been on the list for this bug from the very start (having posted a duplicate) which means I have been waiting for a fix for more than TWO YEARS. Please finally have a go at this, we need it almost every day.
I posted a dup a long time ago too. This would be a great enhancement.
*** Bug 87217 has been marked as a duplicate of this bug. ***
*** Bug 91594 has been marked as a duplicate of this bug. ***
*** Bug 101234 has been marked as a duplicate of this bug. ***
Any word from the powers that be? I have a project with around 1k (yes thousand) quick fixes, 80% of which could use the batch fixing. Is this on anyone's horizon? If not, is anyone on the CC list interested in collaborating on a temporary workaround/hack/plug in to do quick fixes? If so, feel free to contact me directly.
Here's a list of JDT quick fixes that have been mentioned in duplicates and that would profit from batch processing: - Remove unused import - Unqualified access to member - extra semicolons - unnecessary cast or instanceof - create missing constructors - access to static members through non-static contexts - missing serialVersionUID
Why should it be limited? I should be able to multi-select ANY problem marker and quick fix them. It might be necessary to limit multi-select to common markers.
I didn't say that the list from comment 19 should be closed. I just wanted to show that there are a bunch of quick fixes that could be applied in batch (I e.g. also forgot the 5.0 quick fixes to add @Override or @SuppressWarnings). Still, not all quick fixes will be amenable to be applied to multi-selections. E.g. if you have an error like in ... new Integer(1, "2"); ..., then you can't tell which quick fix 'Remove argument to match Integer(..)' should be applied.
Hi, Can we get a status update on this, please? Part of my role is to migrate lots of development teams from JBuilder to Eclipse, and face the dreaded import- project-and-fix-loads-of-serializable-warnings problem almost daily. This would be a big productivity gain for me. Thanks
There has been no changes to the status since the last comments.
Given it's immense popularity I am going to upgrade the priority.
Please, mark 30204 as dublicate of this.
Fixed in build >20050929. It will now handle mutli select and only prompt if there is more than one quick fix for a marker.
I'm currently running 3.2M2. Can you please point me at the instructions for patching it with the relevant M/I build, please?
I only released the change an hour ago - it will be in builds starting tonight. If you want to look at it load ActionResolveMarker from HEAD
Sorry, I wasn't clear. Once an N build is available with the fix in, how do I apply that to my current 3.2M2 installation?
The easiest way is to just take the new build and use it with your existing workbench. If you want you could always copy the ide plug-in over but there are no guarantees that this not break due to other dependencies.
(Tod is my hero) Any thoughts on comment 7?
I think it is a pretty good idea - the only reason I didn't do it was fear that this feature would get pushed to the background by the other work we are doing and not get into 3.2. I didn't want to miss a feature with 21 votes! Please feel free to log another bug for this idea if you would think it is interesting.
Verified in 20051101
Reopening. We are going to need to add API for teams to buy into this as it is making some problems show up for resolution providers.
*** Bug 28635 has been marked as a duplicate of this bug. ***
Thanks for the progress on this. I've been awarded with the nickname "hunter of the missing this" because of this feature missing. I also tried to patch it on my own, but without significant API change, this is quite a tough task. Thanks, Tod.
Daniel if you have some input into the API I will propose in Bug 114754 please let us know there. I will be looking into this in the next week or so.
(In reply to comment #36) Daniel: For java-specific quick fixes, also check out the new 'Source > Clean Up...' action that has been added for 3.2M3.
For performance reasons I will not be enabling multi select from the menu but will have it as an option to add from the dialog. This will allow you to add all similar markers in your problems view so that you can fix multiple instances of the same problem at once. This is easier than using the selection to build the list as the user does not have to hunt and peck for all of the instances of a problem. Currently only my test marker resolutions support this - if JDT changes thier resolution to be WorkbenchMarkerResolutions and allows grouping we will be able to mullti fix thenthen.
verified in 20051213-0100
