EndOfFile/EndOfData bei Pipe erkennen

[himitsu]

Wenn man mit ReadFile von einer Communications-Resource ließt und es keine/nicht genug Daten gibt, dann schläft der Thread ein, da die Funktion ja wartet, bis genug Daten gelesen wurden.

Kann man also vor dem ReadFile erkennen, ob etwas/genug zum Lesen vorhanden ist?

SetFilePointer liefert hier ja immer 0 und GetFileSize arbeitet eh nicht
und SetCommTimeouts hat leider keine Wirkung.

Klar gäbe es noch andere Wege:
- asynchrones Lesen mit Timeout
- auslagern in einen Thread und die Daten via Callback rüberschicken, wenn was vorhanden ist
- k.A. was sonst noch

Aber ich würde gern direkt auslesen (also kein Thread) und mir wäre es lieb, wenn ich sofort erfahren würde, ob was vorhanden ist (also kein Timeout abwarten).

[sparky]

Wenn es sich tatsächlich um eine named/unnamed Pipe handelt, empfiehlt sich die WinAPI Funktion PeekNamedPipe.

Code:

if not PeekNamedPipe(LHandle, nil, 0, nil, @LBytesAvail, nil) then
  RaiseLastOSError;

Die Funktion ist nicht blockend (d.h. kein Thread erforderlich) und liefert mit dem obigen Aufruf die Anzahl der verfügbaren Bytes.

Mehr unter http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

[himitsu]

Nee, geht leider auch nicht

Zitat:

Unzulõssige Funktion

Dennoch danke und willkommen an Board.



Also derzeit scheint es halbwegs gute Ergebnisse über ReadFileEx + SleepEx als TimeOut zu geben.
Ich denke mal ich werde dieses ausbauen und bei einem TimeOut einige nachfolgende Leseoperationen überspringen (einfach behaupten es gäbe keine Daten), bevor erneut gelesen wird, um den Zeitverlust durch den TimeOut zu kompensieren.


Nja, als was dieses genau läuft, weiß ich auch nicht, es ist jedenfalls keine Datei.

Es handelt sich um ein Eingabegerät (HID):
'\\?\hid#vid_057e&pid_0306#2&32f7afb6&0&0000#{4d1e 55b2-f16f-11cf-88cb-001111000030}'

Na gut, ich versuch dann später mal mit dem ReadFileEx+SleepEx weiterzuprobieren.
Leider mußte ich so auch die Ausgabe asynchron gestalten, da ich eigentlich nur ein gemeinsames FileHandle verwenden wollte ... aber mal sehn.

[Luckie]

Zitat von himitsu:

Es handelt sich um ein Eingabegerät (HID):
'\\?\hid#vid_057e&pid_0306#2&32f7afb6&0&0000#{4d1e 55b2-f16f-11cf-88cb-001111000030}'

Ach das. Diese Bezeichnungen finde ich auch immer nur geil.

[himitsu]

Zitat von Luckie:

Zitat von himitsu:

Es handelt sich um ein Eingabegerät (HID):
'\\?\hid#vid_057e&pid_0306#2&32f7afb6&0&0000#{4d1e 55b2-f16f-11cf-88cb-001111000030}'

Ach das. Diese Bezeichnungen finde ich auch immer nur geil.

Von der Schnittstelle her ist es ja egal um was es genau geht.
Es ist einfach ein Gerät, welches über die Human Interface Device-Schnittstellen (HID) angesprochen wird.
Also wen interessiert es hier wirklich, ob es ein Wü-kompatibles-Eingabegerät ist?

PS: Es steht alles genau drin
- HID > die Schnittstelle
- vid_057e > die Vendor-ID $057E
- pid_0306 > die Product-ID $0306
= Wii-Controler via HID

[sparky]

Also wenn es sich um folgendes Gerät handelt:

HID\VID_057e&PID_0306
HID_DEVICE_SYSTEM_GAME
HID_DEVICE_UP:0001_U:0005
HID_DEVICE

Les Paul Controller for Nintende Wii Model No. 95125.805 (ok, hätte vor dem antworten mal schauen sollen, was schon geschrieben wurde)

könnte vielleicht das folgende Projekt interessant sein:

sourceforge - wiiuse (edit: besonders die Funktionen in io_win.c)

Ist zwar C-Code, aber relativ einfach gehalten und es geht ja im wesentlichen um die API-Aufrufe.
In dem Zusammenhang ist vielleicht auch noch folgender Bereich der MSDN-Library interssant:

Using Raw Input

[Dezipaitor]

Dafür ist doch das Overlapped Flag in Readfile da. Daraufhin dann ein WaitForMultipleObjects. Da kannst du dann nach dem Event von ReadFile und ein AbbruchEvent oder Timeout prüfen und das alles im aktuellen Thread.