Entwickler-Ecke
Dateizugriff - Dateizugriffsproblem...
FriFra - Fr 04.07.03 20:17
Titel: Dateizugriffsproblem...
Ich habe 2 Programme wovon eins jede Sekunde ein jpg-Bild speichert. Das 2. Programm liest dieses Bild jede Sekunde neu ein...
Dieses "Spiel" läuft auch für einige Zeit wunderbar, allerdings passiert es früher oder später immer, dass Programm 1 die Datei nicht speichern kann, weil Programm 2 gerade am lesen ist...
Damit keine Exception angezeigt wird ist der Schreibvorgang in einem try except-Block und es gibt eine globale Fehlerbehandlung (Application.onException). Mein problem ist nun, dass Programm 1 nach der Exception aufhört die Datei zu schreiben obwohl es sonst noch normal reagiert.
Wie kann ich es hinbekommen ohne Zugriffsprobleme zu haben?
Delete - Fr 04.07.03 22:06
Umgekehrt. Pack das Lesen in einen try-execept Block. Elegenter wäre es allerdings, wenn das erste Programm dem zweiten eien Message schickt, wenn es fertig mit shcreiben ist. Kann man eventuell mit WM_COPYDATA lösen.
FriFra - Sa 05.07.03 00:41
Sicher wäre es eleganter.... nur wenn das 2. Programm gerade "beschäftigt" ist, hängt das erste Programm solange bis die Message durch ist! Um genau dieses hängen zu verhindern schreibe ich die Datei.. Es ist mir auch egal, wenn Programm 2 mal ein Bild verpasst...
P.S.: Ich habe sowohl das lesen, als auch das schreiben in try except blöcken... bringt aber nicht viel, da man damit nicht verhindern kann, dass Programm 1 versucht zu schreiben wärend Programm2 gerade liest... Übrigens bringt auch ein "writing" Flag in der Registry nichts, da TRegistry selbst im reinen Lesezugriff eine Exception auslöst wenn gerade von anderer Stelle aus in den zu lesenden Wert geschrieben wird...
Delete - Sa 05.07.03 00:47
Das muß doch gehen. Wenn das erste Programm fertig geschrieben hat, dann schicke es eine Nachricht an das zweite. Das zweite wartet so lange bis die Nachricht angekommen und erst dann fängt es an zu lesen.
Mit der Nachricht setzt du im zweiten Programm eine Variable auf TRUE und das zweite Programm kuckt in einer Schleife so lange bis diese TRUE gesetzt ist. Das Nachkucken mußt du in einem Thread machen, da das zweite Programm ja gleichzeitig den Wert der Variablen überprüfen muß und die Message empfangen muß. Hat es die Nachricht empfangen und wurde die Variable auf TRUE gesetzt, setzt das zweite Programm diese sofort wieder zurück, damit sie vom ersten programm wieder auf TRUE gesetzt werden kann für das nächste Bild.
FriFra - Sa 05.07.03 01:07
Es kann aber sein (und es ist auch so), dass das 2. Programm gerade beschäftigt ist wenn Programm 1 ihm eine Message sendet... dann würde Programm 1 hängen... Es geht also NICHT mit Messages.
Delete - Sa 05.07.03 02:50
Warum sollte das erste Programm hängen? Schick mit PostMessage und gut ist. dann kann das erste Programm doch schon wieder schreiben.
FriFra - So 06.07.03 00:26
| Luckie hat folgendes geschrieben: |
| Warum sollte das erste Programm hängen? Schick mit PostMessage und gut ist. dann kann das erste Programm doch schon wieder schreiben. |
Ich weiss allerdings nicht, wie ich gepostete Messages bemerken und verarbeiten kann... Auf jeden Fall bemerkt die Funktion, welche die mit SendMessage gesendeten Nachrichten empfängt keine geposteten Messages...
Zum diesem Thema hatte ich vor ein paar Tagen schonmal einen Thread, allerdings ohne brauchbare Antwort. Das Ergebnis war, "bei PostMessage hängt zwar der Sender nicht, aber der Empfänger bekommt es nicht mit".
Gibt es irgendwo ein funktionierendes Beispiel für PostMessage? Ich arbeite bisher auch schon sehr viel mit Messages aber nur SendMessage oder SendMessageTimeout...
Delete - So 06.07.03 01:15
Das erstes Programm weiß doch, dass die Nachricht geschickt wurde. Nämlich nach der Zeile Postmessage(....). Desweiteren muß das erste Programm doch das gar nicht wissen. Das zweite Programm muß sich ja nach dem ersten richten. Es ist also nur wichtig, dass das zweite Programm sie empfängt.
FriFra - So 06.07.03 09:51
richtig, aber wie empfange ich eine gepostete Message? Wie gesagt, ich habe schon eine Funktion zur Verarbeitung eingehender Messages (aus FAQ), diese reagiert aber nur auf mit SendMessage gesendete Messages...
Ein Beispielcode zum Empfangen wäre nicht schlecht :roll: ...
Was passiert eigentlich, wenn Programm2 viel langsamer mit der Verarbeitung ist als Programm1 mit dem Posten... landen die Messages dann in einer Art Messageque?? Wenn ja hiesse das dann nicht, das dem Rechner ziemlich schnell die Resourcen ausgingen und der Stream immer mehr "gedehnt" würde?
patrick - Do 10.07.03 09:30
die empfangsfunktion im 2.programm würd ich in einen thread auslagern, so kann man auch daten empfangen, während die eigendliche hauptroutine weiterläuft.
zur datensyncronisation würd ich MMFs verwenden.
O'rallY - Do 10.07.03 14:10
Es gibt bei VCL zwei Möglichkeiten eine Nachricht zu verarbeiten:
- Du schreibst hinter eine Prozedurdeklaration die message messageid oder du machst es über das Event OnMessage von TApplication (ist nicht im Objektinspektor zu finden, musst du im Codeeditor zuweisen). Dort wertest du dann das Parameter aus et voilà.
FriFra - Do 10.07.03 14:16
Aber OnMessage funktioniert nur bei mit sendMessage gesendeten Messages... wenn ich eine Message über PostMessage sende kommt nichts bei der Zielanwendung an, bzw. OnMessage reagiert nicht drauf...
O'rallY - Fr 11.07.03 14:45
Das wäre mir allerdings neu... wenn dies tatsächlich der Fall sein sollte, musst du irgendwas falsch machen :? .
FriFra - Fr 11.07.03 21:38
Also meine Nachrichten empfange ich so:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
| procedure WMCopyData(var Msg: TWMCopyData); message WM_COPYDATA;
...
procedure TMain.WMCopyData(var Msg: TWMCopyData);
var
sText: array[0..255] of Char;
begin
IsWMCopyData := True;
StrLCopy(sText, Msg.CopyDataStruct.lpData, Msg.CopyDataStruct.cbData);
if sText = 'MeineMessage' then
begin
end;
end; |
Das funktioniert mit Sendmessage wunderbar und absolut fehlerfrei... nur bei Postmessage kommt nichts an...
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!