Hallo zusammen,
ich habe mehrere Apps am Laufen die über TCP/IP Verbindungen aufbauen
und bei Form1OnClose abbauen sollten.
Bei allen Apps die auf Windowsserver laufen bleibt aber immer auf der Gegenseite
(sind Maschinensteuerungen, SPS) die Verbindung hängen. Ein Connect tut dann nicht mehr.
Wenn ich die Software mit Click aufs Kreuzchen zumache, wird sauber abgebaut nur wenn wir
ein Windows Zwangsupdate ungeplant mit nachfolgendem Neustart bekommen, hab ich den
Eindruck, das OnClose nicht durchlaufen wird. Also irgendwie so was wie Steckerziehen.
Gibt es einen Unterschied zwischen Win10 Pro und Server2019?
Oder muß ich ein anderes OnClose (oder sonstwas) verwenden? OnCloseQuery hab ich erfolglos
schon getestet
irgendwelche Ideen oder Vorschläge?
wäre ich sehr dankbar
Gruß
NoCee
Problem mit OnClose
Re: Problem mit OnClose
Schon mal sowas probiert?
Code: Alles auswählen
Application.OnQueryEndSession:=@ApplicationQueryEndSession;
procedure TForm1.ApplicationQueryEndSession(var Cancel: Boolean);
begin
//Blah
end;
- af0815
- Lazarusforum e. V.
- Beiträge: 6770
- Registriert: So 7. Jan 2007, 10:20
- OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
- CPU-Target: 32Bit (64Bit)
- Wohnort: Burgenland
- Kontaktdaten:
Re: Problem mit OnClose
Ich lasse mir mit Debugln das ausgeben, damit weis ich mal das die Routine durchlaufen wurde. Bei allen was mit Sockets, Threads etc. zusammenhängt, ist meiner Erfahrung auch etwas Zeit notwendig, das die Kommunikation (meist über interne Threads) abgebaut wird. Killt man die Prozesse zu schnell, kann sein, das die andere Seite das nicht mitbekommt.
Mit fällt das ins besonders bei Kommunikation mit S7 Protokoll auf. Da habe ich mir auch die internas etwas herausgesucht. Da wird mit Threads gearbeitet, die ein Terminate bekommen, das braucht aber zumindest eine Kommunikation oder Timeout um richtig zu beenden und alles sauber zu schliessen. Mache ich im Destroy der Forms einfach ein Free und schliesse das Prgramm, kann das nicht funktionieren und es wird vom System zwangsweise zusammengeräumt, das kann der Partner übel nehmen. Dann geht für ein längeres Timeout mal keine weitere Kommunikation. Das ist allerdings nicht wirklich gut zu durchschauen. Wenn man durch das Destroy mit dem Debugger durchsteppt und es geht, im Betrieb ohne Debugger aber nicht, so würde ich darauf tippen.
Mit fällt das ins besonders bei Kommunikation mit S7 Protokoll auf. Da habe ich mir auch die internas etwas herausgesucht. Da wird mit Threads gearbeitet, die ein Terminate bekommen, das braucht aber zumindest eine Kommunikation oder Timeout um richtig zu beenden und alles sauber zu schliessen. Mache ich im Destroy der Forms einfach ein Free und schliesse das Prgramm, kann das nicht funktionieren und es wird vom System zwangsweise zusammengeräumt, das kann der Partner übel nehmen. Dann geht für ein längeres Timeout mal keine weitere Kommunikation. Das ist allerdings nicht wirklich gut zu durchschauen. Wenn man durch das Destroy mit dem Debugger durchsteppt und es geht, im Betrieb ohne Debugger aber nicht, so würde ich darauf tippen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).