EndOfFile/EndOfData bei Pipe erkennen

[sparky]

Zitat:

Das Einzige, was ich mit der Verbindung zur Wii fand, das war http://blogs.yahoo.co.jp/mummykinoi/58265222.html , aber sehr hilfreich isses nicht unbedingt. (nicht daß ich es nicht verstehen würde, aber
mummykinoi weiß es auch nicht)

Öhhh - ja , mein japanisch is nich so toll... aber wenn ich es richtig interpretiere, erwähnt er auch nur, dass es die Funktionen gibt, oder?

Ich versuche gerade über die GetRawInput... Funktionen einen Barcode-Scanner mit HID Interface (Bluetooth/USB) anzubinden.
Allerdings muss ich heute erst noch ein anderes Projekt zur Abgabe bereit machen.
Melde mich nochmal, wenn ich weiss ob das mit der Raw Input Anbindung hinhaut.

Edit:

Zitat:

HidD_SetOutputReport liefert unter XP+BlueSoleil ERROR_NOT_SUPPORTED zurück.

Besteht die Möglichkeit unter XP einen alternativen Bluetooth-Stack zu verwenden (z.B. von Microsoft)?

[himitsu]

Er erwähnt, daß er erfahren hat, daß es dieses gibt, und fragt quasi ob/wie man dieses nutzen kann.

Zitat von Sein letzter Satz ist:

Kurz gesagt, überhaupt keinen Fortschritt.

Zitat:

Allerdings muss ich heute erst noch ein anderes Projekt zur Abgabe bereit machen.
Melde mich nochmal, wenn ich weiss ob das mit der Raw Input Anbindung hinhaut.

Keine Sorge, ich hab Zeit, dieses ist "nur" ein Füllprojekt, um mich von anderen Dingen etwas abzulenken (manchmal braucht man von einem anderem Projekt etwas Abstand, um da endlich wieder durchzusehn, weil man so weit drin steckt, daß man den Wald vor lauter Bäumen nicht mehr sieht)

Zitat:

HidD_SetOutputReport liefert unter XP+BlueSoleil ERROR_NOT_SUPPORTED zurück.

Dieses wiiuse arbeitet ähnlich, nut daß es erst WriteFile versucht und das nicht geht auf HidD_SetOutputReport ausweicht.
Sich dabei aber mehrkt, daß es nicht ging und dann beim nächsten Versuch direkt die andere Variante nutzt.
Das werde ich wohl so ähnlich übernehmen.

wiiuse nutzt dieses auch um BlueSoleil und WindowsBTStack zu unterscheiden (WriteFile=BlueSoleil, ansonsten WinBTStack).

Zitat:

Besteht die Möglichkeit unter XP einen alternativen Bluetooth-Stack zu verwenden (z.B. von Microsoft)?

Leider nein, unter WinXP ist der Windows-Bluetooth-Stack hierfür nicht nutzbar.
Der Controler wird einfach nicht verbunden, bzw. die Verbindung bricht nach wenigen Sekunden wieder zusammen/ab.
Da scheint sich erst seit Win7 oder eventuell Vista etwas verbessert zu haben.
Darum wird auch in fast allen Fällen, wo der WiiControler mit dem PC verbunden wird, auf BlueSoleil verwiesen.

Es gibt zwar inzwischen einen Treiber, welchen jemand Anfang des Jahres veröffentlich hat, aber ausprobiert hab ich den noch nicht und wenn wir es unter Win7 über dessen eigenen BTStack hinbekommen, dann ist dieser Treiber auch eher unnötig, vorallem da er eh nur für Win7 existiert.
http://www.codeproject.com/KB/system/wiisensor.aspx


Ach ja, was die Unterstützungen angeht, vom System her hab ich eh nur vor XP+ (notfalls auch erst ab Win7) zu unterstützen.
Älteres wird explizit nicht mehr unterstützt (entweder es läuft oder nicht).
Aktuell hab ich 2 APIs verwendet, welche es erst ab XP gibt.
Also alle Vorschläge für diese Versionen und älteres wird eh "ignoriert"

[sparky]

Kurzes Update zum Thema Raw Input:

Als wahre Fundgrube hat sich Jan Axelson's Lakeview Research herausgestellt, im Bereich Tools hat er 2 Programme zum Untersuchen von USB-HID Geräten (für die Angabe von UsagePage und Usage der
Top-Level Collection (TLC) zur Geräteauswahl) inkl. Quelltext für Delphi . Ausserdem ein Hinweis auf Robert Marquardt's HID Controller Component Suite für Delphi.

Erfolgsmeldung kommt (hoffentlich) morgen...

[himitsu]

Schau mir grade die Programmchen an

PS: Roberts HID-Zeugs ist auch in der JCL (JEDI) enthalten.

[himitsu]

Zitat von sparky:

Kurzes Update zum Thema Raw Input:

Bist du da weitergekommen?

Hatte gestern versucht dieses bei mir zu integrierren,
aber egal was ich bei RegisterRawInputDevices vesuche, es kommen keine WM_INPUT bei meiner Anwendung an.

Hab es mit den Werten (UsagePage=5, Usage=1) der TopLevelCollection des Devices versucht und auch mit den Werten (UsagePage=$FF00, Usage=1) von den InputButtons versucht.



Nja, immerhin läuft es jetzt endlich, auch wenn es nicht optimal ist, da leider die reinkommenden Daten ein bissl viel sind, bzw. nicht über den Timer optimal genug verarbeitet werden.

Hab jetzt die Anwendung auf 3 FileHandles umgestellt.
- 1x GENERIC_WRITE, für die Schreibzugriffe
- 1x GENERIC_READ + Overlappt, für die Lesezugriffe
- 1x DesiredAccess=0, für sonstige Zugriffe

Das Overlappt machte beim Schreiben leider enorme Probleme, so daß es manchmal angeblich erfollgreich war, selbst wenn das Device nicht angeschlossen war.
Ohne das Assynchrone konnte man nicht Lesend zugreifen, ohne den Thread hängen zu lassen.
Und da es nun eh schon 2 Handles gab, fliel das 3. Handle auch nicht weiter auf und so ist nun alles voneinander getrennt.

Nun wäre es noch sehr schön, wenn das mit dem RawInput klappt, da ich den Timer nicht zu schnell laufen lassen kann/will, da ich nicht durch Pollen das System zu sehr auslasten möchte.

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