I have had an experience with a customer in whose stores the employees use Android Zebras TC51 for store operations.
We have installed V:Link in those PDAs and we have realised that automatic enter/carriage return after using the barcode scanner of the PDA is not executed because V:Link does not create an automatic profile in datawedge.
For the matching process there is an easy workaround which is clicking on the "Save" button, but using the V:Link PRO functionality to search a label and manage the details of this one (the magnifying glass in the middle of the app) there is no "Save" button or similar so it's not possible to use this.
The client states that much of the apps they use on the PDA create the datawedge profile to configure this action or others automatically and they don't see the reason why our app doesn't do it.
Besides, it's not feasible to create the profile manually in every app for all the PDAs used in several stores so I don't know if someone has had any similar experience with this issue.
I'd like that V:Link could create the profile automatically gaining different advantages when using a barcode scanner like this automatic carriage return execution, removing useless spaces, etc.
Steps I did for the manual creation of the profile (in case it's useful for someone) for the automatic carriage return:
Go to the Datawedge app
Create a new profile for V:Link
Go to "Associated apps", look for V:Link logo and select it
Select "*" to include every activity or select specific activity
Go to “Keystroke output” section
Click the “Enabled“ checkmark
In “Action key character“ select “Carriage return”
Go to "Basic data formatting"
Enable the "Send ENTER key" option
You can now exist Datawedge and use VLink
Thank you in advance.
After scanning a product, now it's needed to press enter, or manually save the matching, what is very time consuming. I.e., when you scan a label, it's automatically saved and moved to an item scanning part. When you scan an item, you need to manually confirm a matching. We have some workaround for that now, but would be nice to have this natively - as there is an issue with massive deployment of a workaround (and it's not possible to implement it manually to bigger amount of devices).