Thank you,

I was reading this from the LXE pdf.

IBM 5250
5250 LXE Commands

Input Device ID (*K)

The input device ID feature provides the host application developer with
the ability to determine which LXE mobile client user
input device and which barcode symbology was utilized to enter data in any
field on the screen. When the 5250 host application
is programmed to request this data from the mobile client, and when the
input device ID feature is enabled at the client, the
client sends this information to the 5250 host emulation. This feature can
be used with the match field edit and scan and
increment features, in addition to normal user input.

This feature is useful to monitor the use of automatic input devices to
enforce the practice of not using the keyboard or keypad
as an input device.

Description
There are two major components to this feature:

- The input ID field identifies the field that follows as an operator
input field.
- The operator input field is the area on the screen where information
is returned to the host application.

Input ID Field
The input ID field:

- must be preceded by a field attribute (FA) that designates the input
ID field as unprotected (operator input capable).
- is designated with an * (asterisk) as the first character and a K as
the second character.
- can have any display attribute including non-display.
- does not have to be on the same line as the operator input field, but
it must be the first input field to precede it.
- cannot have any input fields defined on the screen map between it and
its associated operator input field.
- must have the Modified Data Tag (MDT) set by the host application so
it will return to the host when [Enter] is pressed.
- behaves exactly the same as any protected field on the LXE client
device.

Terminal Operation
When the input ID feature is enabled in client setup, the RFTerm 5250
terminal emulation modifies the input ID field to behave
as if it has the Bypass (protected) field attribute. The user can place the
cursor in the input ID field with the arrow keys, but
input is not allowed. If the user attempts input in this field, an error
message will appear indicating that the field is protected. If
the input ID feature is not enabled at the client device, RFTerm will treat
input ID fields as normal input fields.

http://www.viivakoodi.fi/assets/catalog/parts/LXE/Datasheets/MX3plus/RFTermReferenceGuide.pdf


On Fri, Aug 5, 2016 at 4:28 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

Not with a 5250 device....there's no way to differentiate between the
keyboard and the barcode scanner.

Think of the barcode scanner as a keyboard emulator, as far as the 5250
session is concerned the input was keyed in.

Now if you wanted to move to a windows/android/ect application...then then
SDK might allow you to tell when the input came from the scanner and when
it was keyed on the keyboard.

Charles


On Fri, Aug 5, 2016 at 4:11 PM, Michael Schutte <mschutte369@xxxxxxxxx>
wrote:

Has anyone successfully implemented the keyboard shift attribute I
(Inhibit
any data typing)?

We have a client wanting to make sure a barcode is scanned rather than
keyed. Ultimately training the is the major issue. Pickers are typing
in
the item number on the screen but end up picking up the wrong item.
Forcing
them to scan the barcode would help, however, there's still the potential
that they could scan one thing and pick the other.

Anyway, I've setup a display file to test out.

A DSPSIZ(24 80 *DS3)
A PRINT
A INDARA
A R SCN01
A CF01(01)
A CF03(03)
A CF04(04)
A CF12(12)
A OVERLAY
A RTNCSRLOC(&RECLOC &FLDLOC)
A RECLOC 10A H
A FLDLOC 10A H
A 5 4'Item:'
A DSPATR(HI)
A SCITEM 20I B 5 10ENTFLDATR(*NOCURSOR (*DSPATR HI
RI))

A 23 11'F3=Exit'
A COLOR(BLU)


RPGLE program.

FDISPLAYFILCF E WORKSTN
/Free
dow 1=1;
Exfmt SCN01;
If *inkc;
leave;
endif;
enddo;
*Inlr = *On;
return;
/End-Free


The RF device I tried it on was MX17. It successfully inhibited me from
typing in the field but it also did not take the scan.

I've read from other forums for some alternatives. One being do not
display the field you key into in, have some values hidden within the
field, or even having a check digit on the barcode. THe check digit
isn't
an option as the customer would have to change their barcode which would
affect their other clients/customers. I've also seen about changing the
RF
device to add prefix/suffix to the end of the scan. This isn't feasible
as
we have hundreds of RF devices.

Are there any other suggestions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.