Die Vermutung hat sich bestätigt. Gleich kommt ein neuer Snapshot. Timo, kannst du den kurzfristig testen?
Build 549 ist oben. Ich würde gerne wissen, ob das mit dem DTR jetzt wieder funktioniert - die eine oder die andere Methode.
Das Problem war übrigens, dass nach dem “ComPort(0).Open” der Port sofort wieder geschlossen wurde. Reference-counting sei dank.
Funktioniert soweit bis auf Problem:
Bei Klick auf PFL in der Playlist wird zwar PFL gesetzt, aber nach dem Beenden nicht mehr zurückgesetzt.
Bei Klick auf einen Player klappt das…wenn allerdings einmal PFL in der Playlist gemacht wurde,
muss mAirList beendet werden, um DTR wieder zurückzusetzen…
Fehler gefunden. Build 550 hochgeladen.
Jetzt hätte ich noch gerne eine Rückmeldung von Dominique, was mit der Systemlast ist. Vielleicht gab es da einen Zusammhang. Ansonsten ist Version 3.0.2 damit fertig, würde ich sagen.
Dein Wunsch ist mir Befehl… 
Keine Auffälligkeiten mit dem aktuellen Snapshot. Aber noch was anderes: in meinem Script werden die beiden ComPort().SendStr()-Befehle bei mAirList Start und Ende nicht ausgeführt, hast du eine Erklärung dafür? Ich glaube ich hatte diesbezüglich auch schonmal einen Thread aufgemacht…
Gruß
Dominique Görsch
OnStartup und OnShutdown, ja? Muss ich mir angucken.
Nur die ComPort-Befehle, oder wird da gar nichts drin ausgeführt? SystemLog oder so? Zumindest beim OnStartup sollte man ja was erkennen 
Öhm… das hab ich noch garnicht getestet. Was kann man da mal zum schnellen Testen eintragen? Sowas wie msgbox() oder alert() gibts nicht, oder? (Wär übrigens ein “nice to have”, Interaktion mit Scripten…).
//EDIT: Habe nun mal ein SystemLog(‘Foobar’); eingetragen, da passiert nichts.
Im Prinzip ist das möglich. Es lassen sich sogar eigene Dialoge gestalten. Alles möglich mit Pascal Script. Das Problem ist allerdings, dass die Scripts dafür im Haupt-Thread laufen müssen - und das ist nicht gewährleistet. Im Gegenteil, ich versuche gerade, möglichst viele Scriptaufrufe in einen Hintergrundthread zu verschieben.
Den Fehler mit OnStartup und OnShutdown kann ich reproduzieren. Ich kümmere mich um die Behebung.
Super, danke. Zum Thema Scripting… kann nur der Hauptthread mit der GUI kommunizieren? Bei irgendwelchen generierten Dialogen wäre es natürlich schon wichtig, dass sie “non-blocking” sind, also auf keinen Fall den Programmablauf stören/beeinträchtigen oder gar anhalten.
Gruß
Dominique Görsch
So war etwas unterwegs und konnte erst jetzt testen…
Playlist PFL setzt beim Beenden DTR noch nicht zurück, Flanke bleibt bestehen. Sobald ich einen Player in den PFL schicke und wieder zurück, wird es wieder zurückgesetzt.
BTW kann es sein, daß im PFL die Tempo und Pitchfunkion nicht mehr geht? Ich verschiebe die Regler und auch die Werte ändern sich nicht…in der COnfig habe ich es aktiviert…
Komisch, bei mir ging es. Kannst du mal einen SystemLog-Befehl in das OnPFLOff einbauen und schauen, ob es überhaupt aufgerufen wird?
Wegen Tempo und Pitch muss ich gucken, hab ich lange nicht mehr benutzt.
Ja. Die VCL (die GUI-Library von Delphi) ist nicht threadsafe.
Dominique, Build 551 ist nun oben. Da müsste das OnStartup und OnShutdown wieder gehen.
Timo, kommt bei dir auch eine Access-Violation-Meldung im System Log, wenn du das Extra-PFL beendest?
Ich weiß, woran das liegt. Muss mir noch eine Lösung überlegen.
In der Statuszeile kommt in der Tat eine Access violation…
Sorry, war grad mal ein bissl TV schauen.
Funktioniert bestens, Danke.
Gruß
Dominique Görsch
Ich weiß schon, woran es liegt. Ist leider etwas schwierig zu lösen. Das Problem ist, dass in dem Moment, wo die PFLOff-Nachricht vom Script verarbeitet wird, der Player schon längst geschlossen und aus dem Speicher gelöscht ist. Das bringt die asynchrone Verarbeitung der Meldungen so mit sich.
Ich schlafe eine Nacht drüber und überlege mir was.
So, ich habe eine Lösung gefunden. Build 552 liegt bereit.
Achtung, es ergibt sich eine Änderung:
In allen Notification-Script-Prozeduren, die etwas mit einem Player zu tun haben (also OnPlayerStart, OnPFLOn, etc.) entfällt ab sofort der Parameter “Item”. Bitte die Scripts entsprechend anpassen: “Item: IPlaylistItem;” aus der Parameterliste löschen.
Außerdem kann es nun vorkommen, dass der Parameter “PlayerControl” leer ist, also nil. Das ist dann der Fall, wenn der Player inzwischen geschlossen wurde, also insbesondere der PFL-Player im Eigenschaften-Dialog. Wer also auf das Item zugreifen muss, sollte erst überprüfen, ob PlayerControl <> nil ist, und dann PlayerControl.GetItem abfragen.
Morgen Torben,
wo du grad dabei bist, dort was zu ändern…
[ul][]Ist es viel Aufwand den entsprechenden Events (OnPlayerStart/-Stop) den betroffenen Player als Parameter mitzugeben?
[]Liesse sich etwas wie OnPlayerLoad/-Unload einrichten?[/ul]
Gruß
Dominique Görsch
-
Bei Start/Stop ist der Player-Parameter mit dabei. Aber wie gesagt, bitte vorher auf nil testen.
-
Wegen Load/Unload: Würde es auch ein “StateChanged” tun? Dann kannst du gucken, ob der neue Status “pcLoaded” oder “pcEmpty” ist.