Nur wenn ich beides deaktiviere im Destroy wird das Rendern in der anderen Anwendung weitergeführt.

markieren

Delphi-Quellcode:

    CancelWaitableTimer(VisTimer);
    CloseHandle(VisTimer);

Hmm.. Das kann es aber nicht sein Oder?
Welche alternativen bleiben mir dann noch?
Ich benötige einen WaitableTimer damit die Anwendungen bei aktionen die das Plugin betreffen
Konfiguration und so weiter nicht hängen bleibt.

Zitat:

Allerdings frage ich mich, ob es bei deinem Anwendungszweck überhaupt Sinn macht einen Namen für den Timer anzugeben. Warum machst du das? Denn viel sinnvoller wäre doch wohl mit unbenannten Timern unabhängig voneinander zu arbeiten, oder?

Und das könnte mein Probelm beheben ?
Wenn das so einfach ist probiere ich es doch gleich mal


gruss

Zitat von EWeiss:

Jo.. Ich schließe das Handle.

markieren

Delphi-Quellcode:

  if VisTimer <> 0 then
  begin
    if not Suspended then
      ThreadHalt;

    CancelWaitableTimer(VisTimer);
    CloseHandle(VisTimer);
  end;

Werde mal versuchen wie es sich verhält wenn ich auf CloseHandle verzichte.
Abgesehen von eventuellen Speicherlecks die dann wieder entstehen.

Damit lässt du genau das Falsche weg
CloseHandle zerstört den Timer nicht, wenn es noch andere Handles darauf gibt.
Aber: CancelWaitableTimer schaltet ihn auf inaktiv, sodass der andere Prozess nicht mehr signalisiert wird.

Die saubere Lösung wäre es, einen privaten Timer zu verwenden. Also entweder kein Name oder ein privater Namespace.

Zitat:

The object can be created in a private namespace. For more information, see Object Namespaces.

[MSDN]

// EDIT: Zu langsam Ich hab nur den Beitrag von EWeiss gesehen gehabt.

Zitat von EWeiss:

Und das könnte mein Probelm beheben ?
Wenn das so einfach ist probiere ich es doch gleich mal

nil statt einem Namen angeben, das funktioniert z.B. bei Pipes oder Events genauso.

WOW jo.. kann mich nur Herzlich bei euch bedanken das behebt einige diverse andere probleme.
Wußte nur nicht das hier einfach ein nil genügt um andere Anwendungen auszusperren.

Naja denke mal das wird auch anderen helfen die ähnliche probleme damit haben.

gruss

Jap, das meinte ich mit Shared Die Timer API scheint dann ähnlich wie CreateMutex() oder CreateEvent() zu arbeiten. Dort sind die "named" Varianten auch immer Shared im gesamten Benutzerkontext.

Zitat von Zacherl:

Jap, das meinte ich mit Shared Die Timer API scheint dann ähnlich wie CreateMutex() oder CreateEvent() zu arbeiten. Dort sind die "named" Varianten auch immer Shared im gesamten Benutzerkontext.

Danke .. Habe ich nicht gewußt

gruss