Nach Timer.Enable killt sich das Programm

[Blup]

Ist madExcept auch richtig installiert und in die Anwendung eingebunden?
Erzeuge zum Test mal eine Exception in deiner Methode und schau ob und wie diese gemeldet wird.

raise Exception.Create('Test');

[Rupert]

Natürlich wurde MadExcept richtig installiert und auch zuvor getestet
Aufgrund der unterschiedlichen Meinungen zu diesem Problem bin ich mir aber ziemlich sicher, dass es kein Programmfehler ist.

Zitat:

date/time : 2021-09-07, 17:43:07, 294ms
computer name : HEIZ-PC
user name : Erhitzer <admin>
registered owner : Erhitzer
operating system : Windows XP Service Pack 3 build 2600
system language : German
system up time : 32 minutes 17 seconds
program up time : 3 seconds
physical memory : 499/767 MB (free/total)
free disk space : (C 26,74 GB
display mode : 1280x1024, 32 bit
process id : $24c
allocated memory : 31,95 MB
largest free block : 1,28 GB
executable : Heizung2020.exe
exec. date/time : 2021-09-07 17:38
version : 11.0.1.1
compiled with : Delphi 5
madExcept version : 4.0.21
contact name : Rupert
contact email : [e-mail]
callstack crc : $9f487409, $90a79116, $90a79116
exception number : 1
exception class : EABSException
exception message : Cannot open file:'C:\Programme\Heizungsregelung\Datenbank\Heiz daten.abs' Error code: 32. ErrorMessage: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird - Native error: 30364.

[CCRDude]

Die Meldung sagt ja aber schon, dass es ein eindeutig Programmfehler ist

Da wird der mögliche Fehlerfall, dass die Datei anderweitig geöffnet ist, nicht behandelt.

Wenn es immer die gleiche Zeit ist: findet zu dieser Zeit evtl. ein Backup statt? Es gibt ja durchaus berechtigte Interessen dritter Programme bzw. des Betriebssystems - sei es ein Backup, ein gründlicher AV-Scan, ... .

Da muss man dann schauen, ob man die Datei dauerhaft offen hält (und auf teilweise sinnvollen Fremdzugriff wie eben ein Backup verzichtet), oder ob man den Fehlerfall behandelt (was man so oder so muss, da die Datei auch schon beim ersten Öffnen anderweitig gesperrt sein kann).

[Rupert]

Zitat von CCRDude:

Die Meldung sagt ja aber schon, dass es ein eindeutig Programmfehler ist

Da wird der mögliche Fehlerfall, dass die Datei anderweitig geöffnet ist, nicht behandelt.

Wenn es immer die gleiche Zeit ist: findet zu dieser Zeit evtl. ein Backup statt? Es gibt ja durchaus berechtigte Interessen dritter Programme bzw. des Betriebssystems - sei es ein Backup, ein gründlicher AV-Scan, ... .

Da muss man dann schauen, ob man die Datei dauerhaft offen hält (und auf teilweise sinnvollen Fremdzugriff wie eben ein Backup verzichtet), oder ob man den Fehlerfall behandelt (was man so oder so muss, da die Datei auch schon beim ersten Öffnen anderweitig gesperrt sein kann).

Dieser Dateifehler wurde von mir provoziert, um MadExcept zu testen.
Suf duesem Computer läuft nichts. Kein Backup, kein Virenscanner.

[Blup]

Timer werden in fast jeder Anwendung verwendet.
Kommentiere doch mal alles was mit deiner Steuerung zu tun hat aus.
Dann lass das Programm laufen und schau ob der Fehler noch auftritt.

[Rupert]

Zitat von Blup:

Kommentiere doch mal alles was mit deiner Steuerung zu tun hat aus.

Du meinst das Lesen von und die Ausgabe auf die Steuerkarte.
Das wird diese Woche nicht mehr gehen, aber ab Montag kann ich das probieren.
Danke!

[CCRDude]

[QUOTE=Rupert;1494313]

Zitat von CCRDude:

Suf duesem Computer läuft nichts. Kein Backup, kein Virenscanner.

Du hast also bewusst den Windows Defender, VSS und weitere Systemdienste deaktiviert? Ist zwar noch ein XP, trotzdem schon ein Multitasking-Betriebssystem.

Zitat von Blup:

Timer werden in fast jeder Anwendung verwendet.

Timer verwende ich auch gelegentlich, aber nicht nicht in diesem Kontext. Für wiederkehrendes Daten-I/O wie hier verwendet man eher Threads als Timer. Kaum etwas ist nerviger als nicht reagierende UIs, weil der Entwickler Last im Hauptthread erzeugt.

"Timen" kann man dann immer noch mit WaitForSingleObject mit definiertem Timeout auf ein Terminate-Event, um die Schleife im Falle des Programmschließens sofort zu beenden.

Ansonsten, um einen Mehrfachaufruf der Timer-Methode wirklich zu verhindern: mit TCriticalSection wrappen, dann kann er nicht nochmal rein, bevor er raus ist.

Ansonsten hilft es manchmal auch schon, die Logik nicht in der Timer-Methode zu haben, sondern von dort per PostMessage an eine andere Methode die eigentliche Ausführung zu triggern.

[venice2]

Hatte ich ebenfalls drauf hingewiesen
Ob er das in Betracht zieht mag mal dahin gestellt sein.

[Blup]

TCriticalsection hält nur andere Threads davon ab den selben Codeblock aufzurufen.
Innerhalb eines Threads ist der Mehrfachaufruf möglich, deshalb ist das hier keine Option.
Dafür reicht eine Variable, wie oben von mir vorgeschlagen.

Normalerweise würde man eine Steuerung die Tag und Nacht läuft auch nicht auf dem PC implementieren.
Dafür ist zum Beispiel Arduino besser geignet: https://de.wikipedia.org/wiki/Arduino_(Plattform)
Der PC oder das Smartfone zeigt dann im einfachsten Fall nur die Webseite des Controllers an, über die man das Programm steuert.

[CCRDude]

Zitat von Blup:

Innerhalb eines Threads ist der Mehrfachaufruf möglich, deshalb ist das hier keine Option.
Dafür reicht eine Variable, wie oben von mir vorgeschlagen.

Du hast recht!

In diesem Kontext eine Zwischenfrage: verwendet das Programm zufälligerweise Application.ProcessMessages? Das wird ja gerne mal reingehauen, wenn man den UI-Thread viel arbeiten lässt, und hat bei mir schnell dahingerotzten Timerdingern auch schonmal was kaputtgemacht, bevor ich gelernt habe, die Finger davon zu lassen. Deswegen ja auch der Tipp, die eigentliche Funktionalität per PostMessage in ner anderen Methode zu triggern, um aus dem Kontext dieser vom Timer aufgerufenen Methode rauszukommen.

Zitat von Blup:

Normalerweise würde man eine Steuerung die Tag und Nacht läuft auch nicht auf dem PC implementieren.

Aber schau mal am Anfang, wie alt das ganze ist. 1997 gab es noch keinen Arduino. Ein Hutschienen-PC mit Goldcap statt Batterie und EEPROM war's da eher... wobei das dann TP statt Delphi noch gewesen wäre.