JPH0744298A - Input emulator - Google Patents

Abstract

PURPOSE:To obviate an application exclusively used for SE preparation by fetching data read from a medium by a driver, working the data into character data, inputting the data to the application, and performing processing of the data. CONSTITUTION:A driver 3 fetches the data read from the medium by an input device 1, and gathers the data into a certain unit. An input emulate processing 4 receives the data fetched by the driver 3, and works the data into the standardized character data. Therefore, a code read by a code reader 12 or a magnetic card reader 13 becomes the dame form as a character code read and generated from a keyboard 11 by the input emulate processing 4, the data can be directly delivered to an application 5 being a circulation application generated so that the character code can be received. Thus, any data from various kinds of input devices such as the keyboard and the bar code reader can be worked into the standardized character data, easily inputted to the application, and processed.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an input emulator that emulates data from an input device and transfers it to an application.

Bar codes, magnetic cards, etc. are used for inventory management, product management, personal ID management, etc., and data from these are input to the input fields of the form displayed on the screen, and the input data are distributed as is. It is performed by inputting into the spreadsheet application of the above to perform processing. At this time, it is desired that the data input from the bar code, the magnetic card, and the keyboard be directly input to the input field of the form on the screen with a simple configuration.

[0003]

2. Description of the Related Art Conventionally, when data of a bar code or a magnetic card is loaded into an application using a bar code reader or a magnetic card reader, as shown in FIG. 6, a bar code reader 21, a bar code driver 22 and an SE are created. It was designed to be taken into the business application via the dedicated application 23. The configuration and operation of FIG. 6 will be briefly described below.

FIG. 6 shows an explanatory view of the prior art. In FIG. 6, a bar code reader 21 reads a bar code and converts it into a code.

The bar code driver 22 collects codes read by the bar code reader 21 into a certain unit and notifies the special application 23 for SE creation. The SE-specific application 23 is an application specially created by the SE (system engineer) to pass the data from the barcode driver 22 to the business application.

Next, the operation will be described. (1) The barcode reader 21 reads the barcode attached to the product and converts it into a code.

(2) The bar code driver 2 which has received the notification of the code read and converted from the bar code in (1)
Special application for SE creation 2
Notify 3.

(3) The SE-dedicated application 23, which has been notified in (2), processes the business application and passes it to the business application. The business application that has received the data performs a predetermined business process.

[0009]

As described above, conventionally, when data read from a bar code or a magnetic card is passed to a business application or input in an input field of a form displayed on the screen, There is a problem in that it is necessary to individually create an application 23 that creates the SE-specific application 23 and processes the data so that the business application can receive it.

The present invention solves these problems.
Data input from a bar code reader or magnetic card reader is emulated, processed into a character code in the same format as input from a keyboard, etc. The purpose is to make apps unnecessary.

[0011]

[Means for Solving the Problems] Means for solving the problems will be described with reference to FIG. In FIG. 1, the driver 3 takes in the data read from the medium by the input device 1.

The input emulation processing 4 is for processing the data taken in by the driver 3 into character data. The application 5 receives character data and processes it.

[0013]

According to the present invention, as shown in FIG. 1, the driver 3 takes in the data read from the medium by the input device 1, and the input emulation processing 4 receives the taken-in data, converts it into character data, and directly. The application 5 is input, and the input application 5 performs a predetermined process.

At this time, the processed character data is passed to the application 5 and input to the cursor position of the active window on the screen. Further, the data read from the medium by the input device 1 is data read from a barcode or a magnetic card, and the data is processed in the same manner as the character data input from the keyboard.

Therefore, the data input from the bar code reader 12 or the magnetic card reader 12 is emulated to be processed into the same character data as the input from the keyboard 11 or the like, and directly input to the business application for processing. By doing so, the conventional dedicated SE creation application becomes unnecessary,
It has become possible to easily input data from the various input devices 1 to the application and perform processing.

[0016]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, the construction and operation of an embodiment of the present invention will be described in detail with reference to FIGS.

FIG. 1 shows a block diagram of an embodiment of the present invention.
In FIG. 1, an input device 1 is for inputting various data and characters, and here is a keyboard 11, a bar code reader 12, a magnetic card reader 13, and the like.

The keyboard 11 is for inputting characters, alphanumeric characters, symbols and the like. The barcode reader 12 reads a barcode and converts it into a code. The magnetic card reader 13 reads a magnetic card and turns it into a code.

The OS (Windows system) 2 is an operating system, and here is an operating system called a so-called Windows system. The OS 2 controls the entire system, and here, passes the code input from the input device 1 to the driver 3.

The driver 3 takes in data read from the medium by the input device 1 and collects the data in a certain unit, and is a keyboard driver 31, a bar code driver 32, a magnetic card driver 33, or the like.

The keyboard driver 31 is the keyboard 1
The code input from 1 is received, and the code is converted into character data. The bar code driver 32 collects the codes read from the bar code by the bar code reader 12 into a fixed unit of data.

The magnetic card driver 33 collects the codes read from the magnetic card by the magnetic card reader 13 into a fixed unit of data. The input emulation processing 4 receives the data captured by the driver 3 and processes it into standardized character data (for example, standardized character data that is input from the keyboard and input to the application 5).
Therefore, the code read from the bar code or the magnetic card by the input emulation processing 4 has the same format as the character code generated by reading from the keyboard 11, and the application of the distribution application created to receive this character code. It is possible to directly pass to 5.
For example, input shift state of Kana-Kanji conversion from keyboard 11 (all states such as shift key ON / OFF, Kana mode, English mode, English large mode, English small mode)
Some types of data (standardized character data)
After that, the application 5 is notified. On the other hand, the data read from the barcode is notified to the application 5 as constant data (normalized character data) corresponding to the input barcode regardless of the input state.

The application 5 is an application program, which is a distribution application, and performs various business processes. Next, with reference to FIG. 2, the concept of the configuration and operation of FIG. 1 will be described in detail based on an example in which the barcode is read, standardized, processed into a character code, and input to the application 5.

In FIG. 2, in S1, the barcode reader 12 reads the barcode and generates a code. S2
Receives the code read by the barcode driver 32 in S1, collects the data into a certain unit of data, and stores it in a buffer. In S3, the data receiving unit 41 and the data processing unit 4
2, the data is received by the data transmission unit 43, processed, and transmitted to the application 5, and S31
Through S33 are performed.

In S31, the data receiving unit 41 issues a read to the bar code driver 32, and receives (reads) the combined data in the buffer. In S32, the data (code) received (read) by the data processing unit 42 in S31.
Is processed into standardized character data (see (a) of FIG. 5).

In S33, the data transmitting unit 43 directly transmits the standardized character data processed in S32 to the application 5. In S4, the application 5 receives (inputs) the standardized character data transmitted in S33.

As described above, the codes read from the bar code are stored in a buffer, which is taken out and converted into standardized character data, and the converted character data is directly input to the application 5. As a result, the standardized character data that is the same as the character data keyed in from the keyboard 11 (not shown) is directly input to the application 5, for example, in the input area of the active window, and is input to the application 5 for processing. It becomes possible to do it.

The operation of the configuration of FIG. 1 will be described in detail below with reference to FIGS. 3 to 5. FIG. 3 shows an operation explanatory diagram of the present invention. This shows the operation when the code read from the Harcode is processed into standardized character data and input into the input area on the active window on the screen managed by the application 5.

In FIG. 3, in S11, the bar code reader 12 reads the bar code. S12 is S
The data read in 11 is code-converted into a code (for example, hard ASCII data) (see (a) in FIG. 5).

In S13, the code after the code conversion in S12 (for example, hard ASCII data, A, B, C, ...
・ (Data for each byte)) is temporarily stored in the buffer.

In step S14, the input emulation processing 4 reads at every fixed time whether there is data in the buffer (READ.
Run). In S15, it is determined whether or not there is data to read in S14. In the case of YES, it progresses to S17. If NO, the process returns to S14.

In S16, the bar code driver 32 collects the data in a buffer in a certain unit. For example, it is summarized as a set of data "ABC ...". S17 is S15
Since it is determined that there is data in the buffer by YES, the data is read.

In step S18, the data read from the buffer in step S17 is processed. For example, as shown in the figure, it is processed as message character data character code message ABC ...

In step S19, an active screen is obtained from the OS. S20 sends a message to the active screen. These S19 and S20 obtain the active screen (window) of the application 5 to which the input emulation processing 4 is going to pass the character data from the OS2, and standardize the active screen (window) processed in S18. Send a message (character data).

In step S21, data is input at the position of the cursor on the screen. This displays the character data message transmitted in S20 at the cursor position (see (c) in FIG. 5).

In S22, the application 5 takes in data from the position of the cursor on the active screen (window) and executes the process. As described above, after temporarily converting the code read from the bar code into the buffer and processing the data read from this buffer into standardized character data (message),
It is sent to the active screen (window) and input (displayed) at the position of the cursor, and the application 5 captures this and executes the process. As a result, it becomes possible to convert the code read from the bar code, further process it into standardized character data, and directly input it to the cursor position of the active window of the application 5.

On the other hand, in S23, in the case of a keyboard, the key is pressed. In S24, the keyboard driver 31 is S2.
The key code keyed in 3 is converted into data.

In S25, the data converted in S24 is stored in the buffer. S26 outputs data (character data). S27 is Windows system 20
Converts the message. This converts the character data output in S26 into a message (standardized character data).

In step S28, an active screen is obtained. S2
9 sends a message to the corresponding screen. These S
28 and S29 transmit the standardized character data (message) to the active screen (window), similarly to S19 and S20, via the Windows system 20. Then, in S21, data is input (displayed) at the position of the cursor on the screen, and in S22, the application 5 takes in the data and executes the process.

As described above, the character data obtained by code conversion of the code input from the keyboard 11 is transmitted to the active screen (window) and input (displayed) at the position of the cursor, and the application 5 fetches and executes the processing. . As a result, the character data obtained by code conversion of the code read from the keyboard 11 can be input to the position of the cursor in the active window of the application 5 as in the conventional case.

FIG. 4 is a diagram showing the construction and operation of the essential parts of the present invention. This is a configuration diagram and an operation explanatory diagram of a main part in the case where the input emulation processing 4 emulates the same standardized character data input by key input.

In FIG. 4, the bar code driver 32
1 is the bar code driver 32 of FIG. 1, in which the code read from the bar code by the bar code reader 12 is converted into data and temporarily stored in a buffer.

The application 5 is an application (application program) that performs various business processes. Here,
A window is displayed on the screen, character data is input at the cursor position of the window, the input data is fetched, and processing is executed.

The key input emulation processing 41, here, takes in data from the buffer of the bar code driver 32, processes it into standardized character data, and inputs it at the cursor position of the active window. , A read processing procedure 42 and a main procedure 43.

The read processing procedure 42 reads the data from the buffer of the bar code driver 32, processes the data into standardized character data, and then notifies the main procedure 43.

The main procedure 43, for the character data notified from the read processing procedure 42,
Here it notifies the active window. Next, the operation of FIG. 4 will be described in detail.

In FIG. 4, the bar code library is read and the stored data is read from the buffer of the bar code driver 32 (S1 in FIG. 3).
7).

If there is no data to be read in, the process returns. Creates the data to be notified. This creates standardized character data from the data read in (processing, S18 in FIG. 3).

Is the WMU of the main procedure 43.
Notify SER. Obtains the window in which the main procedure 43 is currently active. This is S1 in FIG.
As described in 9, obtain the currently active window of the app 5 from the OS.

(3) notifies the active windows of data (character data) in order (S20 in FIG. 3). The notified data (character data) is input at the cursor position.

If there is data remaining, starts a 10 millisecond timer. Then, the process returns to and is repeated, and the notification of the data (character data) to the active window is repeated.

After the notification of all data (character data) is completed, the process ends. As described above, the data (code) read from the barcode and stored in the buffer of the barcode driver 32 is processed into standardized character data and input (displayed) at the cursor position of the active window of the application 5. As a result, it becomes possible to convert the barcode data into standardized character data, input it at the cursor position of the window, and pass it to the application 5, and the SE can execute the dedicated application corresponding to the conventional application 5 and the barcode driver 32. Eliminates the need to create.

FIG. 5 is a data / display explanatory diagram of the present invention. FIG. 5A shows an image of the data format.
(A-1) shows barcode data. This is shown in Figure 3.
It is an image of the hard ASCII data which is the barcode data after being read from the barcode and subjected to code conversion in S11 and S12. Here, the hard ASCII data is divided into 1-byte units such as A, B, C, ....

(A-2) shows the data collected by the bar code driver 32. This is an image of collectively storing the hard ASCII data in the buffer in S16 of FIG. Here, the hard ASCII data is "ABC
"..." are organized in a certain unit.

(A-3) shows data notified to the application 5 by the key input emulation processing 4 and the Windows (Windows) system. This is S20 in FIG.
Alternatively, it is the data transmitted to the application 5 as a character code message (standardized character data) in S29. Here, the character code message is the standardized character data of message character data character code message ABC ... To the system.

(A-4) shows data notified by the keyboard driver 31 to the Windows system. This is data transmitted to the Windows system 20 as a key code message in S26 of FIG. Here, the key code message is key code = key address XYZ ... This key code message is processed by the Windows system 20 into the format (a-3) and is notified to the application 5.

FIG. 5B shows an active window table. This is a table that stores which window the application 5 is currently active. The window active in 19 or S28 of FIG. 3 is found by referring to this active window table.

FIG. 5C shows an example of the screen. this is,
In the example of the active window found in (b) of FIG. 5, the character data read from the barcode and processed and standardized at the cursor position in the table of the window or the code input from the keyboard 11 is displayed. This is a window for displaying (inputting) processed standardized character data.

[0059]

As described above, according to the present invention,
The data input from the bar code reader 12 or the magnetic card reader 13 is emulated, processed into the same character data as the input from the keyboard 11, etc., and directly input to the business application for processing. Therefore, any data from the various input devices 1 can be processed into standardized character data and easily input to the application 5 to be processed. As a result, the dedicated application 23 for creating a conventional SE becomes unnecessary, and the input emulation processing 4 according to the present invention is added to improve the function, so that the user can operate the barcode reader 12 and the magnetic card reader 13 or the like. The data from the input device 1 can be directly passed to the application 5 to be processed, and furthermore, the existing distribution application can be input as it is to be processed and processed.

[Brief description of drawings]

FIG. 1 is a configuration diagram of an embodiment of the present invention.

FIG. 2 is an explanatory diagram of a main part configuration of the present invention.

FIG. 3 is an operation explanatory diagram of the present invention.

FIG. 4 is an explanatory diagram of a configuration and an operation of main parts of the present invention.

FIG. 5 is a data / display explanatory diagram of the present invention.

FIG. 6 is an explanatory diagram of a conventional technique.

[Explanation of symbols]

1: Input device 11: Keyboard 12: Bar code reader 13: Magnetic card reader 2: OS (Windows system, Windows system) 3: Driver 31: Keyboard driver 32: Bar code driver 33: Magnetic card driver 4: Input emulation processing 5: App

Claims (3)

[Claims] 1. An input emulator that emulates data from an input device and transfers the data to an application. A driver (3) for fetching data read from a medium by the input device (1) and data fetched by this driver (3). An input emulator comprising: an input emulation process (4) for converting the processed character data to a character data and directly passing the processed character data to an application (5). 2. The input emulator according to claim 1, wherein the processed character data is passed to an application (5) and input to the cursor position of an active window on the screen. 3. The data read from the medium by the input device (1) is data read from a bar code or a magnetic card, and the data is processed into the same format as the character data input from the keyboard. The input emulator according to claim 1 or 2, characterized in that