EndOfFile/EndOfData bei Pipe erkennen

[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.

[sparky]

Für unseren Anwendungsfall habe ich als "Singleton-Pattern" einen modalen Dialog , und wenn der (nach einem Timeout) wieder geschlossen wird gibts auch keine Raw-Input Nachrichten / Registrierung mehr. Funktioniert besser als gedacht.
Danke für die zusammenarbeit

Übrigens: Ich würde gerne den HID-Controller aus deiner WiiHID Lib zum ermitteln aller angeschlossenen HID-Geräte verwenden. Ist das Ok, da es sich um eine kommerzielle Verwendung handelt?

[himitsu]

Is OK, ich werd' da die nächsten Tage noch das RAW-Input einbauen, den nicht richtig funktionierenden Timer ausbauen und dann wird das Ganze vermutlich wieder unter 'ner passenden Multilizenz veröffentlicht, welche das erlauben müßte.

Zitat:

MPL v1.1 , GPL v3.0 or LGPL v3.0

Und ich bedanke mich dann auch schonmal.



Muß mir jetzt nur noch überlegen, wie ich das HID und RawInput am Besten verbinde, also wie möglichst optimal die RawInputs an die entsprechenden registrierten HID-Klassen weitergeleitet/zugeordnet werden können.

Und wie/ob ich ein Win7-Problem beseitige, denn mein WiiControler wird von GetRawInputDeviceList doppelt gefunden, also mit zwei verschiedenen Handles (hDevice) und es kommen alle Reports doppelt rein.
(mal sehn ob ich sie dann einfach doppelt verarbeite oder ob/wie man die Doppelten ignorieren kann)