EndOfFile/EndOfData bei Pipe erkennen

[sparky]

Sorry, dass es etwas gedauert hat...

Das Projekt ist bei uns erstmal wieder auf Eis gelegt worden andere Sachen haben Vorrang.

Ich werde aber morgen mal die Beispiel-Quellen zu dem was ich schon rausgefunden habe hier posten.

Soviel schonmal vorab:

WM_INPUT Messages kommen an , aber dafür immer von allen Devices die den gewählten TLC-Kriterien entsprechen
Man muss also die eingehenden Messages nach ihrem Device-Handle filtern, die Zuordnung des Device-Handle zu den HID Geräten ist möglich aber ein bischen umständlich.
Das "schlechte" ist, dass man die Input-Messages nur bekommt wenn die Anwendung aktiv ist (also den Focus hat), was ich für unsere Barcode-Scanner Geschichte eigentlich vermeiden wollte.

[himitsu]

Theoretisch sollte da RIDEV_INPUTSINK helfen.

Zitat:

If set, this enables the caller to receive the input even when the caller is not in the foreground. Note that hwndTarget must be specified.

Wäre zumindestens gut, da ich es ja über einen Service, bzw. über ein Hintergrundprogramm lösen wollte.

[sparky]

Die Verwendung von RIDEV_INPUTSINK funktioniert zwar, betrifft aber wieder alle Devices die den TLC-Kriterien von RegisterRawInputDevices entsprechen. Bei einem Barcode-Scanner mit Tastatur HID also auch die normale Tastatur... und so ein Verhalten würde mit Sicherheit auf Anwenderseite für Verwirrung sorgen

Wäre aber noch zu verkraften, wenn man wenigstens die Registrierung der Devices nach der Übertragung wieder aufheben könnte (zur Info: die Barcodes werden offline gescannt und anschließend in einer separaten Programmmaske als Batch vom Benutzer übertragen)

Na mal schauen ob mir da noch was einfällt

[himitsu]

Cool, es geht (WinXP).
Jetzt muß ich nur noch rausfinden, warum es bei mir nicht ging.

Zitat von sparky:

Wäre aber noch zu verkraften, wenn man wenigstens die Registrierung der Devices nach der Übertragung wieder aufheben könnte

Die Registrierung bekommst'e über RIDEV_REMOVE wieder weg, falls du das meintest.

ansonsten:
- da ich diese "alte" JEDI Windows API nicht installiert hab, hab ich mir die entsprechenden Deklarationen erstmal mit reinkopiert
- den Empfang der WM_INPUT-Messages hab ich verändert
- und der Aufruf von RegisterRawInputDevices wurde angepaßt, falls man da mal mehr als nur einwas registriert

So, jetzt probier ich das ganze gleich nochmal unter Win7 aus.

[edit]
Win7 lief auch

[sparky]

Habe gerade festgestellt, dass bei RIDEV_INPUTSINK (ohne RIDEV_NOLEGACY) andere Anwendungen die Messages trotzdem noch erhalten - ich brauche also nur über das Device-Handle zu filtern was ich tatsächlich haben will, Super

Das Flag RIDEV_REMOVE war mir bekannt, ich hatte es aber wegen der Hinweise im MSDN Artikel zur RAWINPUTDEVICE Struktur (für RegisterRawInputDevices) noch nicht verwendet:

Zitat:

Remarks

If RIDEV_NOLEGACY is set for a mouse or a keyboard, the system does not generate any legacy message for that device for the application. For example, if the mouse TLC is set with RIDEV_NOLEGACY, WM_LBUTTONDOWN and related legacy mouse messages are not generated. Likewise, if the keyboard TLC is set with RIDEV_NOLEGACY, WM_KEYDOWN and related legacy keyboard messages are not generated.

If RIDEV_REMOVE is set and the hwndTarget member is not set to NULL, then parameter validation will fail.

Wenn ich es nicht total falsch verstanden habe, kann man dem System per RIDEV_REMOVE nur mitteilen, dass man keine Messages mehr für bestimmte TLCs haben möchte - aber eben nicht, dass man die Registrierung für ein bestimmtes hwndTarget komplett aufheben möchte...

mir fällt beim Schreiben gerade auf, dass das System wohl keinen Grund haben wird mir weiter Messages zu schicken, wenn ich alle registrierten TLCs wieder entferne. Ich denke mal Problem gelöst.

Danke für die Info, dass es auch unter Win7 funktioniert...

[himitsu]

Zitat von sparky:

aber eben nicht, dass man die Registrierung für ein bestimmtes hwndTarget komplett aufheben möchte...

Jupp, man kann es auf ein bestimmtest Fenster registrieren, aber nur für die komplette Anwendung deregistrieren.

[himitsu]

Was ich grade noch Wichtiges mitbekommen hab
und weswegen ich meiner HID-Klasse demnächst ein Singlepattern verpasse.

Es kann pro Anwendung immer nur ein Fenster für ein für ein Ereignis (UsagePage+Usage) gegistriert sein.

Und zwar immer das Letzte bekommt die Nachrichten.

Genaue Bezeichnungen haben vorrang vor ganzen Gruppen (RIDEV_PAGEONLY).
Wenn man also für ein Fenster eine ganze UsagePage reserviert und für ein Anderes nur einen bestimmten Bereich (UsagePage+Usage), dann ist bei der Gruppe dieser Bereich nicht enthalten.




Da ja pro Anwendung nun eh nur ein Fenster empfangen kann, ist es also nicht schlimm und auch irgendwie einleuchtend, warum man beim Deregistrieren kein Handle angeben muß/darf/braucht.