Home > Articles > Programming > Java

📄 Contents

  1. FAQ 319: What is eScript?
  2. FAQ 320: Language integration phase 1: How do I compile and build programs?
  3. FAQ 321: How do I load source files edited outside Eclipse?
  4. FAQ 322: How do I run an external builder on my source files?
  5. FAQ 323: How do I implement a compiler that runs inside Eclipse?
  6. FAQ 324: How do I react to changes in source files?
  7. FAQ 325: How do I implement an Eclipse builder?
  8. FAQ 326: Where are project build specifications stored?
  9. FAQ 327: How do I add a builder to a given project?
  10. FAQ 328: How do I implement an incremental project builder?
  11. FAQ 329: How do I handle setup problems for a given builder?
  12. FAQ 330: How do I make my compiler incremental?
  13. FAQ 331: Language integration phase 2: How do I implement a DOM?
  14. FAQ 332: How do I implement a DOM for my language?
  15. FAQ 333: How can I ensure that my model is scalable?
  16. FAQ 334: Language integration phase 3: How do I edit programs?
  17. FAQ 335: How do I write an editor for my own language?
  18. FAQ 336: How do I add Content Assist to my language editor?
  19. FAQ 337: How do I add hover support to my text editor?
  20. FAQ 338: How do I create problem markers for my compiler?
  21. FAQ 339: How do I implement Quick Fixes for my own language?
  22. FAQ 340: How do I support refactoring for my own language?
  23. FAQ 341: How do I create an Outline view for my own language editor?
  24. FAQ 342: Language integration phase 4: What are the finishing touches?
  25. FAQ 343: What wizards do I define for my own language?
  26. FAQ 344: When does my language need its own nature?
  27. FAQ 345: When does my language need its own perspective?
  28. FAQ 346: How do I add documentation and help for my own language?
  29. FAQ 347: How do I support source-level debugging for my own language?
  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

FAQ 339: How do I implement Quick Fixes for my own language?

The JDT has support for so-called Quick Fixes. Whenever a marker is generated, a set of resolutions is associated with it for users to click on and choose an automatic fix of the problem as shown in Figure 19.5. Quick Fixes are implemented through the org.eclipse.ui.ide.markerResolution extension point:

<extension point="org.eclipse.ui.ide.markerResolution">
   <markerResolutionGenerator
      markerType="org.eclipse.core.resources.problemmarker"
      class="org.eclipse.escript.quickfix.QuickFixer"/>
</extension>

19fig05.jpgFigure 19.5 Quick Fixes in the Eclipse Java editor

The implementation class implements the IMarkerResolutionGenerator interface. Use the IMarkerResolutionGenerator2 when resolutions are expensive to implement. See the javadoc for the interface for an explanation. Here is what the implementation class may look like:

class QuickFixer implements IMarkerResolutionGenerator {
   public IMarkerResolution[] getResolutions(IMarker mk) {
      try {
         Object problem = mk.getAttribute("WhatsUp");
         return new IMarkerResolution[] {
            new QuickFix("Fix #1 for "+problem),
            new QuickFix("Fix #2 for "+problem),
         };
      }
      catch (CoreException e) {
         return new IMarkerResolution[0];
      }
   }
}

An array of Quick Fixes has to be returned for the problem associated with the current marker.

Each marker resolution, or Quick Fix, implements IMarkerResolution or, when a description and an image are available, IMarkerResolution2. Here is what the implementation may look like:

public class QuickFix implements IMarkerResolution {
   String label;
   QuickFix(String label) {
      this.label = label;
   }
   public String getLabel() {
      return label;
   }
   public void run(IMarker marker) {
      MessageDialog.openInformation(null, "QuickFix Demo",
         "This quick-fix is not yet implemented");
   }
}

The problem indicator—in our sample, the WhatsUp attribute—is associated with the marker by the parser. Typically, the Quick Fix handler that resolves the problem, as shown in this example, lives somewhere in the UI. Following this paradigm is advisable as it separates the problem detection in the compiler/parser from how it is presented to the user.

Quick Fixes can be inspected and executed by using the context menu on a given problem in the Problems view. Note how the JDT uses a context menu and the double-click action on a marker to active Quick Fix.

Note

FAQ 340 How do I support refactoring for my own language?

  • + Share This
  • 🔖 Save To Your Account