On 07.12.2012 13:12, Ian MacArthur wrote: > > On 7 Dec 2012, at 10:54, Albrecht Schlosser wrote: ... >> Are these only controllers that need to be built into a box >> or something, or do they come as "ready-to-go" devices? > > > Both, I think - though I'm not sure, and I still don't have the link that he > uses... > > He certainly had some bare boards a bit like this: > http://www.ultimarc.com/ipac1.html though that's not the actual part he uses. > This is just a bare controller though in this case, you need to add your own > switches and a box for this part.
Well, I looked somewhat closer at it and studied the manual, and it looks pretty good if it would come to producing an own box, i.e. if we can't find a better complete (keyboard-alike) device. Debouncing keys seems to be included, as well as alternate key codes with something like a "shift" key. Maybe more than we need. > I think this one can handle up to 56 buttons, which is maybe enough (in the > sense that it is probably more than a human operator can cope with anyway! At > least if they are not allowed to look!) Well, I asked again, and it looks as if there is a standard mode where looking at the keyboard should be avoided, but then about 16 buttons might be enough. More buttons/keys might be used for some special input, so that it could be acceptable to look at the keyboard/device in this case... > I suppose you could buy a few basic 3x4 or 4x4 keypads from RS and hook them > up to this controller, and have two switch groups, e.g. like... > http://uk.rs-online.com/web/p/keypads/0146222/ or something... We could probably do this, or let someone do it for us... > But what you really want is a dedicated keypad that already has all that in > one unit. Yup, if we can get such a thing > Which I know I have seen, but I can't find it now! still interested... >>> and come with a basic WinXX and Linux driver >> >> Win + Linux, that'd be more than I had hoped to find >> (of course you need Windows, but there might also be Linux >> users, and I'd like to support that too). > > Also, note that this driver is only needed to configure the keypad/controller > the first time, to "teach" it the strings for each key... You don't > distribute it with the hardware or anything. Yup, meanwhile I saw this following your link above: http://www.u-hid.com/home/index.php Seems appropriate, one board < 80$, but it has to be built into a case, and you need the buttons/keys/switches. But this or something similar could be "Plan B" ;-) >>> that allows you to program the device, such that it converts each key press >>> into a string - then in your code you catch the string and interpret it. >> >> That ought to work, although I'm a litte afraid of interference >> (races) with real keyboard actions (what if one presses a normal >> keyboard key while the "other keyboard" transmits its string?). > > Yes, good point, I don't know. I guess I imagine that the USB stack might > deliver the strings atomically? Well, probably not, but if it did that ought > to solve the problem! Might be true for a USB device, hopefully, <OT> but I had a bad experience with another (PS2) keyboard with a card reader for (German) health insurance cards. The reader was embedded in the keyboard, however it didn't send character (key) codes, but ALT-Key-Sequences, like ALT-0-6-5 for letter 'A', which consists of 8 (eight!) key events (down + up for each of the four keys). Hence, a string of ~ 100 characters took 13 seconds to transmit the entire string. Reliability = Null, especially if you take into account that a user could change the active window while the keyboard was sending. Even if the user didn't do it himself, there could be another popup window taking focus. We never used that thing, and later there were other dedicated USB card readers (with a better API). Thanks again for your help Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
