Nur eine Programminstanz und Weitergabe der Datei an laufende Instanz

[mdo]

Hallo!
Ich habe ein kleines Problem und eine Lösung, welche wohl ein Overkill darstellen würde...

Problem:
Ich habe eine Art Winamp programmiert und als Standardprogramm für *.wav Dateien eingetragen. Klicke ich nun also auf eine *.wav Datei, so öffnet sich mein Player und spielt sie ab. Klicke ich nun aber auf eine Weitere *.wav Datei, so öffnet sich eine neue Instanz des Players... Da dies nicht der gewünschte Effekt ist, brauche ich Hilfe ^^



Gewünschter Effekt:
Die neu angeklickte Datei soll der Playlist angehängt werden.
Bsp:

MeineWave1.wav
MeineWave2.wav

1. Doppelklick auf MeineWave1.wav
2. Player1 öffnet sich mit MeineWave1.wav in der Playlist
3. Doppelklick auf MeineWave2.wav
4. Player1 added MeineWave2.wav zu der Playlist



Meine grundsätzlich funktionierende aber viel zu komplzierte Lösung:
Jeder Player lauscht auf einem Port auf localhost. Sobald ein Player gestartet wird, sendet dieser eine Statusabfrage mit einer (seiner) UniqueID über den Port. Der ältere Player empfängt diese Nachricht, erkennt dass es nicht seine ID ist und sendet dem neuen Player ein Statusflag und seine ID. Daraufhin gibt der neue Player die Datei (welche in den args steht) und einen AUfruf zum adden in die Playlist an den alten player weiter...
Bsp:

MeineWave1.wav
MeineWave2.wav

1. Doppelklick auf MeineWave1.wav
2. Player1 startet und beginnt den Port 666 abzuhören und sendet einmal auf dem Port 666 das Segment: #STATUS#Player1#
3. Player1 bekommt innerhalb des kurzen Timeouts (500ms) keine Antwort und geht davon aus, dass er alleine ist...
4. Player1 öffnet sich mit MeineWave1.wav in der Playlist
5. Doppelklick auf MeineWave2.wav
6. Player2 startet und beginnt den Port 666 abzuhören und sendet einmal auf dem Port 666 das Segment: #STATUS#Player2#
7. Player1 empfängt das Segment von Player2 und erkennt, dass es sich nicht um seine ID handelt.
8. Player1 sendet auf Port 666 das Segment: #ACK#Player1#
9. Player2 empfängt das ACK Segment mit der ID des lebenden Players und sendet zurück: #ADD_TO_PLAYLIST#C:\MeineWave2.wav#
10. Player2 beendet sich
11. Player1 added MeineWave2.wav zu der Playlist


Diese Vorgehensweise ist zu kompliziert und zu fehleranfällig... Hat jemand da eine bessere Idee?

EDIT:
Habe dazu ein nettes Snippet gefunden:

bool createdNew;

System.Threading.Mutex mutex = new System.Threading.Mutex(true, Application.ProductName, out createdNew);
if (createdNew) {
// bitte Form1 ersetzen
Application.Run(new Form1());
// und auch wieder Freigeben besser ist besser
mutex.ReleaseMutex();
} else {
MessageBox.Show("Programm wurde bereits gestartet!", "Info", MessageBoxButtons.OK, MessageBoxIcon.Error);
}

Allerdings ist hier die Weitergabe von MeineWave2.wav an die Playlist von Player1 nicht realisiert... Also müsste ich auch hier ein Gespräch der beiden Player über Ports realisieren...
Übrigens: Zielframework ist .NET 2.0!

 

[colblake]

Hallo mdo,

<nur sone Idee>

Du könntest dafür Named Pipes benutzen:
Wenn die Pipe nicht vorhanden ist, dann ist noch kein Programm von Dir gestartet -> Programm starten.
Wenn eine named Pipe vorhanden ist, dann schicke den Dateinamen der wav über die pipe zu dem "alten Programm".

</nur sone Idee>

Gruß
Col.Blake

 

[mdo]

Hallo colblake!

Ja, über named pipes habe ich auch schon nachgedacht, allerdings gibts da ein Problem und eine Unbekannte:

Problem:
Das Zielframework ist .NET 2.0. Also kein .NET Support für named Pipes... Daher müsste ich über dllImport alte Win32 API calls benutzen... Prinzipiell kein Thema, aber "unschön"... Gibts da keine bessere Alternatvie? Kann mir nicht vorstellen, dass .NET 2.0 derart arm in IPC DIngen bestückt ist...
Auf der anderen Seite habe ich selbst auch noch nichts weiter gefunden

Unbekannte:
Der Recorder soll citrixfähig sein... Ich weiß nicht, in wie fern dies mit den named Pipes zusammenspielt... Die laufen ja quasi alle auf der gleichen Maschine und doch in unterschiedlichen Sessions... Kommen die sich sessionübergreifend nicht in die Quere?

 

[colblake]

Hi mdo,

Problem:
Das Zielframework ist .NET 2.0. Also kein .NET Support für named Pipes... Daher müsste ich über dllImport alte Win32 API calls benutzen... Prinzipiell kein Thema, aber "unschön"... Gibts da keine bessere Alternatvie? Kann mir nicht vorstellen, dass .NET 2.0 derart arm in IPC DIngen bestückt ist...
Auf der anderen Seite habe ich selbst auch noch nichts weiter gefunden

Nun, ich habe das auch noch nicht mit .NET gemacht. Daher wusste ich nicht, dass es das im 2.0er nicht gibt. Man lernt nie aus.

Unbekannte:
Der Recorder soll citrixfähig sein... Ich weiß nicht, in wie fern dies mit den named Pipes zusammenspielt... Die laufen ja quasi alle auf der gleichen Maschine und doch in unterschiedlichen Sessions... Kommen die sich sessionübergreifend nicht in die Quere?

Da kann ich leider nix zu sagen. Von Citrix habe ich keinen Plan. Aber hast Du dann mit Deinem komplizierten Ansatz nich das gleiche Problem?

Gruß
Col.Blake

 

[mdo]

Stimmt natürlich...
Die Kommunikation über Ports hat genau die gleichen Probleme wie die Kommunikation über named Pipes. In jedem Fall brauch jede Instanz des Recorders/Players eine Unique ID welche übermittelt werden muss (bzw bei den Pipes wäre es der Name der Pipe). Von daher hast du recht...
Ich mach mir die Tage mal ausführlich Gedanken über die beiden Alternativen. Allerdings wäre ich für weitere Vorschläge dankbar, denn gefallen tun mir beide Varianten nicht sonderlich... Aber wenns sonst nix gibt, bleibt mir wohl keine andere Wahl...
Das schicke an der Portkommunikation ist, dass man so PC übergreifend die Player Kommunizieren lassen kann... Das schicke an named Pipes ist die Einbettung in Windows (nicht so fehleranfällig). Hm, schwere Entscheidung...