Nach Rausschreiben über "Neue Datei erzeugen" wird das "Projekt" geleert

[fwtsd]

Hallo

Nach Rausschreiben des fertig geschnittenen TS files über "Neue Datei erzeugen" wird anschliessend das gerade bearbeitete "Projekt" komplett geleert. Man erhält wieder ein komplett leeres Hauptfenster. 

Da ich ein gerade geschriebens TS file sofort mal auf die Schnittqualität überprüfe und bei Nichtgefallen die Schnitte noch einmal überarbeiten möchte, muss ich (fast) alle Schritte des Einlesens des zu schneidenen TS Ursprungfiles noch einmal ausführen. Also TS file öffnen über Menüpunkt, die Analyse abwarten, alte Schnittpunkte übernehmen bzw. nach Öffnen des Schnittfensters die gespeicherte Schnittliste wieder laden usw.

Könnte das Hauptfenster nach dem Schreiben über "Neue Datei erzeugen" nicht das aktuelle Projekt (er)halten? D.h. ich komme dann sofort über den Button "Schnitt vorbereiten" wieder in das Schnittfenster des immer noch geladenen "Projektes" und kann sofort weiterarbeiten. Das wäre doch ein entscheidender Zeitgewinn. Oder habe ich im Programmablauf/ in der Bedienung etwas übersehen?

[testest]

Wurde schon öfter nach gefragt, der große Cypheros dürfte es auf die Liste gesetzt haben?
...
...
...
..doch niemand weiß wie weit unten im Einmannbetrieb..

[fwtsd]

..der große Cypheros dürfte es auf die Liste gesetzt haben?
.

Ja gut. Bin neu hier im Forum und nutze den Doctor erst seit kurzem.

Dann hoffe ich mal, dass dieser Punkt in der Prio Liste doch weiter nach oben rutscht. 

[Cypheros]

Der TS-Doctor merkt sich den letzten Schnitt. Wenn Du die gleiche Datei nochmal öffnest, läd er die vorher erstellte Schnittliste erneut und Du kann den Schnitt korrigieren.

[testest]

Der TS-Doctor merkt sich den letzten Schnitt. Wenn Du die gleiche Datei nochmal öffnest, läd er die vorher erstellte Schnittliste erneut und Du kann den Schnitt korrigieren.

Mein Herr, das hat er oben schon integriert gehabt: "Also TS file öffnen über Menüpunkt, die Analyse abwarten, alte Schnittpunkte übernehmen bzw. nach Öffnen des Schnittfensters die gespeicherte Schnittliste wieder laden usw."

Hier beschreibt er eine laaange Zeit und reichlich komplizierte Aktionen, all das könnte wegfallen wenn nach dem Schreiben des ts die Infos noch drin wären im TSDoc.
Auch ich habe häufig und regelmäßig (!) den Fall das ich die gleiche Datei direkt nochmal einladen muß, zB. wenn die Audioauswahl, Untertitel oder andere Parameter bei mehreren Schnitten (Filmen) innerhalb einer Datei wechseln oder auch schlicht Alzheimer mich dazu zwingt (ich darf auch mal defekt sein liebe Untertitelfans)?

Ich weiß schon was du fürchtest, "wenn ich das mach melden sich wieder mind. 150 Leute 'Hilfe, wie bekomm ich jetzt ein neues ts rein? Da bleibt ja immer das alte drin?" oder Änderung bei Stapelverarbeitung, die finden die 375te? Option im Menü nicht 'ts wird nach Schreiben in TSDoc behalten' - ja/nein -  die ich dir gerade andienen möchte Ich bin aber sicher die Option wird deeer Riesenerfolg! -> Aktion Beschleunigung des Workflows..

[Mam]

Ich bin aber sicher die Option wird deeer Riesenerfolg! -> Aktion Beschleunigung des Workflows..

Möchte ich zwar stark bezweifeln, aber wat solls  ?

Sein Problem dabei ist, dass er bestimmt richtig stolz darauf ist, nach dem Durchlauf alle Spuren beseitigt zu haben, und den Doc wieder "auf Anfang" setzen zu können, ohne grosse Speicherlecks oder fehlinitialisierte Variablen.
Je nachdem, in wie weit er den "Reset" zentralisiert hat (sprich: ist alles in einer Funktion, oder über das ganze Programm verteilt?), ist es kein Problem, statt nach dem Durchlauf die Funktion erst bei "Öffnen" (einer neuen Datei) aufzurufen, oder, wenn verteilt, dann ist es so ziemlich unmöglich, ohne die Gesamtstabilität ernsthaft zu gefährden.

Ich bezweifle aber stark, dass Du mit Deinem Vorschlag beim Boss auf offene Ohren stoßen wirst, "never change a running system..."

[fwtsd]

... Ich bin aber sicher die Option wird deeer Riesenerfolg! -> Aktion Beschleunigung des Workflows..

.
Ja genau, das war/ist auch mein Gedanke/ meine Bitte, den Programmablauf an dieser Stelle zu modifizieren.

Wenn ich beispielsweise eine Datei aus einem Textverarbeitungsprogramm speichere/ rausschreibe, muss ich die soeben bearbeitete/ geschriebene Datei ja auch nicht zwingend neu laden um sie neuerlich zu bearbeiten, sofern ich das Programm selbst oder die Datei nicht schließe.   

[testest]

Mönsch Mam, halt ein, du wetterst doch immer dagegen wenns nicht auf deinem Mist gewachsen ist..
Schon Anteilseigner? Großes Aktienpaket?

Wenn ich beispielsweise eine Datei aus einem Textverarbeitungsprogramm speichere/ rausschreibe, muss ich die soeben bearbeitete/ geschriebene Datei ja auch nicht zwingend neu laden um sie neuerlich zu bearbeiten, sofern ich das Programm selbst oder die Datei nicht schließe.   

Richtig! Das ist eine grundlegende Computer-comfort-regel, rausschmiss des alten wenn, dann erst bei einladen von neuem. Aus gutem Grund!

[Djfe]

Sein Problem dabei ist, dass er bestimmt richtig stolz darauf ist, nach dem Durchlauf alle Spuren beseitigt zu haben, und den Doc wieder "auf Anfang" setzen zu können, ohne grosse Speicherlecks oder fehlinitialisierte Variablen.
Je nachdem, in wie weit er den "Reset" zentralisiert hat (sprich: ist alles in einer Funktion, oder über das ganze Programm verteilt?), ist es kein Problem, statt nach dem Durchlauf die Funktion erst bei "Öffnen" (einer neuen Datei) aufzurufen, oder, wenn verteilt, dann ist es so ziemlich unmöglich, ohne die Gesamtstabilität ernsthaft zu gefährden.

Ich bezweifle aber stark, dass Du mit Deinem Vorschlag beim Boss auf offene Ohren stoßen wirst, "never change a running system..."

sicherlich die Regel "never change a running system" ist sicher wichtig,
aber sein derartiges System kannst du in dem Punkt auch nicht mehr ganz als laufend bezeichnen, schließlich hindert es ihn daran neue Innovationen zu ermöglichen

er sollte einfach ein Projekt nebenher starten, in welchem er den TS-Doctor (unabhängig von den Hauptupdates) in OOP überträgt, dann hat er die ganzen blöden Probleme nicht mehr und kann später ganz komfortabel Teile des Programms abändern/unterschiedlich zusammenfügen (wenn alles OOP ist, werden noch die letzten Programmänderungen integriert und er kann in der Betaversion testweise auch schon die neue Version anbieten)
alle Funktionen wie Analyse, Werbeerkennung, Schnitt, Skin/Oberfläche etc. wären sauber getrennt
und ganz wichtig: wenn dieser Teil abgeschlossen ist, steht der Weg offen für die Ideen zur Version 2.0, die in einem anderen Thread aufgelistet wurden (er kann ganz einfach eine neue Batchverarbeitung schreiben, wobei mit einfach gemeint ist, dass der Unterbau des Programms dann unabhängig ist und er die Oberfläche/das Interface autark ändern kann)
alle Optionen/Analyseschritte wären dann alleinstehend und nicht wie von dir beschrieben irgendwo im Programm verteilt, es würden bei sauberer Programmierung auch keine Probleme auftreten, dass irgendein Teil im Speicher verbleibt


@test man kann es auch einfacher als über die Optionen lösen
einfach ein Schließen Eintrag im Menü unter Datei öffnen
das machen viele Programme so und somit dürfte es keinen wirklich verwirren
ansonsten baut er halt noch einen zusätzlichen X-Button ein oder fängt den Schließen Button ab->wenn einer den roten Schließen Button drückt (oben in den Fensterleiste) wird einfach nur die Datei geschlossen
(@Mam bei diesem Schritt könnte er sogar die Form wechseln/alles vergessen/ein neues Fenster öffnen, um sicher zu gehen, dass keine Variablen verbleiben, nur sollte es bei OOP nicht mehr nötig sein)

[testest]

..weise Worte oh Djfe, mögest du erhört werden..

ansonsten baut er halt noch einen zusätzlichen X-Button ein ->wenn einer den roten Schließen Button drückt (oben in den Fensterleiste) wird einfach nur das "Speichern fertig" Fenster geschlossen...

...und das ts ist weiterhin im TSDoc geladen.

Jaaa das will ich, das will ich, huhu Cyph bist noch da?

[Cypheros]

Ja, bin noch da. Da ich das Thema aber schon gefühlte 1000 mal erklärt habe, hier nochmal ein Zitat einer meiner letzten Statements:

Die Analyse liefert nicht nur Information über die Aufnahme sondern konfiguriert auch gleich die Ausgabemodule. Wie bei einem Motor wo durch die Motorkontrolle Zündzeitpunkt, Kompressionsdruck und hunderte weiterer Parameter eingestellt werden.

Diese Werte ändern sich während der Fahrt und müsste somit vorher gespeichert werden, um sie dann zurückzusetzen. Das wäre aber sehr aufwändig und fehleranfällig.

[Djfe]

kannst du keine Objekte wie Analyse und Schnittfenster getrennt erstellen, in denen die ganzen Infos gespeichert werden?

ich verstehe, dass es irgendwo zusammenarbeiten muss, kenne selbstverständlich deinen Code nicht

aber, wenn sich Werte "während der Fahrt" ändern, speicherst du halt alle Werte in entsprechenden Objekten
das würde dann wie folgt funktionieren

Hauptthread
   Analyse(Objekt)
   Datei(Objekt)
   Schnittfenster/Ausgabemodule(Objekt)
   GUI(Objekt)

Datei wird als Objekt geladen -> ermöglicht auch das gleichzeitige Öffnen mehrerer Filme, enthält alle wichtigen Analyseergebnisse: Tabellen, PCR, EPG, Größe, Streams (Codec+Container), etc. ; erledigt somit die Zwischenspeicherung der Analyseergebnisse, das Löschen/Zurücksetzen dieser Informationen ist absolut nicht fehleranfällig, da nach dem Schließen der Datei durch Vererbung auch alle dessen Variablen mitgelöscht werden
(PCR wird beispielsweise als weiteres Objekt gespeichert und besitzt seine eigene destruct Funktion, die aufgerufen wird, sobald das parent-Element gelöscht wird)

Analyse (entweder als Hauptobjekt oder als Unterobjekt einer Datei) wird durch den Hauptthread dazu aufgerufen, eine Analyse zu machen, Analyseergebnisse werden in der Datei gespeichert (nur die später benötigten)

die Ausgabemodule (entweder gleichzeitig mit der Analyse erstellt oder später) holen sich ihre Konfiguration aus den Analyseergebnissen (die eventuell bereits durch die Analyse dahingehend aufbereitet wurden, dass sie als Konfigurationen übernommen werden können)
wenn die Ausgabemodule eher geladen werden, würde auch die Wartezeit beim Start des Schnittfenster wegfallen, da sie bereits im Hintergrund geöffnet sind und nachher nur noch im Schnittfenster sichtbar gemacht werden

die GUI ruft die einfachen Informationen einer Datei ab, um sie anzeigen zu können
sie trägt sich in die Funktionen ein, die die Variablen in der Datei(Objekt) ändern, denn alle Variablen sind Privat und werden nur durch Funktionen geändert, welche Updatebefehle an GUI, Ausgabemodule etc. weiter senden (eventuell tut's bei der GUI auch ein genereller Updatebefehl am Ende der Analyse, die Ausgabemodule müssen aber wie du sagtest sofort die Änderungen übernehmen)
Beispiel:
Die Analyse findet ein EPG, ruft die Funktion auf, die in der Datei das Objekt EPG konstruiert, übergibt alle wichtigen Werte als Variablen
->zum Schluss wird nachgesehen, ob jemand eingetragen ist, der über Änderungen informiert werden muss:
in diesem Fall wird also die GUI wie folgt informiert: GUI.update(Self); //wobei Self für das EPG Objekt ist


auch ein Motor lässt sich sicherlich als Objekt darstellen:
Motor
    construct (starte Motor -> startet Motorkontrolle)
    Motorkontrolle (Objekt)
         Überprüfung der Parameter/des Zustands -> Ergebnisse passen Zündzeitpunkt, Kompressionsdruck etc. an
         diverse Variablen mit Ergebnissen der Analyse/Motorkontrolle
    Zündzeitpunkt
    Kompressionsdruck
    ...hundert weitere Parameter...

"bei voller Fahrt": es sagt ja keiner, dass die Abläufe getrennt werden, sondern nur die einzelnen Programmmodule, Analyse und Ausgabemodule rufen sich ja gegenseitig auf (über Funktionen), es müssen also auch nicht alle Infos zwischengespeichert werden, sondern du kannst ja auch direkt das Ausgabemodul initialisieren und in ihm die Konfigurationen festsetzen

scheinbar speicherst du ja quasi gar nichts zwischendurch sondern gibst sie möglichst schnell an die Ausgabemodule, um sicher gehen zu können, dass sie dann keiner mehr verunstalten kann und sie auch später nicht für Probleme sorgen (als Leichen irgendwo im Programm),
du müsstest also die komplette Programmstruktur umschreiben, um einen sauberen Ablauf zu ermöglichen und einen übersichtlichen Code

http://www.itwissen.info/definition/lexikon/Objektorientierte-Programmierung-OOP-object-oriented-programming.html
http://www.delphipraxis.net/940502-post5.html

[Cypheros]

Das Ganze ist in Delph geschrieben, OOP und besteht aus dutzenden von Units und Klassen. Über 500.000 Programmzeilen.
Das schmeißt man nicht einfach über den Haufen um den erneuten Schnitt der gleichen Aufnahme zu bescheunigen.

[Djfe]

Ist klar
Würde aber auch zukünftige Innovationen ermöglichen und nicht bloß, dass die Datei geladen bleibt.

Gibt aber wohl momentan deutlich wichtigeres als derartig viel Code umzuschreiben...

Hab bisher auch nur theoretisch überlegt, die Ausmaße sind natürlich deutlich größer und der Nutzen entspricht wohl momentan nicht der nötigen Arbeit.

[fwtsd]

Als Themenstarter und Programmier-Laie habe ich die von mir losgetretene Diskussion mit Interesse verfolgt. 

Dann wird man sich wohl vorerst mit dem derzeitigen Workflow abfinden müssen.