GS1 DataMatrix reading problems

[Adrian Semcheff]

GS1 DataMatrix reading problems in Harbour.

The GS1 code used as the field separator ascii 29 (ANSI) or 8596 ascii (unicode) with clipper takes it as ascii 29 but with Windows applications such as Notepad, ascci read it as 8596, but something looks. Instead Harbour is filtered in both the Get or Inkey()

The 8596 ascii unicode is "righ left arrow"

I tried using "set to 255 +2048 EventMask" but both the Get as inkey () will continue removing the buffer.

Someone can help me!

Thank you very much!

Adrian.

[john s wolter]

Adrian,

I've setup scanners on machine tools bound for different countries that need to handle different languages.

Here's a background article about Unicode that I found very useful.  I grew up from a puppy knowing only ASC-II.  Then the Internet went global and everything changed.  It may be you need to ensure the 2-byte version of string/character functions are used.

"The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)"

Some questions and investigations....

The form of the scanner data output may effect the results of string/character functions.  This could be what you're seeing and account for the differences as the data traverses from the scanner to being stored and changed by Harbour and other programs.

Is the scanner being read by its own software or some generic Windows driver?  It could be better to use the generic driver as Microsoft would ensure conversion if compatible.  What are the variables that can be set within the port, USB or Serial, driver?  Check "Properties" through the Device Manager(Mangler)   If its own driver check the USB/Serial port output directly, before that software, to see if it is outputting 1 or 2 bytes per character.

You need to divert the raw scanner port output , and I mean everything, to a file.  Usually the port is a (virtual) USB or serial port but a real serial port is even better  Then use an editor that allows you to see the Hex codes.  This way you can observe the data as it arrived from the scanner and before data is modified by software.  Here you should try to determine what kind of data stream it is outputting.  Byte order may be revealed as important.

VEdit is one editor which can view files as Hex, binary, EBCDIC, and or display them with ASC-II and with CRLF and control characters icons.  The standard version handles 2 GB files, the 64-bit handles unlimited sized files.  Using these features you could edit dbf or index files directly from DOS, UNIX, and Macs OSs.  I've done this to fix crashed dbf's.

Next check the scanner's specifications to see how it is setup, 1 or 2-byte output.  Some will only produce 1-byte output.  The default setup could be for 1-byte character output particularly if it is manufactured in or distributed from the U.S.   

Just so you know, no matter what your doing with Microsoft Windows or the SDKs, everything underneath is UCS-2, two-byte.  Also from the article...

"...encodings of English text are Windows-1252 (the Windows 9x standard for Western European languages) and ISO-8859-1, aka Latin-1 (also useful for any Western European language). But try to store Russian or Hebrew letters in these encodings and you get a bunch of question marks. UTF 7, 8, 16, and 32 all have the nice property of being able to store any code point correctly..."

Once you are sure about the form of the data being received you can then step through the software until you reach Harbour.  If your are still having issues then return to this form to ask more questions.

Cheers
John S Wolter
------------------------

LinkedIn: johnswolter

- Mailto:johns...@wolterworks.com

- USA, Eastern Standard Time, -5 GMT, -4 GMT DST

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

[Adrian Semcheff]

Hello again.

Thanks for your response!

Windows applications take it as 2 bytes and "DOS". are taken as 1 byte. I do not know at what point they become.

Either way I would like to know how to make not ingnore Harbour.

In Visual Basic or Visual Fox, depending on the function it transforms into "?", But I see them. Although with that reached me!

Thank you again.

Adrian.

2012/10/3 john s wolter <johns...@wolterworks.com>

[Klas Engwall]

Hi Adrian,

> Windows applications take it as 2 bytes and "DOS". are taken as 1 byte.
> I do not know at what point they become.
>
> Either way I would like to know how to make not ingnore Harbour.
>
> In Visual Basic or Visual Fox, depending on the function it transforms
> into "?", But I see them. Although with that reached me!

Isn't all this rather irrelevant? The barcode reader is not reading text
but data. As I understand it, you are using a keyboard wedge which
inserts the barcode data in the keyboard buffer. If the receiving
application interprets the data as text and the data contains bytes with
ASCII values below 32, then your final result will be wrong.

You are apparently reading GS1-128 barcodes with multiple fields
separated by the GS character, which equals chr(29). Harbour's standard
get reader first handles various K_CTRL_* codes and navigation codes.
When all such special key codes are exhausted it checks if the code is
>= 32 and <= 255 and puts the code in the active get if so. So chr(29)
will be ignored.

As I said when you first asked about chr(29) in September the solution
is to write a custom get reader that does not skip key codes outside the
default interval.

The key handler is in the GetApplyKey() method of the HBGetList class in
src\rtl\getlist.prg. Subclass HBGetList into your own HBGetListBarCode
class (or whatever you want to call it). The subclass only needs one
single method, GetApplyKey(). Everything else can be used straight from
the superclass. Borrow the code from the GetApplyKey() method in
getlist.prg to your subclass and make the changes you need. You also
need a custom ReadModal() function, ReadModalBarcode() or something like
that, that uses your subclass instead of the default HBGetList class
(see src\rtl\getsys.prg), and you need to call that custom
ReadModalBarcode() function instead of the default ReadModal() that the
read command is preprocessed into.

In GetApplyKey() you should take special precations with the K_CTRL_HOME
key code (which is 29) and handle that key code right in that CASE if
the Ctrl key is not active. nShifts := hb_gtinfo( HB_GTI_KBDSHIFTS )
will get you the status of the various shift keys and hb_bitor( nShifts,
HB_GTI_KBD_CTRL ) will tell you if the Ctrl key is active. I use a
similar test to distinguosh beween K_CTRL_C / K_PGDN and K_CTRL_V / K_INS

I do not have all the GS1-128 key codes in front of me right now, but
there might be other special cases than 29 that also need to be handled
separately in GetApplyKey().

Regards,
Klas

[Adrian Semcheff]

Hello Klas!

Thank you again.

I tried to do what you tell me but I can not make it work.

In Clipper 5.3 had done something similar in getsys.prg and worked well.

I will keep trying.

Regards, Adrian.

2012/10/18 Klas Engwall <har...@engwall.com>

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.

Unsubscribe: harbour-users+unsubscribe@googlegroups.com
Web: http://groups.google.com/group/harbour-users

[Klas Engwall]

Hi Adrian,

> I tried to do what you tell me but I can not make it work.

Can you tell me which part of my suggestion did not work and what steps
you took to get to that point? Maybe there is something simple missing.

Regards,
Klas

[Adrian Semcheff]

Klas.

I think the problem is at a lower level, because what happens to get it is with the inkey(), both ignore the character. I watched the inkeyapi.c in ... \ rtl line 226 and find that there is problem. Rejects characters chars <32 or chars> 255 when it detects that it is unicode.

Remember that the get is based on inkey.

Sorry for my english!

Regards, Adrian.

2012/10/22 Klas Engwall <har...@engwall.com>

Regards,
Klas

[Adrian Semcheff]

Klas, correction: when it detects that it is NOT unicode (which is true).

Regards, Adrian.

2012/10/26 Adrian Semcheff <adriansem...@gmail.com>

[Klas Engwall]

Hi Adrian,

> I think the problem is at a lower level, because what happens to get it
> is with the inkey(), both ignore the character. I watched the inkeyapi.c
> in ... \ rtl line 226 and find that there is problem. Rejects characters
> chars <32 or chars> 255 when it detects that it is unicode.
>
> Remember that the get is based on inkey.

I do not have a keyboard wedge available here so I cannot actually test
reading a barcode, but if the line you are pointing to is relevant (it
only seems to measure the length of the string in case it were converted
to another CP), then none of the following would work either, as far as
I can understand:

proc main()
? inkey(0) // Type <Alt><Num2><Num9> or <Ctrl><Home> here
return

proc main()
hb_keyput(29)
? inkey(0)
return

And none of the control characters would turn up in the get reader
either. I modified my custom get reader to display the keycode value of
each character, and it displays 29 when I type <Alt><Num2><Num9> in a
get. I don't know how else to prove that it works.

I wrote a keyboard driver 30 years ago, so I know that the
<Alt><Num2><Num9><AltRelease> handling goes on entirely in the driver
and the final result, 29 in this case, is put in the keyboard buffer
after <Alt> is released just like 32 is put there when you press the
space bar. So the 29 that my little samples produce is real. It is only
a matter of handling it properly in the get reader.

And about CP conversion, BTW ... inkey() does convert keycodes in the
32-255 interval (for single byte codepages) to the VM codepage. So when
you enter data (as opposed to text in the VM CP) in a get, then do it
with a 437 CP like "EN" or your data may get corrupted. This applies to
<Alt><Num> sequences as well as barcode input.

Regards,
Klas

[Adrian Semcheff]

Hi Klas.

Yes, keyboard 'ABC' + ALT (29) + 'DEF', works perfect.

To emulate the problem with the scanner do the following:

With an old text editor (DOS), I do exactly the same thing: 'ABC' + ALT (29) + 'DEF', then do "copy" and "paste" from the editor to the habour program and it is the same, harbour ignores the chr (29), it is more, there is pause when "paste" remove the character.

But if I save the file with the old editor and open it with notepad and do 'copy' and 'paste' works perfect, one sees that translates notepad chr (29) to Unicode and therefore accepts habour.

Thanks, thanks, thanks!

Regards, Adrian.

2012/10/26 Klas Engwall <har...@engwall.com>

Regards,
Klas

[Klas Engwall]

Hi Adrian,

> Yes, keyboard 'ABC' + ALT (29) + 'DEF', works perfect.
>
> To emulate the problem with the scanner do the following:
>
> With an old text editor (DOS), I do exactly the same thing: 'ABC' + ALT
> (29) + 'DEF', then do "copy" and "paste" from the editor to the habour
> program and it is the same, harbour ignores the chr (29), it is

> more,there is pause when "paste" remove the character.

Are you saying that you paste it in a get in Harbour? If so, do you use
the standard get reader? You must use a custom get reader that does not
remove key codes below 32 and does not perform a <Ctrl><Home> when it
encounters a keycode 29.

> But if I save the file with the old editor and open it with notepad and
> do 'copy' and 'paste' works perfect, one sees that translates notepad
> chr (29) to Unicode and therefore accepts habour.

Notepad corrupts the data because it thinks it is Unicode text, then you
paste the corrupted data in the Harbour get. Sorry, but this makes no sense.

Regards,
Klas