[news.eclipse.tools] Re: progress monitor trouble

[Thomas Mäder <thomas_maeder@xxxxxxx>]

Doesn't look like that's the problem; you should get a clear SWTError
for access from the wrong thread

Thomas

"Christophe Elek [IBM-OTI]" wrote:

>
> Just a thought, but isn't the progress monitor running in a different
> thread, and if the code in the run requires to modify or notify the
> SWT thread's code, it should be done as asynchExec ? Now, you should
> get an error for that
>
> Juanita Ewing wrote:
>
>> Pardon the length of this message. All the code in this message has
>> been
>> compiled and tested under on eclipse .035, the JRE version.
>>
>> Summary: I've been trying to add a progress monitor to some code
>> that
>> edits portions of the JavaModel. I'd like to take advantage of the
>> built-in progress monitor part that is part of the Wizard
>> implementation.
>> But I am getting some VERY ODD results...
>>
>> The following version of the editing code works perfectly. Note that
>> it
>> has no progress monitors. We take care to fetch the working copy of
>> the
>> model before performing any edits. After the operation completes
>> (remember
>> this is being performed in a wizard), the editor, outline pane, etc
>> are
>> updated correctly regardless of whether the text of the java file
>> had been
>> edited before the operation was invoked. This indicates to me that
>> there
>> is not a problem accessing the working copy. Here is the code I am
>> executing to perform the edits to the JavaModel. This code is called
>> from
>> my wizard's performFinish() routine:
>>
>>         existingMethod.delete(false, null);
>>         IMethod redefinedMethod =
>> fType.createMethod(fRedefinedSourceString,
>> null, true, null);
>>         newMethod = fType.createMethod(fNewSourceString,
>> redefinedMethod, true,
>> null);
>>
>> When I incorporate a progress monitor into this operation things get
>> very
>> weird. I've told the WizardDialog that it needs a progress monitor,
>> and
>> then defined a runnable. In the code below, this is an
>> IRunnableWithProgress. The progress monitor appears to work properly
>>
>> during execution of the operation. The progress monitor correctly
>> shows
>> the description of the task and its progress. After the operation
>> completes is when things go wrong. Most importantly, the editor
>> contents
>> are wrong. The cursor is in a place that doesn't exist in the text
>> and the
>> text is only partially updated. The lines in the editor that have
>> been
>> covered by the wizard are out of synch with the lines that were
>> exposed.
>> The outline pane has incorrect contents. Some subsequent workbench
>> operations cause errors in the workbench because the displayed text
>> apparently is not in synch with the model. Sometimes the workbench
>> even
>> gets a fatal error. For example, FATAL ERROR in native method: Out
>> of
>> memory when expanding local ref table beyond capacity. Mostly the
>> text
>> looks sort of like it did before the edits to the model were
>> performed.
>> But this is wrong!!!
>>
>> I've tried many variations with progress monitors: With and without
>> SubProcessMonitors. Nulls instead of monitors to Java model
>> operations. No
>> updates to the monitor state. WorkbenchModifyOperation instead of
>> IRunnableWithProgress. Reveal selection code after the operation
>> completes... All these variations have the same wrong behavior as
>> the
>> version below.
>>
>> Here is a version of the editing code with a progress monitor. Just
>> like
>> the first version, this code is called from my wizard's
>> performFinish()
>> routine:
>>
>>         IRunnableWithProgress op = new IRunnableWithProgress() {
>>                 public void run(IProgressMonitor monitor) throws
>> InvocationTargetException {
>>                         try {
>>                                 monitor.setTaskName("Method
>> Extraction");
>>                                 monitor.beginTask("Extraction", 5);
>>                                 existingMethod.delete(false, null);
>>                                 monitor.worked(1);
>>                                 IMethod redefinedMethod =
>> fType.createMethod(fRedefinedSourceString,
>> null, true, null);
>>                                 monitor.worked(2);
>>                                 newMethod =
>> fType.createMethod(fNewSourceString, redefinedMethod,
>> true, null);    //should be false
>>                                 monitor.worked(2);
>>                         } catch (JavaModelException e) {
>>                                 throw new
>> InvocationTargetException(e);
>>                         } finally {
>>                                 monitor.done();
>>                         }
>>                 }
>>         };
>>
>>         try {
>>                 getContainer().run(true, true, op);
>>         } catch (InterruptedException e) {
>>                 return null;
>>         } catch (InvocationTargetException e) {
>>                 // ErrorDialog stuff
>>         }
>>
>> Incorporating a progress monitor shouldn't be hard. So I must be
>> going in
>> the wrong direction somewhere. Can someone please point me in the
>> proper
>> direction?
>
> --
> -------------------------
> Christophe Elek
>
>