2

I've struggled quite a bit with Eclipse and progress-monitors to try to have good progressbars which report useful progress information to the user. Inevitably the code gets cluttered with lots of things like

if (monitor.isCancelled())
    return;

...

lengthyMethodCall(monitor.newChild(10));

and all over the place I need to pass a IProgressMonitor as an argument to my methods. This is bad, for several reasons:

  1. The code gets cluttered with lots of code which is not relevant to what the function actually does.
  2. I need to manually guesstimate which parts of the code takes time, and which parts do not.
  3. It interacts badly with automated tests; where much of the information which goes into a progressbar instead should be logged for later inspection.

Is there a way out of this? Are there tools which can help me out with one or more of these problems? Should I be looking at Aspect-Oriented Programming tools, or are there other alternatives?

Improve this question
2
  • for point 3 can't you create your own IProgressMonitor (which you should be able to as it's an interface) which logs the calls to it and pass that into the method
    – ratchet freak
    Nov 20, 2012 at 15:08
  • Yes, I can. But I still consider it a kludge.
    – JesperE
    Nov 20, 2012 at 15:14

2 Answers 2

Reset to default
1

The code gets cluttered with lots of code which is not relevant to what the function actually does.

Sounds like Java run time exceptions. :-) I guess one way out of the IProgressMonitor mess is to wrap up all of your "batch" processing into Jobs (org.eclipse.core.runtime.jobs).

I need to manually guesstimate which parts of the code takes time, and which parts do not.

Not really. You can wrap any code in a Job. If it executes quickly, you won't even see the progress monitor popup. If it takes time to process, then it should be a Job anyway.

It interacts badly with automated tests; where much of the information which goes into a progressbar instead should be logged for later inspection.

ratchet freak already answered this in his comment. You can write your own implementation of IProgressMonitor that logs the information you wish.

Improve this answer
3
  • I'm not making myself clear. The problem is how to know how to divide the total progress monitor "ticks" among the subtasks. Say that I have a method which takes an IProgressMonitor and calls three methods. I don't want to guess how many ticks each call should get (when using SubMonitor#newChild(), for example).
    – JesperE
    Nov 20, 2012 at 15:49
  • @JesperE: You have two options. Set all of the totalWork values to IProgressMonitor.UNKNOWN, and leave all of your monitors indeterminate. Or, you can set all of the totalWork values to IProgressMonitor.UNKNOWN, and measure the amount of time your three methods takes.
    – Gilbert Le Blanc
    Nov 20, 2012 at 16:08
  • If I wanted a concrete solution or workaround to this particular problem I would be asking on stackoverflow.com. I'm more interested in thinking "outside the box" here, and not necessarily limit myself to what is technically possible with current APIs in Eclipse.
    – JesperE
    Nov 20, 2012 at 16:28
0

maybe you could annotate each method with custom annotation and then process those annotations.

or maybe you could log the last execution time of those methods and then estimate time based on that.

Improve this answer
1
  • Your answer starts to address some of the OP's concerns, but does not do so fully. Consider editing your answer and providing more details.
    – user53019
    Aug 27, 2013 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.