[WinCE] TEdit doesn't receive text from some barcode scanners
Original Reporter info from Mantis: sekelsenmat
-
Reporter name: Felipe Monteiro de Carvalho
Original Reporter info from Mantis: sekelsenmat
- Reporter name: Felipe Monteiro de Carvalho
Description:
The issue is already fixed. I am just reporting here to keep a record of it.
Basically we found 3 different kinds of scanners:
1> Some scanners send Windows messages equivalent to pressing each number, for example:
WM_KEYDOWN wparam=VK_3
WM_CHAR wparam=51='3' lparam=1
WM_KEYUP wparam=VK_3
2> The same as type 1, but with wparam=0 in the WM_KEYDOWN
WM_KEYDOWN wparam=0 lparam=1
WM_CHAR wparam=51='3' lparam=1
WM_KEYUP wparam=0 lparam=-1073741823
3> Some scanners send only a series of WM_CHAR messages
4> Some scanners send a Ctrl+V paste operation:
WM_KEYDOWN Ctrl
WM_KEYDOWN v
WM_PASTE
WM_KEYUP v
WM_KEYUP Ctrl
The problem was that in some scanners of type 2, the WM_KEYDOWN has wparam=0 which is not a value described as possible in the MSDN docs and it
will cancel the following WM_CHAR =(
I read the MSDN documentation and I haven't found anything about this behavior: http://msdn.microsoft.com/en-us/library/windows/desktop/ms646280(v=vs.85).aspx
Similarly in the MSDN docs there is no Virtual Key code with value zero.
I have tryed to determine if the LCL is one interpreting the WM_KEYDOWN and cancelling the WM_CHAR with this code to send a TLMKey before the key char:
var
LMKeyMsg: TLMKey;
begin
LMKeyMsg.Msg := LM_KEYDOWN;
LMKeyMsg.CharCode := 0;//Word(WParam);
LMKeyMsg.KeyData := 1;
DeliverMessage(editField, LMKeyMsg);
Windows.SendMessage(editField.Handle, WM_CHAR, 48, 1);
But no. In this case everything goes OK and the char is inserted. So I think that the LCL is not interpreting the WM_KEYDOWN and is not causing the problem. If I send raw messages, like this:
Windows.SendMessage(editField.Handle, WM_KEYDOWN, 0, 1);
Windows.SendMessage(editField.Handle, WM_CHAR, 48, 1);
//Windows.SendMessage(editField.Handle, WM_KEYUP, 0, -1073741823);
this one is not necessary
Then the WM_CHAR gets supressed.
So I think that the native Windows control is the one which is doing this behavior. And I think it might be on purpose, so that people can activate the scanner reading by supressing WM_KEYDOWN with wparam=0. But I am not sure, since there is nothing in the documentation about this.
At the moment I fixed this by adding a special check for wparam=0 in WM_KEYDOWN and change it to VK_0. The behavior is configurable via WinCEWidgetset.BarcodeScannerWorkaround
See the commit here: http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=40630
Mantis conversion info:
- Mantis ID: 24132
- Fixed in version: 1.1 (SVN)
- Fixed in revision: 40630 (#146aeb10)