Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Is it pososible for VFP to access camera and read qr code? 2
- Thread starter Mandy_crw
- Start date
Chris Miller
Programmer
No, there's nothing built into this. It seems most smartphones have built it into their camera app to detect QR codes and decode their encoded value.
You can get a picture from a webcam or notebook inbuilt cam, for example, but as VFP does not run on smartphone OSes like Android or iOS and even not on the mobile Windows versions Microsoft smartphones had, which MS stopped doing, your only chance in that domain is the only device platform that's overlapping, a tablet with a normal Windows OS (not just the Windows RT version) and a webcam including an app for it that has that feature of decoding QR:
For a desktop device, you'd need to stitch several things together:
A) getting an image from a webcam: Possible
B) use a library or online service for decoding an image of a QR, also a skewed one like its coming from a cam, to decode it. I don't know something like that.
A complicated solution I could think of is actually using any phone with that inbuilt function, which allows to send the decoded QR code via mail, then receive that in VFP. Surely not something you'd want to use if, for example, you'd want to scan QR codes in a POS/cashbox system.
For normal line barcodes there are barcode scanners as devices that decode the barcode and emulate a keyboard, so this can be used to get the decoded barcode as keyboard input into any normal textbox. You'd need such a device capable to also decode QR, maybe that's the best solution. So, for example POS system hardware could have that feature. They usually have a scanner built into the cashier desk at the end of the conveyor belt. I've not yet seen price tags using QR codes in any market, not even in a hardware store, which could make use of the QR code capabilities. They all still use line barcodes like GTINs.
Anyway, the essence is, you should never start building code that analyzes an image in VFP, the Foxpro language is not built for that kind of image processing, that should come from a library specialised on imageprocessing. You could contribute reading out the cam picture. I found this on tek-tips: thread184-1730529
It's still not even 50% of the task, though, as a cam doesn't give you a single image only, you would need to read a series and decode all of them, as many images will be blurry and not decodable and even if you get a decoding, it might be wrong, so you'd need to ensure at least two or three decoding have the same result to be sure that's what the QR code encodes. Again, the simplest solution will be a device that does all this without needing to mediate between a webcam and a QR image decoder.
Chriss
You can get a picture from a webcam or notebook inbuilt cam, for example, but as VFP does not run on smartphone OSes like Android or iOS and even not on the mobile Windows versions Microsoft smartphones had, which MS stopped doing, your only chance in that domain is the only device platform that's overlapping, a tablet with a normal Windows OS (not just the Windows RT version) and a webcam including an app for it that has that feature of decoding QR:
For a desktop device, you'd need to stitch several things together:
A) getting an image from a webcam: Possible
B) use a library or online service for decoding an image of a QR, also a skewed one like its coming from a cam, to decode it. I don't know something like that.
A complicated solution I could think of is actually using any phone with that inbuilt function, which allows to send the decoded QR code via mail, then receive that in VFP. Surely not something you'd want to use if, for example, you'd want to scan QR codes in a POS/cashbox system.
For normal line barcodes there are barcode scanners as devices that decode the barcode and emulate a keyboard, so this can be used to get the decoded barcode as keyboard input into any normal textbox. You'd need such a device capable to also decode QR, maybe that's the best solution. So, for example POS system hardware could have that feature. They usually have a scanner built into the cashier desk at the end of the conveyor belt. I've not yet seen price tags using QR codes in any market, not even in a hardware store, which could make use of the QR code capabilities. They all still use line barcodes like GTINs.
Anyway, the essence is, you should never start building code that analyzes an image in VFP, the Foxpro language is not built for that kind of image processing, that should come from a library specialised on imageprocessing. You could contribute reading out the cam picture. I found this on tek-tips: thread184-1730529
It's still not even 50% of the task, though, as a cam doesn't give you a single image only, you would need to read a series and decode all of them, as many images will be blurry and not decodable and even if you get a decoding, it might be wrong, so you'd need to ensure at least two or three decoding have the same result to be sure that's what the QR code encodes. Again, the simplest solution will be a device that does all this without needing to mediate between a webcam and a QR image decoder.
Chriss
- Thread starter
- #3
Chris Miller
Programmer
I find that QR handscanners ar an available hardware device type, and I'm not surprised.
Chriss
Chriss
-
1
- #5
tomk3
Programmer
Hello,
I agree with Chriss.
We use hardware barcodescaners since many years.
If you get a "HID-Version" of a scanner, it acts like a keyboard.
So you get the content of the barcode directly into VFP, fox example in a textbox ("as if typed")
Btw.
If you want to print the barcodes by yourself (for example in stock) and read it elsewhere (on truck) :
For small content like serial numbers, another barcode type (2D, like 3of9 , code128,..) may be better because it usually takes less space.
There is a fantastic barcode generating lib for 2D and QR for VFP :
Best regards
tom
I agree with Chriss.
We use hardware barcodescaners since many years.
If you get a "HID-Version" of a scanner, it acts like a keyboard.
So you get the content of the barcode directly into VFP, fox example in a textbox ("as if typed")
Btw.
If you want to print the barcodes by yourself (for example in stock) and read it elsewhere (on truck) :
For small content like serial numbers, another barcode type (2D, like 3of9 , code128,..) may be better because it usually takes less space.
There is a fantastic barcode generating lib for 2D and QR for VFP :
Best regards
tom
- Thread starter
- #6
Thank you tom.. my app waits an i put from user (idnum) then shows name and surname plus the picture… so im thinking of integrating qr code… instead of inputing idnum… just a thought though… but you have given a light tom… thank you so much Chriss and Tomk3
Nigel Gomm
Programmer
Mandy,
it may be possible through the WinRT. There's a session coming up at FoxFest. There's no mention of cameras or QR codes in the session description but i'm sure questions will be asked during the session. If it is possible it will likely involve C#.
hth
n
it may be possible through the WinRT. There's a session coming up at FoxFest. There's no mention of cameras or QR codes in the session description but i'm sure questions will be asked during the session. If it is possible it will likely involve C#.
hth
n
Chris Miller
Programmer
It's doable to have barcodes on an id card or such if you'd use this as login or for an attendance recorder or something like that. Or as entrance check for concerts or conferences.
A 1D line barcode would be sufficient, there's no real need for going QR, as one ID like a user ID can be your key for any further detail info about that person, no need to have that in the QR code, if you thought of it. Handsacnners scan in 1D codes extremely fast, I think it's why they are still so popular for product scanning in POS systems, it's lightning-fast to scan.
I haven't had a hardware QR scanner. With the usual phone cameras app, I only had experiences that were less effective, as the QR code has to be focused, while scanners work with a laser that scans the code making almost no difference whether you scan it closely or far away, rotated or not. And yes, there are those smeared codes that don't scan in even after many tries, I think everybody knows these cases from your grocery shopping alone. But overall it's just a matter of printing them sharp and in high contrast and then protecting them from becoming smeared.
The only experience with QR code scanning I had was for train tickets and, well, they had monstrous scanners that also use laser scanning, on an area instead of just along a line, obviously. And that was also fast and reliable.
Like with any products today, I guess you find some tests, reviews and demonstration videos about them to judge for yourself what you like. I'm also not sure whether it's still so much cheaper and more reliable to only need 1D scanning.
Chriss
A 1D line barcode would be sufficient, there's no real need for going QR, as one ID like a user ID can be your key for any further detail info about that person, no need to have that in the QR code, if you thought of it. Handsacnners scan in 1D codes extremely fast, I think it's why they are still so popular for product scanning in POS systems, it's lightning-fast to scan.
I haven't had a hardware QR scanner. With the usual phone cameras app, I only had experiences that were less effective, as the QR code has to be focused, while scanners work with a laser that scans the code making almost no difference whether you scan it closely or far away, rotated or not. And yes, there are those smeared codes that don't scan in even after many tries, I think everybody knows these cases from your grocery shopping alone. But overall it's just a matter of printing them sharp and in high contrast and then protecting them from becoming smeared.
The only experience with QR code scanning I had was for train tickets and, well, they had monstrous scanners that also use laser scanning, on an area instead of just along a line, obviously. And that was also fast and reliable.
Like with any products today, I guess you find some tests, reviews and demonstration videos about them to judge for yourself what you like. I'm also not sure whether it's still so much cheaper and more reliable to only need 1D scanning.
Chriss
- Thread starter
- #9
tomk3
Programmer
Hello,
if you want a personalized version with individual cards like Chris described (entry cards) you can also get RFID scanners using HID.
We store the individual serialnumber of the card when its given to a guest and check it. For VFP it is like input via Keyboard.
Regards
tom
if you want a personalized version with individual cards like Chris described (entry cards) you can also get RFID scanners using HID.
We store the individual serialnumber of the card when its given to a guest and check it. For VFP it is like input via Keyboard.
Regards
tom
- Thread starter
- #11
-
1
- #12
Chris Miller
Programmer
HID is short for human interface device. And the usual ones are mouse and keyboard only.
Specific things like scanning barcodes or RFIDs only in themselves are not human input devices, even if the devices are handscanners, usually a human still is involved in holding the barcode over a camera or at least holding a RID or anything that is the actual input near to a device registering it. Same goes with a reader for smartcards.
This recognized RFID, smartcard data, nbarcode or whatever it is, is then often turned into a input that emulates a keyboard, so it's a virtual HID, a virtual keyboard input and on the interface design and in your side of programming, you don't need to learn special DLL functions, don't need to program waiting for some events, to you it's just keyboard input, as if someone typed in the info of the barcode or RFID or smartcard. You only need a tet or editbox and no special programming, that's what makes it simple for us as developers, as we just need to provide things we usually also provide for use of human users.
In the end tom just meant to say good news, nothing special about this, for your code you can do as if whatever code came from keyboard entry of the data.
Chriss
Specific things like scanning barcodes or RFIDs only in themselves are not human input devices, even if the devices are handscanners, usually a human still is involved in holding the barcode over a camera or at least holding a RID or anything that is the actual input near to a device registering it. Same goes with a reader for smartcards.
This recognized RFID, smartcard data, nbarcode or whatever it is, is then often turned into a input that emulates a keyboard, so it's a virtual HID, a virtual keyboard input and on the interface design and in your side of programming, you don't need to learn special DLL functions, don't need to program waiting for some events, to you it's just keyboard input, as if someone typed in the info of the barcode or RFID or smartcard. You only need a tet or editbox and no special programming, that's what makes it simple for us as developers, as we just need to provide things we usually also provide for use of human users.
In the end tom just meant to say good news, nothing special about this, for your code you can do as if whatever code came from keyboard entry of the data.
Chriss
- Thread starter
- #13
oh... Thank you Chriss for always taking time to answer all my questions.... my app is already being used... although sometimes it shows the error "cannot access cursor" but it is now usable.... Thanks to you and all people in this forum.... God bless....
- Status
