Data Fields - Has anything changed?

Hi,

Has anything changed recently in the device firmware's in regards to Data Fields?

I am getting a string of users contacting me, on what started as the VAHR and now Edge devices, reporting they don't work. The Data Fields are long established ones (over a year old) and I haven't made any recent updates.

In the CIQ_LOG.TXT they get an Exception in compute, with a stack trace of null.

When I ask them to use a Test Build, it works perfectly, and generates no helpful Log.

I have a VA, Fenix 3 and Edge 1000 and can't repeat.

Any ideas?

Cheers
Chris
  • Hi,

    I've been waiting on some more information from a couple of other developers on similar issues. I will create a separate ticket for your because the log info sounds a little different, but it would be great if you could get the log from the user and send it to [email][email protected][/email] for me to dig into.

    Thanks,
    Coleman
  • Thanks Coleman - I've attached the log

  • Thanks Coleman - I've attached the log



    Perfect. Thanks you for that. I've attached it to the ticket. could you send me a link to the DF in the app store so I can try it out on a device as well? The log also showed an unhandled exception. Are you doing anything out of the norm in the compute section of your code?

    Thanks,
    Coleman
  • Ok, I have found some more information from some helpful Users. I can't confirm this, as the Test Build behavior differs from the Release Build and I can't repeat. However....

    I have a property of type Float. On some devices, this is not a float on when read from the property, so actions like multiplication fail with an exception. I am also checking for null. In addition users are reporting that a values are gaining .000000 at the end, so if they save 162, when editing settings later, they see 162.000000

    Again I can't repeat on my Fenix 3 HR, VA and Edge 1000

    Does this help?

    Cheers
    Chris
  • Just a guess, but it may not be the device you are running on, but what's used for settings. (GCM/Android, GCM/iOS, GCM/WP, GE), as there have been other cases where GCM/A for example, returned a float when it should have been a number. Maybe the a GCM/A update tried to fix that and now it returns a number when it should be a float? That could explain why it just started happening with your DF.

    See this thread (#10 in the post) as it talks about type checking for settings. If you are expecting a float and get a number maybe you can just do a toFloat() if you get a number.

    https://forums.garmin.com/showthread.php?359183-New-Developer-FAQ-2


    If you find out a common GCM type/version is used for settings, that would get the ticket for this pointed at the GCM group responsible.
  • Thanks Jim, you're a star, I think you've got it spot on.

    Interesting point, the user is setting an exception when I try and convert the value 162.00000 using .toNumber()

    Thoughts?

    Cheers
    Chris
  • f=162.000000;
    n=f.toNumber();

    works fine in the sim.

    Or is it only something that happens on the device itself? Could it be that in settings you think it's 162.000000, but with an odd type conversion error with GCM you are seeing something like 162000000 instead? (maybe add a range check to your type check?)
  • A thought on something you might try. (disclaimer: I've not done this myself, but I think it should work!)

    The user that's having the 162.000000 problem. Have the user send you their .set files (or just the one for your DF if they know which it is - if not, you should be able to file dump the .set files and find the ones with your keys in it). Rename it so that it matches the .prg you run in the sim, and put it in the settings directory in the temp folder used by the sim. That way you might be able to run the sim, using what they have for settings and debug what's happening.
  • f=162.000000;
    n=f.toNumber();

    works fine in the sim.

    Or is it only something that happens on the device itself? Could it be that in settings you think it's 162.000000, but with an odd type conversion error with GCM you are seeing something like 162000000 instead? (maybe add a range check to your type check?)


    Yes, I tried faking in the Sim and worked a treat. I also tried entering 162.000000 on my devices. All okay.