View Issue Details

IDProjectCategoryView StatusLast Update
0024132LazarusLCLpublic2013-03-25 09:53
ReporterFelipe Monteiro de Carvalho Assigned ToFelipe Monteiro de Carvalho  
Status resolvedResolutionfixed 
Fixed in Version1.1 (SVN) 
Summary0024132: [WinCE] TEdit doesn't receive text from some barcode scanners
DescriptionThe 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:

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:

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:

   LMKeyMsg: TLMKey;
   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:
TagsNo tags attached.
Fixed in Revision40630
Attached Files


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2013-03-25 09:53 Felipe Monteiro de Carvalho New Issue
2013-03-25 09:53 Felipe Monteiro de Carvalho Fixed in Revision => 40630
2013-03-25 09:53 Felipe Monteiro de Carvalho Status new => resolved
2013-03-25 09:53 Felipe Monteiro de Carvalho Fixed in Version => 1.1 (SVN)
2013-03-25 09:53 Felipe Monteiro de Carvalho Resolution open => fixed
2013-03-25 09:53 Felipe Monteiro de Carvalho Assigned To => Felipe Monteiro de Carvalho