Not Enough Arguments Error

Hi to all!
In one of my datafields I have the following code line:

dc.drawText(fieldWidth - 32, 138, f_XTINY, poMax.format("%0d"), textCenter);

where:
f_XTINY is Graphics.FONT_XTINY
poMax is taken from setup as Numeric: 100 to 500 limited
textCenter is Graphics.TEXT_JUSTIFY_CENTER | Graphics.TEXT_JUSTIFY_CENTER;

In some cases the above codeline throws an "Not Enough Arguments Error".
It never happened to me, but I can see seldom occurances in ERA.

What can throw this error?
I'm at my wits end...

  • you can have this kind of error if your poMax is empty.

    did you put 

    min="100" max="500" required="true"
    in your settings?
    if not, user can just delet the field and let it blank.
  • PS: try to leave it blank on your own settings and see if it happens

  • While Garmin Connect IQ does not allow the storage of a blank value, it is possible with Garmin Express and then leads to crash!
    Thanks for pointing out!

  • This is what I call "suspenders and a belt" where you can try to avoid it in setting, you may also want to check that it's what you expect in your code.  In the new developer FAQ, you'll see a work-around for a bug when a Number showed up as a string in the app.

  • There used to be a bug in the Garmin Connect app (before the separate store app existed) where if a field was defined as numerical and you entered a non numerical value, the app would allow you to press the Save button, and your CIQ app on the device would receive all null values. This isn’t relevant anymore, at least in the Connect IQ Store app (I’ve heard that some very old devices still use Garmin Connect for CIQ settings), but it’s another data point concerning bugs and unexpected behaviour around settings. 


    https://en.wikipedia.org/wiki/Robustness_principle

    In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept


    One downside to this principle is increased memory consumption due to additional code. In the case of the “all null settings” quirk I mentioned above, not only did I have to write code to do null checks, I also had to hardcode settings defaults in my app code itself (in addition to the defaults in the resources). For obvious reasons, “don’t repeat yourself” is another important principle in computing, but I had to violate it in order to avoid crashes. All of that is to say your code will never be perfect and there will always be compromises. 

  • Many thanks to you all for your input!

    Strange thing is: I have had coded a null check for the variables taken from setup, but it turned out: a blank numeric field in setup is not null. It is „nothing“… (don‘t know, what it is really…)

    But required=„true“ seems to do the trick.

    PS: It's hard to believe the errors users make when inputting setup... but I‘m learning!

  • Strange thing is: I have had coded a null check for the variables taken from setup, but it turned out: a blank numeric field in setup is not null. It is „nothing“… (don‘t know, what it is really…)

    Is it possible that it's an empty string ""? This goes back to Jim's point about how a numerical setting may not necessarily receive a Number value.

    PS: It's hard to believe the errors users make when inputting setup... but I‘m learning!

    This is a huge part of the robustness principle. You absolutely cannot assume your users won't make mistakes (or that they won't be malicious). You also can't assume the platform you develop on doesn't have bugs.

    Arguably, a well-behaved and user-friendly app should *assume* users will make mistakes and take steps to either prevent those mistakes from happening in the first place or to fail gracefully when mistakes do happen.

    e.g. In the past, I could make an old Garmin device enter an endless reboot loop if I had an array out-of-bounds error in my CIQ code. (In this scenario, I as a CIQ developer am the "user"). Was that a mistake on my part? Absolutely. Is it reasonable for a device to reboot forever if a 3rd-party has a simple bug like that? I don't think so. Anyway, to their credit, Garmin eventually fixed that problem.

  • PS: It's hard to believe the errors users make when inputting setup... but I‘m learning!

    are you new to this? I mean I used to code app for my company, ask a user to put his birthday, he will put his name etc... everyone can be distracting or missread etc

  • are you new to this?

    No - I‘m programming for many years, but I did it for my own (film subtitling) company - and yes: I started with Monkey C 7 months ago and I‘m programming for other people the first time.

    Is it possible that it's an empty string ""?

    The above mentioned var poMax is declared as Numeric in settings and is declared Numeric in view.mc. But when it is read as blank from setting into view.mc it behaves like a empty string. It is not null, but it seems to be nothing else but „nothing“.