How to Access Monkeybrains Files?

Former Member over 9 years ago

Hi Connectors,

I have a bit of a quandry. After developing, testing, pushing to Git, AND sucessfully submitting to the Garmin App store. I come back later to further develop my watch face to this upon building:

Failed invoking <symbol>
UnexpectedTypeException: Expected Number/Float/Boolean/Long/Double, given null
initialize in C:\Users\Jeff\_my_garmin_workspace\GarminApps\CleanWatchFace\source\MyGridView.mc:23
draw in d:\1_2_1\mbsimulator\submodules\technology\monkeybrains\virtual-machine\api\WatchUi.mb:1498
onUpdate in d:\1_2_1\mbsimulator\submodules\technology\monkeybrains\virtual-machine\api\WatchUi.mb:604
onUpdate in C:\Users\Jeff\_my_garmin_workspace\GarminApps\CleanWatchFace\source\MyGridView.mc:141
Unhandled Exception
Unhandled Exception

I am looking less for debug help (unless someone sees something painfully obvious) and more for information on how to access the files marked in bold. I do not see them anywhere. My guess is that I am SOL and they are compiled into the VM, but thought I'd ask anyway.

Thanks,
Jeff

Former Member over 9 years ago

Ok now maybe a little debug help is in order:

I hit the exception I described earlier when I call (or somewhere within) View.onUpdate(dc):

function onUpdate(dc) {
...
//some other code
...
Sys.pritnln("checkpoint 1");
View.onUpdate(dc); //trigger exception here
Sys.pritnln("checkpoint 2");
...
//some more code
...
}

"checkpoint 2" is never reached; the exception fires instead.

I don't quite grasp the concept of calling onUpdate() from within itself so some insight here would be helpful.

Thanks as always,
Jeff

travis.vitek over 9 years ago

Yes, that code is compiled into the VM, and we have no access.

You aren't really calling onUpdate from within itself, you are calling onUpdate on the base class, which has the side effect of drawing each Drawable in the layout that you set when you last called setLayout. The exception is most likely happening because a Drawable doesn't have some member initialized. This could be due to an unspecified parameter in the layout definition, or failure to assign some default value to an attribute inside a custom Drawable.

It looks like the final frame of the stack trace is bogus. It isn't likely that you'd be dynamically initializing a MyGridView from within the draw() function of a Drawable.

Former Member over 9 years ago

Thanks Travis that all makes perfect sense and I'll look into those suggestions.

While I have you on the line, do you have any idea when we might get some more robust debug capability? I could have this licked already were I to just go and sniff out the offending drawable object. At the very least it would have been nice to have been included in the "stack trace", as is the case when an undeclared variable is used - the compiler will complain about those all day.

travis.vitek over 9 years ago

No, unfortunately I don't know. It does seem that the SDK is improving with respect to debugging, but it is a slow process.

Travis

Former Member over 9 years ago

I found the bug. I had inadvertently on purpose deleted my bin/*settings.json file as part of a clean up effort. Whenever I called App.getApp().getProperty("some_prop") there was no data to find, only null.

After commenting out those calls to getProperty(), a new settgins.json file was created and I was able to work from that.

Remember kids: don't delete settings files.

jim_m_58 over 9 years ago

Remember kids: don't delete settings files.

Actually, the best way to handle this is check for null when reading a property, as things do deleted in the real world too!

If you read a key and it's null, use a default.

lcj2 over 9 years ago

This post covers a great way to use settings and all the heavy lifting has been done for you: https://forums.garmin.com/showthread.php?341818-Issue-debugging-settings&p=795298#post795298

I have used it and it works well