# Neustart nach preference-Änderung



## NGP (14. Apr 2009)

Hallo,

ich möchte in meiner RCP-Anwendung nach einer Änderung bestimmter Präferenzen bei Bestätigung in der preference-page neu starten:


```
boolean performOk(){
  super.performOk();
  if(boolRestartNecessary){
    PlatformUI.getWorkbench().restart();
  }
  return true;
}
```

Das funktioniert soweit aber beim beenden der PreferencePage wird vermutlich noch auf die Workbench zugegriffen, die bereits geschlossen ist - NullPointer -


```
at org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.close(FilteredPreferenceDialog.java:587)
	at org.eclipse.ui.internal.dialogs.WorkbenchPreferenceDialog.close(WorkbenchPreferenceDialog.java:140)
	at org.eclipse.jface.preference.PreferenceDialog$13.run(PreferenceDialog.java:951)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
...
```
Es wird natürlich trotzdem beendet und wieder gestartet, aber das missfällt mir, ich fand jedoch bislang keinen Weg, den Neustart erst dann anzustoßen, wenn die PreferencePage vollständig beendet ist. So etwas wie PostWindowClosed().

Hintergrund: Mein Anwender muss sich im Splash-Screen gegenüber der Datenbank authentifizieren. Ist keine Verbindung zur Datenbank vorhanden, wird der Login-Screen geschlossen, das Hauptfenster nicht gezeigt und es erscheint dafür die PreferencePage in der der Anwender die Datenbankadresse, Port,... angeben kann. Ändert er dort die Datenbankadresse startet die Anwendung neu, verbindet sich zu der DB  und zeigt den Login-Screen.

Jemand etwas vergleichbares schon gelöst?

Grüße
Thomas


----------



## NGP (15. Apr 2009)

Einen Notbehelf fand ich:

die preferences-page ist modal. Ich kann in der OK-Methode der preferences-page ein bit in der aufrufenden Klasse setzen. Wenn die Ablaufsteuerung zurückgegeben wird, kann ich nach einer Prüfung auf das Bit den Neustart veranlassen.

Sicher nicht die schönste Lösung, zumal nur in der Situation nutzbar, dass ich im Code die preference-page aufrufe.
Schönere Lösungsvorschläge willkommen.

Grüße
Thomas


----------



## Vayu (15. Apr 2009)

Kannst du dich nicht als Listener an die Prefs hängen und bei change einer bestimmten halt den neustart veranlassen?


```
DeinPluginActivator.getDefault().getPreferenceStore().addPropertyChangeListener(WerAuchImmer);
DeinPluginActivator.getDefault().getPluginPreferences().addPropertyChangeListener(WerAuchImmer);
```


----------



## NGP (15. Apr 2009)

Jetzt wenn ich's lese, ...
Statt über die properties-page zu versuchen geordnet herunterzufahren, auf eine Änderung der Properties reagieren.

-Habe es eben eingebaut. Einwandfrei. Danke für den Tip.

(Wenn ich jetzt noch die Schaltfläche fände, mit der ich das Thema als abgeschlossen markiere  )

Gruß
Thomas


----------



## Vayu (15. Apr 2009)

die schaltfläche gibt es noch nicht wieder. im alten forum ging das. wird aber wohl dran gearbeitet


----------



## NGP (16. Apr 2009)

Ich habe festgestellt, als ich den Vorschlag testete war in der Run-Configuration -consoleLog nicht gesetzt.
Die Exception wird auch mit dem Listener geworfen. :-(

Die properties-page greift noch irgendworauf zu, wenn der Restart ausgelöst wird. (Wenn ich den Neustart auslöse solange die Page sichtbar ist ergibt das ebensowenig ein Problem wie wenn ich es aufrufe, nachdem die PropertiesPage die Kontrolle zurückgab. Wohl irgendwo eine "Schreibe-die-Properties-Funktion" innerhalb der preferenceDialog-Klassen, die noch nicht fertig ist)



NGP hat gesagt.:


> -Habe es eben eingebaut. Einwandfrei. Danke für den Tip.


----------



## Vayu (16. Apr 2009)

ok, da bin ich jetzt ehrlich gesagt ratlos ...

Ist es deine PrefPage die die NullPointerException wirft? Wenn ja zeig mal bitte ein bisschen Code (auch wenn ich da wohl eh nichts finde  aber gucken schad nix)


----------



## NGP (16. Apr 2009)

Der Fehler tritt bereits bei vom Template erzeugten Code auf.

```
Extensions-org.eclipse.ui.preferencePages-templates-PreferencePages
```
An dem habe ich mich orientiert. Bei meiner Anwendung fügen noch weitere Plugins weitere Preferenzen ein aber prinzipiell das Selbe und auch bei dem Template taucht der Fehler auf.

Ich habe mal im Activator der RCP oder auch in einer ansonsten leeren view

```
Activator.getDefault().getPreferenceStore().addPropertyChangeListener(myPropertyChangeListener);
...
private IPropertyChangeListener myPropertyChangeListener=new IPropertyChangeListener(){

		public void propertyChange(PropertyChangeEvent event) {
			PlatformUI.getWorkbench().restart();
		}
	};
```
angelegt. Die Seite wird im Menü mit dem Command ID = org.eclipse.ui.window.preferences aufgerufen.

Im Debugger verfolgt wird der Restart ausgelöst, nach wenigen Schritten kommen dann Preference-Methoden wie

```
getPreferenceStore().setValue(getPreferenceName(), value);
oder 
StringFieldEditor -- protected void doStore() {
```
Das ist übrigens auch die letzte Methode, die vor der Exception gestartet wird.
Es macht den Eindruck, dass erst der property-changed-event (inklusive restart) ausgelöst wird, dann versucht wird, die neuen Properties zu schreiben. Das kann ja nur schief gehen.

Es gibt das Resources-Plugin mit dem man wohl handler erzeugen kann, die reagieren, wenn sich eine Datei ändert, der Gedanke wirkt aber nicht wirklich überzeugend auf mich.


----------



## Vayu (16. Apr 2009)

hab grad mal ein bisschen rumprobiert.

probier mal folgendes in deinem performOk()


```
UIJob j = new UIJob("BLABLA") {

            @Override
            public IStatus runInUIThread(IProgressMonitor monitor) {
                // hier vllt noch einen dialog der fragt, ob wirklich neu gestartet werden soll
                PlatformUI.getWorkbench().restart();
                return Status.OK_STATUS;
            }

        };
        j.schedule();
```


----------



## NGP (16. Apr 2009)

Habe es eingebaut. Keine Fehlermeldung. Du hast es gelöst :toll:
(Und ich habe kontrolliert, ConsoleLog ist gesetzt )

Ich hatte schon probiert den Neustart als eigenen Job mit kurzer Verzögerung zu starten. Gab aber Fehler. Sollte ich mir mal anschauen, worin UIJob Job erweitert.

:arrow: AsyncExe


----------



## Vayu (16. Apr 2009)

du musst evtl noch unterscheiden, ob derjenige auf APPLY oder auf OK gedrückt hat 

ich denke bei APPLY möchte man nicht zwingend, dass auf einmal die workbench neustartet.

sprich performApply überschreiben, n flag setzen und performOk aufrufen


----------



## Saxony (22. Jun 2009)

Hiho,

da habe ich mal noch eine weitere Frage dazu: Wie kann ich für den neuen Programmstart auch neue Programmargumente mitgeben/setzen? Zum Beispiel der Neustart soll mit -nl en erfolgen.

bye Saxony


----------



## Wildcard (23. Jun 2009)

Saxony hat gesagt.:


> da habe ich mal noch eine weitere Frage dazu: Wie kann ich für den neuen Programmstart auch neue Programmargumente mitgeben/setzen? Zum Beispiel der Neustart soll mit -nl en erfolgen.


Selbst wenn es dafür eine Methode gibt, wäre die Änderung natürlich nicht persistent, also beim nächsten Restart wieder vergessen, insofern solltest du vielleicht die eclipse.ini anpassen, oder die Programmverknüpfung entsprechend anpassen.


----------



## Gast2 (23. Jun 2009)

Saxony hat gesagt.:


> Hiho,
> 
> da habe ich mal noch eine weitere Frage dazu: Wie kann ich für den neuen Programmstart auch neue Programmargumente mitgeben/setzen? Zum Beispiel der Neustart soll mit -nl en erfolgen.
> 
> bye Saxony



Ich habs mal gemacht, geht erst ab elcipse 3.4.xx ohne Bug.
Da gibt es eine extra restart map wo man neue Argumente reinlegen oder alte ändern kann.
Musst ein bischen gogglen gibt jede menge Bugs/Beschwerden dazu


----------

