Book Image

Eclipse 4 Plug-in Development by Example : Beginner's Guide

By : Dr Alex Blewitt
Book Image

Eclipse 4 Plug-in Development by Example : Beginner's Guide

By: Dr Alex Blewitt

Overview of this book

<p>As a highly extensible platform, Eclipse is used by everyone from independent software developers to NASA. Key to this is Eclipse’s plug-in ecosystem, which allows applications to be developed in a modular architecture and extended through its use of plug-ins and features.<br /><br />"Eclipse 4 Plug-in Development by Example Beginner's Guide" takes the reader through the full journey of plug-in development, starting with an introduction to Eclipse plug-ins, continued through packaging and culminating in automated testing and deployment. The example code provides simple snippets which can be developed and extended to get you going quickly.</p> <p>This book covers basics of plug-in development, creating user interfaces with both SWT and JFace, and interacting with the user and execution of long-running tasks in the background.</p> <p>Example-based tasks such as creating and working with preferences and advanced tasks such as well as working with Eclipse’s files and resources. A specific chapter on the differences between Eclipse 3.x and Eclipse 4.x presents a detailed view of the changes needed by applications and plug-ins upgrading to the new model. Finally, the book concludes on how to package plug-ins into update sites, and build and test them automatically.</p>
Table of Contents (19 chapters)
Eclipse 4 Plug-in Development by Example Beginner's Guide
Credits
About the Author
Acknowledgement
About the Reviewers
www.PacktPub.com
Preface
Index

Time for action – setting a conditional breakpoint


Normally, breakpoints fire on each invocation. It is possible to configure breakpoints such that they fire when certain conditions are met.

  1. Go to the execute() method of the SampleHandler class.

  2. Clear any existing breakpoints by double-clicking them or using Delete all breakpoints from the Breakpoints view.

  3. Add a breakpoint to the first line of the execute() method body.

  4. Right-click on the breakpoint and select the Breakpoint Properties menu. (It can also be shown by Ctrl + double-clicking, or Cmd + double-clicking on OS X on the breakpoint icon itself.)

  5. Set the Hit Count field to 3, and click on OK.

  6. Click on the Hello World icon button three times. On the third click, the debugger will open up at that line of code.

  7. Open the breakpoint properties, deselect Hit Count and select the Enabled and Conditional options. Put the following code into the conditional trigger field:

    ((org.eclipse.swt.widgets.Event)event.trigger).stateMask == 65536
  8. Click on the Hello World icon and the breakpoint will not fire.

  9. Hold down Alt, click on the Hello World icon, and the debugger will open. (65536 is the value of SWT.MOD3, which is the Alt key.)

What just happened?

When a breakpoint is created, it is enabled by default. A breakpoint can be temporarily disabled, which has the effect of removing it from the flow of execution. Disabled breakpoints can be trivially re-enabled on a per-breakpoint basis, or from the Breakpoints view. Quite often it's useful to have a set of breakpoints defined in the codebase, but not necessarily have them all enabled at once.

It is also possible to temporarily disable all breakpoints using the Skip All Breakpoints setting, which can be changed from the corresponding item in the Run menu (when the debug perspective is enabled), or the corresponding icon in the Breakpoints view. When this is toggled, no breakpoints will be fired.

Conditional breakpoints must use a Boolean expression, rather than a statement or a set of statements. Sometimes this is constraining; if that's the case, having a utility class with a static method allows more complex code paths (with the caveat that all interesting data must be passed in as method arguments).