Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Number Format Exception #1

Open
Gasman2014 opened this issue Nov 28, 2016 · 7 comments
Open

Number Format Exception #1

Gasman2014 opened this issue Nov 28, 2016 · 7 comments

Comments

@Gasman2014
Copy link

Installs and runs OK. Accepts login details but does not remember server details. Brings up camera scanner window and allows scanning - and identifies barcode number but immediately fails with a

java.lang.NumberFormatException during partscannrapp.ContinousCaptureActivity.

On a spare Android phone that I don't want to set up mail on so can't send entire error message

Android 5.1.1 / Kernel 3.10.49

@mdrobisch
Copy link
Contributor

I will fetch the exception in the upcoming release and make the the server details persistent.
I add some further imformation of valid barcode-tags in the documentation. I hope this helps to get it working.

@Gasman2014
Copy link
Author

Gasman2014 commented Nov 29, 2016 via email

@JelleDijkhuizen
Copy link

Are you still working on this?

@Gasman2014
Copy link
Author

Sorry for such a late reply - this had been on hold for a while but I have now revisited this as I have spent a long while reorganising my components. In the process, I have renumbered my parts to use the internal id which actually makes life much easier!

I would like to be able to get this to work with Partkeepr/Scannr AND with a keyboard 'wedge' scanner.

Background
I followed the instructions at https://wiki.partkeepr.org/wiki/Barcode_Scanning/Configuration but chose to use '#' to prefix my part numbers and '$' to prefix all my locations. This is to facilitate using a keyboard 'wedge' scanner. If I scan a barcode which commences with a # and the part doesn't exist, it will create it or, if the part does exist the main window will show that part. Similarly, if the scanned value begins with $, the main window will show all parts at that location.
In that these are fairly standard instructions, I think some sort of setup like this could be quite common amongst PartKeepr users.

In the past I had a separately generated part number for all my components but realised this was not a good plan. I have now renumbered all my parts to be like '#375' (where 375 is the internal part number).

With the new part numbers and location numbers (e.g. $01-01), my keyboard wedge scanner approach as per the wiki works perfectly BUT I cannot use your app as it balks on the # or the $.

Would it be fairly simple to accommodate these prefixes (or any other user prefixes)?

@Gasman2014
Copy link
Author

I had some further thoughts. You only have to make an allowance for a scan result that begins with the 'part' prefix.
I have had a poke around in the code. I see there is a mPartPart which is an integer and defines the search item. Would it be very difficult to add a preference for a 'part prefix character' - in my case '#' and, if this is set and the scan result returns this as the first character, strip this off first and cast the result as an integer? This would need the scan result to be a string in the first instance.
I have zero experience with Java/Android - if this was Python I might have been able to have a stab at this but I wouldn't know where to start here.

@Gasman2014
Copy link
Author

I gave in and renumbered all my parts - the renumbering wasn't too bad but I do now have a lot of new labels to stick on.
Now it works. Thank you.
One minor niggle - also have some other barcodes (e.g. for location which start with a $) - if I accidentally scan one of these I get an exception and the app crashes. Could this be felt with in a more forgiving manner?

@JelleDijkhuizen
Copy link

Hi @Gasman2014 and @mdrobisch,

The problem with the java.lang.NumberFormatException also happens when you use a EAN-13 number or a string in @Gasman2014 case. To fix this just handle to output from the barcode reader as a string instead of an integer. I will make a pr to change this.

i also found a few other things for those i will make separate issues and pr's

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants