I am currently working on a project that requires the output of a Code128 barcode to a QRP.
It's an older project ported from TD 4.1, it previously used a barcode.dll that doesn't work properly with 6.3.
Since I couldn't find a DLL that would work, I decided to try and use the Code128bWin project from the Sample Vault (https://samples.tdcommunity.net/index.php?dir=&file=Code128bWin.zip).
Now, the problem is, the function used there generates barcodes just fine, but they're not scannable and I can't figure out why.
I'm still fairly new to Team Developer, so maybe the problem is totally obvious and I'm just not seeing it, or maybe there is a simpler way to generate the barcode, but I've been stumped on this for days now, and getting nowhere.
I would be appreciative of any help.
Starting with the obvious - have you tried a UNICODE version of your 'barcode.dll' , as TD6.3 is UNICODE based, or maybe your existing one is UNICODE compliant, but 'not working properly' as you haven't changed your TD string parameters and buffer sizes to UNICODE in your api calls.
e.g. String: LPSTR becomes String: LPWSTR and also bear in mind SalSetBufferLength(20) before an api call will allocate 20 bytes of storage, but be aware that 2 of these bytes will be used as a null terminator. Therefore, to send /receive the barcode string '*4>HR\fpzg' you would need to give the buffer 22 bytes of storage. Could be why your existing dll is not working properly.
Related
I work with barcodes professionally so usually dive fairly deep into the specs.
But I have one thing that I have not been able to do so far. A datamatrix GS1 structured code may be separated by FNC1 or GS. The most common in professional label software is FNC1.
Two versions of the same code is below, encoding GS1 structure (01)03041094787443(21)5Qbag!(93)Zjqw
My question is to prove which separator is used, preferably using code (python or other, that's not very important).
I have tried using the free version of BCTester, but as specification goes, I get "GS" (0x1d) returned for both versions. Every mobile scanner same result, or no technical information at all. Data scans the same for both.
FNC formatted
GS formatted (created by zintQt)
Really hope that somebody will be able to help with this as I'm near losing my mind trying to understand why this happens.
I'm getting different results when scanning the same value in a Code 39 barcode using a regular USB barcode scanner and using my phone camera.
When scanning the value of 482168 using the barcode scanner, I get a value of 142673096 pasted into notepad;
When scanning the value of 482172 using the barcode scanner, I get a value of 142673122 pasted into notepad;
Values 482169 and 482171 are pasted correctly.
I thought initially that the problem was with the app that generates these barcodes, however, the same is happening when these are generated here https://barcode.tec-it.com/en/Code39FullASCII?data=482168
I thought that the length and width of the barcode may have been the problem, but adjusting them did not have any effect.
Has anyone ever stumbled upon anything similar and could suggest why these would be read and encoded differently?
I found this problem to be really interesting, so I compared the various barcode types to see what could be causing the scanner to mis-identify the barcodes. It turns out that Italian Pharmacode (also known as Code 32) is an exact match. Code32 is actually code39 using a compression scheme.
Here is 482168 in code39:
And 142673096 in code32:
It looks like your scanner is prioritizing code32 over code39. So you just need to disable code32 in your scanner.
I'm trying to work with some Visual FoxPro 9.0 code written years ago by programmers now long gone. There are several uses of ALLTRIM() that include a double-asterisk in front of the field name being passed, such as:
fred = ALLTRIM( **barney )
where Barney is a character field in a table. When I try running that line in a VFP session, it errors out with "Function is missing )". But I'm uncomfortable supporting code that I don't understand - what does the "**" do?
I've tried storing the field to a memvar, in case there's a SCATTER in the code that calls this, with no change in the resulting error. I've tried storing other data types (numeric and boolean) to the memvar, still no change. I've been programming in dBase, then FoxBase, then FoxPro, then VFP, for almost 35 years - and I don't remember ever coming across this before. And yet, the program runs without errors, I just don't understand what it is doing.
In case any of this matters, the code in question is stored in a memo field in a table, then invoked with an EXECSCRIPT() call. And some of the tables that the code is working with (but not the one containing the code) are SQL Server tables, accessed through cursor adapters - so "barney" in my example is very likely a field in a cursor adapter, not a .DBF.
I found my answer. Searching for asterisks in source code was useless, of course, because of comments. But I finally thought, after posting this question, of searching for the string with surrounding quotes, and found that, before the code I was looking at was called with EXECSCRIPT(), it was also run through STRTRAN(), which substituted "m." or "." or some other appropriate prefix for the "**" in the code.
So, the double asterisk was internal to the application, and meant nothing to VFP itself.
Recently I implemented a new object type to be stored in Core Data. A very simply object: "LikedObjects" with one data type called
"likedObjects". Here is a snippet from my Xcode project.
For whatever reason, saving the data did not work. It would ALWAYS return nil (when before implementing this it worked perfectly for the other, crossed-out entities).
SOLUTION:
I deleted and re-installed the app. Works fine. Changed 0 code.
My question:
Is it possible / a way for CoreData to corrupt? I want to know a potential reason for why deleting and reinstalling the app was a solution, so that if so I can prevent this in any way...
Yes it can. One of the reasons could be a line separator coming from a Windows app (CRLF) or an otherwise invisible character within the XCode editor, coming from copy & paste.
One way to get rid of these problems is moving the file outside the project and then add it as an existing file once again. The import/copy function does a decent job of cleaning unwanted code. If this does not help, then you will have to write a function which purges ASCII characters 0-26, exception made for code 11 (LF). If you have binary data though, it may not work!
Finally, a matching pair of keys and values may have gone havoc. There, you will have to paste one by one (pair), until you find the cause of grief.
I have two barcodes that I am working with. They are clearly different, but both scan as code 128. One is weird and one is normal. I have tried to reprint the data for the barcode in every way I can think of to I can see what subset (A, B or C) is being used.
For the normal one I know it is A for the first 10 chars then it changes the encoding to B.
I cannot seem to find out how to see what the encoding is on the other (weird) one.
I am using a symbol scanner. (I turned on the prefix char but that only told me D (Code 128)
Is there any tool to allow me to dig into the barcode symbologies?
I know very little about barcodes and zero about non-european ones, but for weird implementations of Code 128, there is also GS1-128.
This online barcode generator looks quite nice and can generate a lot of formats you might want to check against.
Chiming in late here, but the ZXing library (I'm a developer) reads Code 128. You could have it scan the barcode while you attach a debugger to the code. It would show you exactly what's happening, step by step, in the decoding, including subset changes.
I know the problem is fixed. But here's some more resource in case someone's in need :)
Like Pekka mentioned, a Code 128 have subsets like Code 128A, Code 128B, Code 128C and GS1-128(UCC/EAN-128). Here is more information on Code 128 barcode, with encoding pattern illustration.
Thanks for those that answered and commented.
Turns out the company that made our barcodes had a printing error. That caused the barcode to look different.
How it ever successfully decoded I do not know. Anyway. I am going to award the question to Pekka because he gave me a workable solution.