Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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 '12 at 15:08
    
Yes, I can. But I still consider it a kludge. –  JesperE Nov 20 '12 at 15:14
add comment

2 Answers

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.

share|improve this answer
    
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 '12 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 '12 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 '12 at 16:28
add comment

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.

share|improve this answer
    
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. –  GlenH7 Aug 27 '13 at 14:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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