Hi Hagen,
vielen Dank für deinen Hinweis,
genau das "Synchronize" war ja auch das Deadlock Problem in der
DLL.
Du siehst am Code das ich
//Notify;
schon stehen hatte.
Ich werde noch FSyncMode dazu fügen.
Der Vorteil für mich ist "nicht nur", dass ich den TTimerThread nur mit
einer Zeile erzeuge
FTimerThread := TTimerThread.Create( Interval, Notify );
und auch nur mit einer wieder
FTimerThread.Stop;
freigebe.
Desweiteren verwende ich ihn auch um ein/mehrer (MuliMonitor) UI's jede Sekunde (+- 50ms)
FTimerThread := TTimerThread.Create( Notify );
zu updaten ( siehe FOneSec ).
In einem Programm laufen davon mehr als 10
- Unabhängige Hardware Connects ( Seriell )
- Unabhängige Hardware State Checks
- Unabhängige
IP Re/Connects Client seitig
- ...
ca. 10-20 Threads, noch nicht einmal die Hardware
Threads der Seriellen oder SaredMemory Kommunikation
dazu gerechnet. Es ist wirklich ein ganzer
"Batzen an TTimer nötig" ... und die kann man nun mal
nur Begrenzt verwenden, oder?
Jeder kann für sich entscheiden ob er
einen Thread anstelle eines TTimers verwendet.
Klar ist wohl auch jedem, dass ich in der
Anwendung alles Threadsicher halten muss.
Mit diesem Gedanken gehe ich seit D2 immer
an ein Projekt, es ist für mich einfacher
sofort CriticalSection's ( ob nun Global oder Local),
Mutex und ThreadList's zu arbeiten.
Schon wegen der nicht Synchron arbeitenden Hardware ( siehe oben )
und den multiplen Steuerungsmöglichkeiten.
z.B.
- Mehrfach Local als MultiMonitor
( mit eigenem TouchScreen Funktionen ohne System Treiber,
so das du eine Maske auf Screen 2 bedienen kannst und
parallel auf Screen 1 mit der Maus fuchtel kannst um
eine andere Maske zu bedienen )
- Mehrfach Dezentral im Netz
... und es Funktioniert!
Was immer noch offen ist:
Warum der Deadlock in einer
DLL wenn ich
Synchronize( FNotify );
verwende?
Vielen Dank noch einmal Hagen.
Für jeden Input dankbar! (No.5 lebt
)
mfg Rumpi No.5