# Editor und doSave()



## Gast2 (13. Okt 2009)

Hallo zusammen,

in einem Editor hat man eine doSave(IProgressMonitor monitor) methode. Wie benutzt man richtig diesen Monitor damit des User auch diesen Vorgang sieht. So sieht er nichts. 

```
@Override
	public void doSave(IProgressMonitor monitor) {
		
		monitor.beginTask("Test", 100);
		monitor.worked(50);
		try {
			Thread.sleep(1000);
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		monitor.worked(50);
		monitor.done();
}
```

Wenn ich aber einen Job instanziere und die  
	
	
	
	





```
protected IStatus run(final IProgressMonitor monitor)
```
 überschreibe habe ich ein neues monitor Objekt und der Job wird angezeigt. Meine Frage ist was mich mit dem Monitor Objekt in doSave() und wie benutze ich es richtig, damit der User auch was sieht.


----------



## Wildcard (13. Okt 2009)

Du benutzt das schon richtig, in diesem Fall liegt es beim Aufrufer des Codes was er mit dem Monitor macht (also an der Workbench). Wie genau die Logik der Workbench an dieser Stelle aussieht kann ich dir nicht sagen, vielleicht wird nur dann Progress angezeigt wenn der Thread länger als X Sekunden benötigt.


----------



## Gast2 (13. Okt 2009)

Wildcard hat gesagt.:


> Du benutzt das schon richtig, in diesem Fall liegt es beim Aufrufer des Codes was er mit dem Monitor macht (also an der Workbench). Wie genau die Logik der Workbench an dieser Stelle aussieht kann ich dir nicht sagen, vielleicht wird nur dann Progress angezeigt wenn der Thread länger als X Sekunden benötigt.



Wie meinst du wie der Code an der Stelle aussieht den kann ich ja selber gestalten???
Also ich bekomms nur mit jobs hin, dass diese angezeigt werden.
Wie machst du es wenn in dem doSave etwas längeres passiert, dass es in de Jobview angezeigt wird oder als ProgressDialog???


----------



## Wildcard (13. Okt 2009)

Der ProgressMonitor ist Headless, ohne grafische Entsprechung. Es liegt am Aufrufer (der Workbench) um zu entscheiden ob und wie dieser Progress dem Anwender präsentiert wird. Bei Jobs entscheidet zB der Job Manager anhand isUser und ob eine Workbench läuft ob Progress angezeigt werden soll, oder nicht. Es liegt in diesem Fall also an der Save Action zu entscheiden was mit dem Progress passieren soll, nicht an der doSave methode.


----------



## Gast2 (14. Okt 2009)

Wildcard hat gesagt.:


> Der ProgressMonitor ist Headless, ohne grafische Entsprechung. Es liegt am Aufrufer (der Workbench) um zu entscheiden ob und wie dieser Progress dem Anwender präsentiert wird. Bei Jobs entscheidet zB der Job Manager anhand isUser und ob eine Workbench läuft ob Progress angezeigt werden soll, oder nicht. Es liegt in diesem Fall also an der Save Action zu entscheiden was mit dem Progress passieren soll, nicht an der doSave methode.



Jop soweit hab ich es mir gedacht. Aber einem Job oder ProgressMonitor kann ich keinen Monitor mitgeben, dass heißt wenn ich einen neuen Job instanzieren muss ich die 
	
	
	
	





```
protected IStatus run(IProgressMonitor monitor)
```
 überschreiben und da hab ich einen neues monitor Objekt, wobei das andere überflüssig wird.Oder übersehe ich was? Eventuell irgendwo ein Beispiel?


----------



## Wildcard (14. Okt 2009)

Beispiel? Der Job Manager gibt dem Job einen Progress Monitor der (bei setUser(true)) in einem Dialog angezeigt wird. Die Workbench (oder die Action die doSave) aufruft, tut das nicht. Vielleicht läuft der ProgressMonitor einfach ins leere (NullProgressMonitor), vielleicht wird erst ein Dialog angezeigt wenn der Vorgang mehr als n Sekunden dauert.
Innerhalb von doSave hast du keine Kontrolle darüber, du musst lediglich Progress Reporten. Was mit diesem Progress dann passiert bestimmt die Workbench


----------



## Gast2 (14. Okt 2009)

Okay alles klar wenn ich also eine lange save methode habe, dann muss ich einen eigenen Job machen und diesen über den JobManager anzeigen lassen() innerhalb der doSave. 
Also die doSave ruf ich ja nicht selber auf in einem Editor, das macht ja das Framework.
Richtig verstanden?

Aber dann versteh ich immer noch nicht ganz für was der Monitor in der doSave genau da ist?!


----------



## Wildcard (15. Okt 2009)

Nein, das habe ich nicht gesagt, ich habe gesagt es ist lediglich deine Aufgabe den Progress zu Reporten, nicht ihn anzuzeigen.
Schau doch einfach mal nach was die Workbench damit macht indem du einen Breakpoint setzt und dann den Stack hochläufst.


----------



## Gast2 (15. Okt 2009)

Okay werd ich daheim mal machen. Ich überprüf auch mal ob es ein NullProgressMonitor ist.

Gibt es irgendwelche Workbench settings, um da irgendwas dran zu ändern?
Also ich reporte meine methode, aber wenns niemand interessiert oder ich nichts damit machen kannt bringts ja irgendwie nix^^...


----------



## Wildcard (15. Okt 2009)

Ich kenne die Eclipse API nunmal nicht auswendig, du wirst also selbst schauen müssen was mit dem Progress passiert.


----------



## Gast2 (15. Okt 2009)

Also ich komm von der WorkbenchPage savePart...und dann in den SaveHelper.run. Und hab als Monitor

```
org.eclipse.ui.internal.dialogs.EventLoopProgressMonitor
```
aber jetzt weiß ich auch nicht mehr ^^!?!Vor allem nicht wie ich es manipulieren kann^^, vielleicht stell ich mich grad blöd an, aber was hat das mit der API zu tun ich drück auf Save(Standard Command) und das Framework macht doch den rest????


----------



## Wildcard (15. Okt 2009)

Den sollst du auch nicht manipulieren. Schau doch einfach mal was damit passiert, dann findest raus unter welchen Bedingungen der Progress dem User präsentiert wird.


----------



## Gast2 (16. Okt 2009)

Mhm ich glaub ich versteh leider den zusammenhang noch nicht...
Wenn ich debuge komme ich soweit zurück dass ich weiß wo der Monitor erstellt wird.
Aber nirgends sehe ich einen Job, wo es eine bedingung geben könnte dass ich ihn anzeigen lassen könnte...

im SaveHelper.savePart

```
IRunnableWithProgress progressOp = new IRunnableWithProgress() {
			public void run(IProgressMonitor monitor) {
				IProgressMonitor monitorWrap = new EventLoopProgressMonitor(monitor);
				saveable.doSave(monitorWrap);
			}
		};

		// Do the save.
		return runProgressMonitorOperation(WorkbenchMessages.Save, progressOp, window);
```

Aber wenn ich das richtig verstanden hab passiert des alles im UI Thread...
Wie machst denn du sowas, du hast ein editor gibst daten ein, diese willst du jetzt speichern??


----------



## Gast2 (16. Okt 2009)

Super der Progress wir in der StatusLine angezeigt ahhh^^... Ich find net raus wie ich den in der View oder in nem eigenen ProgressDialog anzeigen lassen kann...

weil hier im ApplicaitonWindow holt er sich den StatusLineManager. Ich denk mal um einen Progress in der View anzeigen zu lassen bräuchte ich den ProgressManager

```
try {
            operationInProgress = true;
            final StatusLineManager mgr = getStatusLineManager();
            if (mgr == null) {
                runnable.run(new NullProgressMonitor());
                return;
            }
  
                BusyIndicator.showWhile(display, new Runnable() {
                    public void run() {
                        try {
                            ModalContext.run(runnable, fork, mgr
                                    .getProgressMonitor(), display);
                        } catch (InvocationTargetException ite) {
                            holder[0] = ite;
                        } catch (InterruptedException ie) {
                            holder[0] = ie;
                        }
                    }
                });
```


----------



## Wildcard (16. Okt 2009)

Wenn du unbedingt einen Dialog sehen willst, und die Workbench dafür keinen Hook anbietet, dann würde mir nur einfallen einen Progress Monitor Wrapper zu erstellen der den Progress an zwei ProgressMonitors weiterreicht. Einer ist der übergebene, der andere ein eigener den du in einem Dialog anzeigst.
Reicht die Status Line denn nicht? Braucht dein Editor derart lange?


----------



## Gast2 (17. Okt 2009)

Nee so lange braucht er nicht, wollte nur rausfinden obs es möglich wäre.
Ich denke ich mache einfach einen eigenen Job oder ProgressDialog in der save Methode.
Spricht ja eigentlich nichts dagegen...
Die StatusLine wäre in Ordnung nur leider kann man dort den Progress abbrechen.


----------



## Wildcard (17. Okt 2009)

Du kannst nur abbrechen wenn du auf ProgressMonitor#isCanceled reagierst. Dein Code wird nicht gestoppt.


----------



## Gast2 (17. Okt 2009)

Ja des weiß ich...
Aber sieht halt doof aus wenn der Button cancel aktiviert ist, dann denkt der User er kann was machen, obwohl es nicht so ist.


----------



## Wildcard (17. Okt 2009)

Richtig, sehe ich auch so


----------



## Gast2 (18. Okt 2009)

Wildcard hat gesagt.:


> Richtig, sehe ich auch so



Sind wir schon zu zweit^^


----------

