![]() |
Windows message queue - Limit erreicht?
Moin !
Wir haben einen USB Logger den wir auslesen. Dieser Logger sendet nach einem Kommando einen Block an Daten (~40.000 Telegramme á 57 Byte). Also komponente verwenden wir NrComm (HID) - aber das spielt hier eh keine wichtige Rolle. Die Daten werdenfolgendermassen empfangen:
Delphi-Quellcode:
Und so ausgewertet:
procedure TForm1.HidAfterReceive(Com: TObject; Buffer: Pointer;
Received: Cardinal); var ByteData : AnsiString; i : integer; _msg : PHIDFeedback; begin Inc(HidCount); for i := 0 to Received - 1 do ByteData := ByteData + PAnsiChar(Buffer)[i]; New(_msg); _msg.Data := ByteData; _msg.HidCount := HidCount; PostMessage(self.Handle, WM_MY_HID_DATA, 0, Integer(_msg)); // Daten übergeben end;
Delphi-Quellcode:
Wir nutzen also Windows Messages um die Daten aus dem Empfangsthread in den Mainthread zur Auswertung zu bekommen.
procedure TForm1.DecodeHID(var Msg: TMessage);
var _msg : PHIDFeedback; begin _msg := nil; try _msg := PHIDFeedback(Msg.LParam); // hier passiert noch mehr ... memo1.Lines.Add('[' + IntToStr(_Msg.HidCount) + '] ' + string(_msg.Hex)); finally Dispose(_msg); // Pointer löschen end; end; Diese Technik hat bis dato immer super funktioniert. Aber nun ergeben sich mit einem neuen Logger Probleme. Wenn die Zahl der Telegramme zu gross wird (so ab > 30.000) dann gehen teilweise Telegramme verloren. Gibt es bei den windows Messages irgendwelche Grenzen die man nicht überschreiten darf? Hat die queue nur eine bestimmte maximale Länge? |
AW: Windows message queue - Limit erreicht?
Ich zitiere mal aus dem MSDN:
Zitat:
![]() Frage erledigt? |
AW: Windows message queue - Limit erreicht?
Ja Frage erledigt ... :cry:
|
AW: Windows message queue - Limit erreicht?
Ein Blick in
![]() Zitat:
[edit] da hat wer schneller geantwortet, als meine Leitung senden wollte :cry: [add] zu der For-Schleife sag ich mal Aua :shock:
Delphi-Quellcode:
PS: Wenn du/ihr noch etwas Zeit habt:
procedure TForm1.HidAfterReceive(Com: TObject; Buffer: Pointer;
Received: Cardinal); var ByteData : AnsiString; i : integer; _msg : PHIDFeedback; begin Inc(HidCount); New(_msg); SetLength(_msg.Data, Received); MoveMemory(@msg.Data[0], Buffer, Received); _msg.HidCount := HidCount; PostMessage(self.Handle, WM_MY_HID_DATA, 0, Integer(_msg)); end; ![]() |
AW: Windows message queue - Limit erreicht?
Moin !
Zitat:
Aber das ist im Moment das kleinste Problem. Hast du nicht einen Tip wie ich die Daten vom Empfangsthread Resourcen schonender zum Mainthread bekomme ? |
AW: Windows message queue - Limit erreicht?
Der Speicher von _msg wird nicht wieder freigegeben.
Delphi-Quellcode:
New(_msg);
_msg.Data := ByteData; _msg.HidCount := HidCount; PostMessage(self.Handle, WM_MY_HID_DATA, 0, Integer(_msg)); // Daten übergeben |
AW: Windows message queue - Limit erreicht?
Moin !
Zitat:
|
AW: Windows message queue - Limit erreicht?
Lokale Variablen verlieren ihre Gültigkeit beim Verlassen der Routine. _msg aus HidAfterReceive ist in Decode-Dingsbums unbekannt. Zu mal du in Decode-Dingsbums _msg auch deklariert hast. Das sind zwei unterschiedliche Variablen, auch wenn sie gleich heißen.
|
AW: Windows message queue - Limit erreicht?
Du könntest ja auf eine andere/größere Queue/Liste ausweichen?
Delphi-Quellcode:
Statt Record, CS und gen. Queue könnte man auch TThreadList mit Objekten nutzen.
uses SyncObjs, Generics.Collections;
var QueueCS: TCriticalSection; Queue: TQueue<THIDFeedback>; var Temp: THIDFeedback; begin // hid-thread SetLength(Temp.Data, Received); MoveMemory(@Temp.Data[0], Buffer, Received); Temp.HidCount := HidCount; QueueCS.Enter; try Queue.Enqueue(Temp); finally QueueCS.Leave; end; // mainthread QueueCS.Enter; try Found := Queue.Count > 0; if Found then Temp := Queue.Dequeue; finally QueueCS.Leave; end; if Found then begin // temp auswerten end; |
AW: Windows message queue - Limit erreicht?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:27 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz