View Issue Details

IDProjectCategoryView StatusLast Update
0024132LazarusLCLpublic2013-03-25 09:53
ReporterFelipe Monteiro de CarvalhoAssigned ToFelipe Monteiro de Carvalho 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product VersionProduct Build 
Target VersionFixed 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:
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
TagsNo tags attached.
Fixed in Revision40630
LazTarget-
WidgetsetWinCE
Attached Files

Activities

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