How to use VWconfig.ini

[hjgode]

Hello

I can see a \Windows\VWconfig.ini which applies 'correction' on how the barcode scanner wedge transmits scanned barcode data to applications. Here is a sample I found:

[VWConfig]
DumpConfig="1"


[Notes]
WindowName="Notes"

;;;Use CLIP for all chars 0-127; default above 128
GlobalXmitMethod="CLIP"
GlobalXmitType="Table"

;;;exceptions to the above for TAB and CR
RegSeq="0x09 POST PLAIN 0X09 0X00 0x0000"
RegSeq="0x0D POST PLAIN 0X0D 0X00 0x0000"

[IE]
WindowName="Internet Explorer"

;;;Use CLIP for all chars 0-127; default above 128
GlobalXmitMethod="CLIP"
GlobalXmitType="Table"

;;;exceptions to the above for TAB and CR
RegSeq="0x09 POST PLAIN 0X09 0X00 0x0000"
RegSeq="0x0D POST PLAIN 0X0D 0X00 0x0000"

[Excel]
WindowName="Excel Mobile"

;;;Use CLIP for all chars 0-127; default above 128
GlobalXmitMethod="CLIP"
GlobalXmitType="Table"

;;;exceptions to the above for TAB and CR
RegSeq="0x09 POST PLAIN 0X09 0X00 0x0000"
RegSeq="0x0D POST PLAIN 0X0D 0X00 0x0000"

[Word]
WindowName="Word Mobile"

;;;Use CLIP for all chars 0-127; default above 128
GlobalXmitMethod="CLIP"
GlobalXmitType="Table"

;;;exceptions to the above for TAB and CR
RegSeq="0x09 POST PLAIN 0X09 0X00 0x0000"
RegSeq="0x0D POST PLAIN 0X0D 0X00 0x0000"

Can anyone explain all these settings? Especially the ReqSeq.

regards

Josef

 

[hjgode]

Bump...Trying by myself...

Basics of data and keyboard wedging

This is my thinking of barcode data can be wedged as simulated keyboard data in a windows Operating System. The windows program coding is used here in a very simplyfied way.

Sometimes it is good to know some background information to understand how soemthing is working.

Pre-requisites

First, barcode data is encoded as ASCII and keyboard “data” is in general a windows message sequence. Messages inform a window about changes and request. They control the text on a button or the size of a window. The Windows message queue is the transport way of the OS.

Windows keyboard messages

Sender is the keyboard (the windows keyboard driver)

If you type the [A] key on your keyboard, the keyboard driver gets a make and break signal. This is translated by the driver to the windows message sequence:
WM_KEYDOWN(VK_A, ScanCode)
WM_KEYUP(VK_A, ScanCode)

ScanCode
A scancode is the keyboard hardware scancode of a key on the keyboard. It describes the location of the keycap and is an ddtional information for the receiver.
Warning: there maybe programs that use scancodes to translate keys to characters. A well-known example is the Remote Desktop Mobile Client. It uses scancodes and transfers these to the terminal server. It may happen, that the Mobile has a QWERTZ keyboard setup and the server has a QWERTY setup. Can you imagine what happens? The scancode of the [Z] key creates a “Y” on the server!

The windows message pump (can be part of a window) can “translate” WM_KEYDOWN and WM_KEYUP to this message sequence for a window:
WM_KEYDOWN(VK_A, ScanCode)
WM_CHAR(“a”)
WM_KEYUP(VK_A, ScanCode)

If you press the [Enter] key on your keyboard, you will get a similar windows messages sequence:
WM_KEYDOWN(VK_ENTER, ScanCode)
WM_CHAR(“<CR>”)
WM_KEYUP(VK_ENTER, ScanCode)

Where <CR> is the byte code of the enter value.

NOTE: VK_ENTER is NOT the same as <CR>, although the byte data is the same! VK_ENTER is a possible WM_KEYDOWN/KEYUP window message parameter, where <CR> is a WM_CHAR parameter!

What happens when you press Shift+[A]? Then you get additional keyboard messages and a different WM_CHAR one:
WM_KEYDOWN(VK_SHIFT, ScanCode)
WM_KEYDOWN(VK_A, ScanCode)
WM_CHAR(“A”)
WM_KEYUP(VK_A, ScanCode)
WM_KEYUP(VK_SHIFT, ScanCode)

Modifier keys like Shift, Alt and Ctrl also set flags that can be checked by a windows programmer.

The receiver window

On the windows receiver side, these message sequences is all a window gets for the keyboard.

Normally the Window Proc that is assigned to a window has a list of messages it will process. This is normally done in a switch/case code block. For example, if a coder wants to be informed about mouse clicks, the coder has to include a “message handler” for WM_LMOUSE_DOWN and WM_LMOUSE_UP (for left clicks). If a programmer would like to let his/her application act on keyboard messages, he/she has to add WM_KEYDOWN/WM_KEYUP handlers. If he/she is just interested in character processing, he/she may only process WM_CHAR messages. If you are interested to get all informations, you would use WM_KEYDOWN, WM_KEYUP, WM_CHAR and all the other WM_ messages for keyboard handling.

Simplest keyboard WndProc:

switch(msg){
case WM_CHAR:
//do something
break;
…
}

Enhanced keyboard WndProc:

switch(msg){
case WM_CHAR:
//do something
break;
case WM_KEYDOWN:
//do something
break;
case WM_KEYUP:
//do something
break;
…
}

NOTE: Depending on the writer of an application, the application code may ONLY process WM_CHAR messages!

There are some more possible message in the context of the keyboard, like WM_SYSKEY... etc. But in this general information we dont go any deeper.

Remember, all this is only about what happens with windows keyboard messages.

The input simulation

We want to get the ASCII (yes, it maybe Unicode too) data of the barcode read by a barcode scanner into an application that does not know about a barcdode scanner. To simulate data input inside a windows operating system, there are different choices.

PostMessage

A program can post messages to a specified window. The sender will not wait on the message delivery. Either a window is specified or you use a broadcast.

PostKeyboardMessage

This is a specialized form of the PostMessage API for keyboard messages. It can process a list of 'keys' whereas PostMessage can only post one message at time. Additionally it supports sending to actual foreground window.

SendMessage

A program can send messages to a specified window. The sender code will block until the message is delivered to the window.

Keybd_Event

This function will simulate a keydown or keyup. There is no specified window, that means, the foreground window will get the message first.

SendInput

This is similar to Keybd_Event but does not use a single code. One can use that to send some keyboard events in a sequence. SendInput processes a list of codes whereas Keydb_Event only supports one value at time.

Clipboard

Whuuu, what is that? The clipboard is a memory area where one program can put data in and another may pull the data out. You can put data in the clipboard by pressing Ctrl+[C] and paste data from the clipboard by pressing Ctrl+[V] . The pasting will work if the program or standard window supports that key combination and processes that. Edit or Input fields normally support this copy/paste by default.

A “sender” program can use the following pseudo code sequence to transfer data:
SetClipboardData(“Text to transfer”)
PostMessages for Ctrl+V or use keybd_events for Ctrl+V

The receiver window will then get the Ctrl+V keyboard message and can use GetClipboardData to get the text.

VwConfig.ini

Now with some knowledge on the background I can somehow imagine what CLIP, POST, SEND does mean in the VwConfig dump log files.

[bbrennan]

This is very interesting information.  We just logged a case where a customer was using a CK70 using (RDP) mobile desktop into a terminal server.  They had a home grown application running on the terminal server.  They could type data fine.  When they scanned data, nothing came across.  TS sent us a customized VWconfig,ini.

Based on this post and a couple other entries, I can start to piece together what is happening.

Is there any solid documentation on the entries of the VWConfig.ini ?  I really would like to understand this capability.

As a side note, we also tested with an old CK31 and found that the RDP client there would pass scanned data but it was coming across as garbage.  Digging deeper there, we found an RDP client setting called KEYBOARDHOOK.  Setting this value to zero in the XXX.RDP file caused the Windows Key Combinations to resolve on the client machine.  Setting it to 1 caused the Windows Key Combinations to resolve on the server machine.  

By setting this to Zero, we got the wedge scanner data through to the application as intended.

The RDP files are just text files.  You can pass one from your desktop RDP session to a mobile device.  Depending on the mobile client, you may or may not have access to set some of these entries.  The more modern the client, the less control we seem to have.

[hjgode]

Here is an example for a global replace of some barcode data:

[VWConfig]
; create VWCustomLog.txt and VWDefaultLog.txt in root of device
DumpConfig="1"

;change global setting:
[DEFAULT_APPLICATION]
WindowName="(NULL)"
;define exceptions for default handling
;0x29	=vkey index into table
;	POST	=transmit type (POST=PostMessage?, SEND?, PLAIN=
;		PLAIN	=key modifier (plain, shift, alt, ctrl_shift, ???)
;			0x13	(DC3)=VKEY to use, there is no vkey for DC3 so send as RAW ASCII
;				0x00	=scancode (101-key XT-keyboard, there is no DC3 key=no scancode
;					see also http://www.barcodeman.com/altek/mule/scandoc.php)
;					0x0004	=Flags (RAW ASCII)
;					0x0003	=flags (group?, keyboard scancode?)
RegSeq="0x29 POST PLAIN 0x13 0x00 0x0004"
RegSeq="0x04 POST PLAIN 0x32 0x39 0x0003"
RegSeq="0x30 POST PLAIN 0x32 0x39 0x0003"
 

[hjgode]

Hello

for those that have issues getting wedged barcode data into there apps I have done 4 different vwConfig.ini files with the different xmit types: one for POST, PLAIN, SEND and CLIP for DEFAULT_APPLICATION.

Just rename the one you would like to test with your application, copy it into \Windows on the device and warmboot the device. Then test and verify it is working for you.

Here is one example (vwConfig.ini with EVENT):

[VWConfig]
;dump config to vwCustom.log.txt and vwDefault.log.txt
DumpConfig="1"

;Only the default application is allowed to have a NULL string for the window name.
;the text between [ and ] specifies either a window title or class name. If you use 
;DEFAULT_APPLICATION, then the setting is applied, if no other section matches

[DEFAULT_APPLICATION]
;WindowName="(NULL)"

;__GlobalXmitMethod__
;GlobalXmitMethod is a string and used similarly to the GlobalFlag. 
;Setting this variable to will force all sequences from 0-255 to use this transmit method.
;The following are the only transmit method strings allowed:
;EVENT
;POST
;SEND
;CLIP
;These strings are not case sensitive and must be surrounded by quotes.
GlobalXmitMethod="EVENT"

;__GlobalXmitType__
;GlobalXmitType is a string and used similarly to the GlobalXmitMethod.  Setting this variable will force all sequences from 0-255 to use this transmit type.
;Characters above this can be modified using the UpperKeySeq variable.  Except for one case, the following are the only transmit type strings allowed:
;PLAIN      - character sent with any modifiers such as shift, ctrl, alt, etc.
;SHIFT      - character sent with the "shift" modifier
;CTRL       - character sent with the "control" modifier
;CTRL_SHIFT - character sent with both the "shift" and "control" modifiers
;ALT        - character sent with the "alternate" modifier
;CTRL_ALT   - character sent with both the "control" and "alternate" modifiers
;UNSHIFT    - sends the "shift" release only
;SYNTH      - character is sent using "synthesize" to generate the character.  This is useful mostly for characters above 127.
;PACKET     - this is used by the PostKeybdMessage() API on some platforms.  The virtual key is set to VK_PACKET and the number value of the character is included in the API call.
;Table      - uses a table for transmit type
GlobalXmitType="Table"

;;;exceptions to the above for TAB and CR
RegSeq="0x09 POST PLAIN 0X09 0X00 0x0000"
RegSeq="0x0D POST PLAIN 0X0D 0X00 0x0000"

regards

Josef

[hjgode]

Possibly the one or other already has noticed that using

;;;exceptions to the above for TAB and CR
RegSeq="0x09 POST PLAIN 0X09 0X00 0x0000"
RegSeq="0x0D POST PLAIN 0X0D 0X00 0x0000"

 in all the files makes no sense as this will break our globalXmitMethod selection.

Attached is a file set without exceptions.

Note: with globalXMitMethod=CLIP, the TAB and CR maybe not trigger your WM_KEYDOWN/_UP/_CHAR code.