A customer has asked me can we please limited "keyboard entry" at their goods despatch where they use a USB/Keyboard bar code scanner and stop users overriding the system and entering a barcode (infld) in manually.. The users also cheats as they found ATE "auto mouse" and if the double click the item else where on the screen telling them to scan it, that it also populates the input field.
As you can guess the trouble is the USB scanner uses the keyboard input interface, i did try the INFLD timer and set it to 1 seconds, so they would have type faster than a scanner but the Timer switch only works on in-activity.. is there another switch similar that clears and resets INFLD with in a second. (The barcode scanner should still be faster enough to allow the input).
Also, Is there way turn "Auto Mouse" off? I click Auto Mouse and the tick never vanishes and stays on.
It has been awhile since I've looked very closely at the AutoMouse settings, but I did manage to locate this utility program: AMOUSE.BP which illustrates using AG_MOUSE commands. And the following does appear to work to disable the option:
Code
.RUN AMOUSE/1
AutoMouse set to 1 [disabled]
As for some way to inflict a severe case of attention deficit syndrome on INFLD such that it will only accept a burst of data, I'm going to need at least another cup of coffee...! We may need yet another type code that set the timer to unlimited initially (while waiting for the bar code) but then reset it to 1 second on receipt of the first character?
Ok, I'm thinking it should be ||t, which is just like |t except the timeout doesn't start until the first character is received. Hopefully 1 second is short enough so that if they are manually typing, you'll get a result that is too short and you can reject it.
Note that under that model, it would be up to the app to reject the runt-sized entry. I guess the ultimate would be if INFLD automatically cleared the field on timeout if you hadn't yet typed the XMIN characters, but that seems too specialized to be of any use outside this particular situation.
Sounds good, I was just thinking after the second clear the field ... we may start to see a new world championship of keyboard ninjas trying to beat it!
Hey Steve i am sure you might have already thought of this but if "disable" INFLD, will it still accept data from the reader?
Or what about hiding it off the screen? In coordinates that are not visible by the current open dialog? (i did this by accident so i know it's possibel
what a sneaky way.. what happens if they just type the barcode numbers in and press C/R (even if nothing shows on screen) i guess even hidden it allows it?
I could try this "hide" first ..to save Jack making any changes... until some clever spark comes along and works it out. Or jack fixes the out of screen bug and the INFLD reappears
Note that I had to use a different type code, ||1 because ||t was already taken for a variation of date/time.
Also note that it currently is just a piggy-back on the existing timer mechanism. Essentially it just issues the suspend timer command at the start, after which it acts like a normal timeout (i.e. reactivating the timer on the first character). But I'm a little worried that you're going to say that the 1 second timeout isn't enough of a challenge for your fleet-fingered friends. The problem is that the logic is currently based on timer routines with only one-second resolution, meaning that to be sure we didn't cheat the speedy scribe we really have to wait until the seconds value has increased by 2. If it's too easy to out-type the timer, we might have to look into changing it over to millisecond (or nanosecond?) precision.
Sorry, the notes may not have been sufficiently explicit regarding the necessity of setting the INFLD'TIMER parameter to something (i.e. 1 being the smallest possible timeout). I'm not sure whether the delayed timeout wasn't working at all for you, or was it just that the "1 second" seemed like an eternity?
.RUN INFLFD5
Windows delayed timer test
Timer : 1
INFLD: <GUI edit appears, suspend timer also starts counting down in bottom corner,
wait 5 secs to confirm no timeout; then type '1234' and wait...>
<timeout occurs after 1-2 secs, resulting in this...>
ENTRY: [1234]
EXITCODE: 11
TIMER: 1
If the problem is that the 1-2 second timeout is way too long, then we may need to switch to a more precise timer, or maybe handle the combination of ||1 and TIMER=1 (or maybe 0?) as a special case with a 100 ms timeout? But if it's not working at all, then we have a different problem to solve first.
Just tried your example and does kind of what you say.. but I was expecting as I type 1 2 3 4 5 6 7 when a second was up from start of me typing it would clear the field so i had start again, currently if i dont stop it carry's on... Or was that what you mean with:
Quote
1 second timeout isn't enough of a challenge for your fleet-fingered friends. The problem is that the logic is currently based on timer routines with only one-second resolution, meaning that to be sure we didn't cheat the speedy scribe we really have to wait until the seconds value has increased by 2. If it's too easy to out-type the timer, we might have to look into changing it over to millisecond (or nanosecond?) precision.
And you have have a whole second between key presses for it to clear/restart?
Ok, first I can see now that it is resetting the timer after each character, which is not what you want. That should be easy to fix.
But as for what happens when it times out, I was thinking that exiting with the exitcode=11 (timeout) was the most flexible option, leaving it to the application to decide whether the input was sufficient to be valid. But I guess we could say that if it failed to satisfy the XMIN characters, then it would make sense to just clear the field, reset/suspend the timer, and start over again from the beginning?
The problem with the first version was more subtle than it appeared. It wasn't resetting the timer after each character. But it so happens that the normal timer mechanism gets processed only once per second, and timeout is only checked for after one second of no activity. So as long as you were typing at least one character per second, you were avoiding the timeout test. The new version now checks for timeout after after character, as well as after every second without input. So now I think you might actually find it challenging to type in a, say, 10 character field before it times out (assuming TIMER=1). I had to use the AutoMouse or paste feature to properly verify that I could in fact enter several characters successfully.
I think having the application take care of weeding out invalid entries and resetting the field is the right call, since you probably need to have logic like that anyway in order to deal with defective scans.
One detail that might still be open to question is that of treating the initial wait for the first character as equivalent to the suspend feature (10 minutes) is that you absolutely have to be prepared to deal with timeout, at least every 10 minutes. But it seems like the you need to have that logic anyway, so I'm not sure I see any advantage in adding special logic to not time out after 10 minutes of inactivity.
Customer updated his ATE with latest ashw32.exe 1691.1 and you have great feed back! works a treat.. (no more wrong stock items shipped due to employees typing in a wrong barcode rather than SCAN the right one)
Is it possible to have a new ATE/Install build at a convenient point. Thanks.
but the Timer switch only works on in-activity.. is there another switch similar that clears and resets INFLD with in a second. (The barcode scanner should still be faster enough to allow the input).
