Support Request #3860
closed
Loosing layout after renaming manifest file
Added by hidden over 5 years ago.
Updated over 5 years ago.
Requester's Priority:
Normal
Description
Supportanfrage
ADTF wird mittels ADTF Launcher gestartet.
adtf_launcher.exe adtf_devenv.manifest
Das Ergebnis ist das erwartete: ADTF wird mit der bekannten Fensteranordnung der "Dock Windows" gestartet
Eine Umbenennung der Manifest führt zu einem anderen Verhalten.
adtf_launcher.exe adtf_mydevenv.manifest
Das Ergebnis ist ein leeres ADTF Fenster, alle "Dock Windows" fehlen und müssen per Hand geöffnet und an die passende Stelle gezogen werden.
Wird ADTF geschlossen und erneut über den Launcher gestartet, sind wieder alle "Dock Windows" verschwunden.
- Ist das Verhalten so zu erwarten?
- Ist das Verhalten dokumentiert?
- Kann ich als Anwender etwas tun, um dieses Verhalten zu umgehen? Insbesondere der letzte Punkt ist ein Show-Stopper
Lösung
Overview of the layouts within ADTF
- Status changed from New to In Progress
- Topic set to ADTF::Common
- Status changed from In Progress to Customer Feedback Required
Hallo Jens,
wie bereits am Telefon besprochen hier noch eine kurze Zusammenfassung:
In der manifest (adtf_devenv.manifest) steht nichts zum Systemlayout.
Damit dies funktioniert solltest Du die folgenden Dateien (Kopien) ebenfalls an die "geänderte" .manifest mit umbenennen/anpassen.
adtf_devenv.settings
adtf_devenv.Default.systemlayout
oder eben ggf ein anpasstes Systemlayout mit:
adtf_devenv.Common.systemlayout
Was in deinem Beispiel dann eben z.b. zu adtf_mydevenv.Common.systemlayout wird.
Bitte in jeden Fall noch um ein Feedback und Antwort ob wir das Ticket damit schließen können.
Danke und Gruß
Matthias
Hallo Matthias,
nachdem ich die Dateien ergänzt habe, klappt der Start nun wie erwartet.
Ich habe auch einmal alle Dateien an einen anderen Ort kopiert und dann den ADTF Launcher aufgerufen. Hier zeigt sich dann, dass die url relativ zur binary definiert sind und die Services nicht geladen werden können. Als Workaround kann noch die Variable $(APPDIR) ergänzt werden (Im Original im Abschnitt "dependencies" für "linux" genutzt). In einem ersten Test können die entsprechenden Services dann auch unter Windows geladen werden und ADTF startet wieder:
<plugin url="$(APPDIR)/adtf_clock.srv" />
Ansonsten kann das Ticket aus meiner Sicht zu gemacht werden.
Viele Grüße
Jens
- Subject changed from Umbennenung der Manifest-Datei "adtf_devenv" führt zu anderem Verhalten to Loosing layout after renaming manifest file
- Status changed from Customer Feedback Required to To Be Closed
- Resolution set to Solved Issue
Hallo Jens,
Ich habe auch einmal alle Dateien an einen anderen Ort kopiert und dann den ADTF Launcher aufgerufen. Hier zeigt sich dann, dass die url relativ zur binary definiert sind und die Services nicht geladen werden können. Als Workaround kann noch die Variable $(APPDIR) ergänzt werden (Im Original im Abschnitt "dependencies" für "linux" genutzt). In einem ersten Test können die entsprechenden Services dann auch unter Windows geladen werden und ADTF startet wieder:
Nein, natürlich relativ zum manifest file, siehe Kap 4 ADTF Manifest File
Das ist kein Workaround sondern normales Verhalten, über die Manifest Datei definierst du deine ADTF Ausprägung, der Launcher ist "dumm" und kennt keine Plugins, sondern lädt diese nur.
Dazu muss er wissen wo sie liegen.
Die Devenv ist die default Vollausprägung und lädt einfach alles !
Nachtrag zum Layouting, siehe Overview of the layouts within ADTF
Ticket wird geschlossen
- Description updated (diff)
Hallo Florian,
Du hast natürlich recht. "Problem" ist, dass es relative Pfade sind, die man zu absoluten anpassen muss/kann sobald man die manifest außerhalb der ADTF-Installation verortet.
"Workaround" weil ich nicht erwartet hatte, dass er die Umgebungsvariable (teilweise mit backlashes) schluckt.
Nochmal vielen Dank für die Hinweise.
Viele Grüße
Jens
- Project changed from 11 to Public Support
- Status changed from To Be Closed to Closed
- Private changed from Yes to No
Also available in: Atom
PDF