I have a bar-code scanner with USB interface, so it appears as an HID.
There are reasons why I must breakpoint on the first character.
That brings my Delphi IDE to the front, it stops on the breakpoint and the rest of the bar-code is injected into my code as if it had been typed front the keyboard (which, in a way it has, as the USB scanner is just another HID).
Is there any way to avoid this? Or to add an initial check as to the source of the input?
It annoys me so much that I am now looking for a scanner with an RS232 interface.
The problem is that HID "devices" send information back to the computer in packets known as "reports".
In the case of a mag-swipe, or bar-code scanner, the "report" contains the entire number.
Which is to say, you don't receive reports character-by-character, but the entire string at once. (In the case of a mag-swipe, you will receive all two, or three, tracks in the same report).
So your code doesn't break "on the first character", it breaks "on the entire report". The fact that the remaining characters are there you can think of as a bonus (if you don't want to look at them you don't have to). But you won't be receiving any more "reports" for subsequent characters.
i cannot imagine any reason why you wouldn't want to know the bar-code at once. But most mag-swipe and bar-code scanners can be configured to emulate a keyboard, rather than a generic HID device. In that case you will receive multiple WM_KEYDOWN messages.
Related
Working with a Konica Minolta, I am sending PostScript commands to it. Most of the time everything works correctly and I am able to switch trays using the MediaPosition command. The printer has 4 trays and the Paper Tray Settings from the printer display are set to "Letterhead", "Letterhead", "Letterhead" and "Plain".
I am successfully switching between trays using this:
<</ManualFeed false /MediaPosition 0>> setpagedevice
One of the ps files creates a job which prints from the from the third tray, the forth tray and then tries print from the first tray. However, at this point the printer freezes and asks you to put "Plain" paper in Tray 1. I am assuming this happens because the last print came from a "Plain" paper tray but I am just guessing. Going from 3 to 4 works but then to 1 does not.
I have tried to use /MediaType (letterhead) but it seems that this command is ignored as it comes along with some settings of Duplex which are incompatible with it:
<</Duplex true /Tumble false>> setpagedevice
Any idea what is actually causing this problem and even more so, how to fix it so the printer continues without freezing and asking to change the tray paper setting?
I cannot see what this has to do with Ghostscript, where is Ghostscript used in the described process ?
Page device parameters are, to some extent, device dependent and are usually treated as requests. For example you can set /Duplex, and the device will generally ignore it if it does not have a duplexer. (ie the request is ignored).
However, certain page device requests can have other effects, these are documented in Section 6.2.7 Unsatisfied Parameter Requests of the 3rd Edition PostScript Language Reference Manual (p446 in my copy).
The interpreter can respond to such an unsatisfied parameter request in a variety
of ways, such as by ignoring it, raising a PostScript error, or displaying a message
on the front panel of the device requesting intervention by the human operator.
Without seeing the exact PostScript program, it's not possible to tell exactly what's going on, but I would guess that the interpreter thinks, for whatever reason, that it cannot satisfy the request for tray 1 because it's MediaType does not match (it wants Plain and you have defined it as Letterhead). It's likely that switching tray the way you are doing changes the current MediaType (or possibly some other parameter but MediaType makes sense). I imagine that initially the MediaType is not present in the dictionary, so you can change to any other tray. When you change the tray, because you've defined the media type on the control panel, it picks up the new MediaType. When you try to switch back the current MediaType doesn't match the MediaType of the tray you are trying to switch to.
Most likely the reason that adding /MediaType (letterhead) doesn't work is because you say you've defined the tray as containing Letterhead. PostScript is case-sensitive so letterhead is not the same as Letterhead.
Or it could be that the paper tray setting simply isn't the same as the MediaType. I'm afraid that this sort of device-dependency is highly specific to each manufacturer, the only people who can probably tell you what you need to send for certain are the printer manufacturers' own engineers.
We have a group of users who need to see the payloads of packets in wireshark captures. I'm looking for a way to remind them users that the data contained within may not represent the exact frames on the wire (because the capture will have been pre-processed by the time they get it to remove, e.g. security-sensitive IP addresses). A hook in the capture file that triggered a popup with a short message would be perfect. Is there anyway to do this, short of wrapping Wireshark with another binary (which would be trivially bypass-able anyway)?
I've searched in the wireshark lists but come up empty.
The only thing you could do would be to have the pre-processing program write out the file in pcapng format and add a comment to the initial Section Header Block giving that warning. That won't produce a popup - but, then, not all the capture file reading programs in the Wireshark suite are GUI programs that could produce a popup.
I have two keyboards attached to a PC. One is used to type in TMemo1 and the other in TMemo2. Both are allowed to type at the same time. The problem is I cannot distinguish what keyboard-one has typed and what keyboard-two has typed.
Is there any way to distinguish, which device certain input came from?
#Dian, you can use the RegisterRawInputDevices function to register the keyboards and monitor the WM_INPUT message to determine the device (keyboard) where the input came from.
check theses links for more info
Using Raw Input from C# to handle multiple keyboards
WM_INPUT Message
As far as I know there is no way to distinguish keyboards unil you have hooked keyboard driver. Windows provide solid input model to application, so there is no difference for application receiving input from keyboard, second keyboard, IR remote control, or from another program that uses SendInput API function.
sorry for this little bit strange title, didn't found a better one..
I've got the following situation:
I have a PC with an RFID reader connected via USB.
I now need a program which pops up when ab transponder was scanned the the RFID reader and shows the scanned value. (The reader just simulates keystrokes)
Problem: the value of the transponder is something like 0001230431, and I can't change it. (To prefix a hotkey combination or so)
So I have thought about using a global keyboard hook, check if three zeros where typed in, capture rest of data and when the 10 digits are complete, call the application through an automation object and show the number.
But I'm not very exalted about using a global keyboard hook. Many AV programs don't like them very much, they are not so easy to handle with Delphi and I guess that's not very resource-friendly for such a little task...
So I'm looking for an alternative solution...maybe somebody has an idea?
Big thx!
ben, you can use the RegisterRawInputDevices and GetRawInputData functions.
first you must use the RegisterRawInputDevices function to register the input device to monitor and then you can retrieves the data from the input device using the GetRawInputData function.
Check theses functions too
GetRawInputDeviceList retrieves the list of input devices attached to the system.
GetRawInputDeviceInfo retrieves information on a device.
Why not make sure the Delphi app with a text edit control has focus before the scan is done? Then the keystrokes will go straight into your Delphi app.
I've written some BlackBerry apps, but now i'm trying to write one that must access the hardware (keyboard) in some low level way, and I can't seem to find a way to do it, nor any help to it in the 'official' boards.
The thing is, I need to know when, at any time, the '$' key is pressed in the blackberry keyboard, so my app (or resident service) can catch it, stop the '$' char from displaying, and if the user presses a vowel next, then add an accent to that vowel... and if it presses another key, just send back the '$' char + the other char.
i.e. '$' + 'a' = รก
In other words, I need to create an app or service that converts the '$' key into an accent key, just like typical non-US PC keyboards works.
Now here's the problem: The whole Blackberry OS works under a Java Virtual Machine (Kind of making the JVM the actual OS). So as you can imagine, every app written for it is written in Java.
There's obviously a set of special blackberry api libraries into their Java implementation so the developer is able to access particular Blackberry functions and features... however there doesn't seem to be a thing that I can use to achieve my particular task.
But then maybe there is, and I haven't found it, since I'm still new to Blackberry Programming.
So, in that note, any help or comment will be greatly appreciated.
-Gabriel Alonso.
A screen need to have the focus to be able to get key Event.
RIM dosen't allow low level access to their hardware for security reason.
Press and hold a letter key and roll the thumb-wheel to scroll through international/accent characters, equation symbols and other marks.
Here is the source
Blackberry do not allow execute applications, if they use certain API, not to mention the low-level programming.
All that you can use in your applications for keypad handling - it is possibilities of Java. Like KeyListener interface and Keypad class.
This is a very late reply, however...
You can use keyChar (member of screen, and of KeyListenerInterface) to intercept any key - for the first letter, capture the key pressed. If it's "$" hold onto it and don't call super.keyChar. On the next keyChar (or after a delay with no input) perform your mapping if $ was previously pressed, and send your designed character code to the super.keyChar call. keyDown and keyUp can be used similarly if keyChar presents implementation issues.