Here are a few Complication samples

If you look at the sample I linked to, in the View's initialize(), I have 

        //check for complications
        hasComplications=(Toybox has :Complications); 
        if(hasComplications) {
            hrId=new Id(Complications.COMPLICATION_TYPE_HEART_RATE);
            if(hrId!=null) {
                hrComp = Complications.getComplication(hrId);
                Complications.registerComplicationChangeCallback(self.method(:onComplicationChanged));
                Complications.subscribeToUpdates(hrId);        
            }
        }

And here's the callback:

    function onComplicationChanged(id as Complications.Id) as Void {
        if(id.equals(hrId)) {
            curHr=Complications.getComplication(id).value;
        }

    }

I have

jim_m_58 said:

I have

import Toybox.Complications;

if I comment out that import, type checking throws an error. 

ERROR: fr965: C:\Users\James\workspace-prod\ComplexWF\source\ComplexWFView.mc:204: Cannot resolve type 'Complications.Id'.

With it, no problem with type checking on

That's not a type checking error, as simply commenting out "import Toybox.Complications" (without adding the corresponding using statement) will cause that error whether or not type checking is enabled. That's just a classic name resolution error.

If I go back to SDK 3.2.5 (which does not include type checking or import), and try to build the following code without using Toybox.Time...

var t = new Time.Duration(30);

...I get the following error:

Unable to detect scope 'Time.Duration' for the symbol 'initialize'.

If I do the same thing with a newer SDK that has type checking (even if type checking is disabled), the following error is returned:

Cannot resolve type 'Duration'.

Yeah, the wording of the error message changed and it has the word "type" in it, so it's natural to assume that it's literally a type checker issue, but actually it existed before type checking was added to CIQ, and it exists even when type checking is disabled.

Monkey C has always required modules to be included with using or import before you can use the associated symbols, except maybe for certain modules which are implicitly included, like Toybox.Lang.

jim_m_58 said:

If I change the import in my code to "using", I get this error:

ERROR: fr965: C:\Users\James\workspace-prod\ComplexWF\source\ComplexWFView.mc:86,12: Cannot find symbol ':Id' on type 'self'.

That's because of the following code which references the Id type without the Complications module prefix:

hrId=new Id(Complications.COMPLICATION_TYPE_HEART_RATE);

If you look at the github repo that I was discussing with the other poster, there are no type references without module names. All the type references are fully qualified, which is why import is unnecessary.

I can make one very simple change to your code to get it to compile with "using Toybox.Complications" instead of "import Toybox.Complications":

hrId=new Complications.Id(Complications.COMPLICATION_TYPE_HEART_RATE);

You see, there are two differences between "using" and "import", both of which are documented.

- using allows defining an alias for a module with as, import does not

- import allows type names to be used without the module name (e.g. Lang or Complications), using (usually) does not.

To be fair, there is a strange quirk where new Id(...) will compile and run with using Toybox.Complications, but only when type checking is disabled, so I can see how that would lead one to the conclusion that using doesn't work with type checking. However, that doesn't change the fact code can have using statements with the type checker enabled, as long as types are fully qualified.

All of this is why I said it doesn't make sense for one person to post code and another person to use different code to explain why the original code is wrong. The original code had an issue causing a type check error which had *nothing* to do with using vs import.

I wouldn't have used the tone I did if the reply wasn't both condescending and incorrect. Sorry, but if someone is going to talk down consistently, it would really help to be sure they know what they are talking about. It's not just about how I feel about the reply, it's also the fact that it's a form of misinformation. I'm a big fan of trying to understand how and why things actually work, not just relying on received wisdom and blanket statements.

Of course we can agree that Garmin seemingly prefers import over using now. Doesn't mean that all code which still references using cannot be compiled with type checking enabled.

Hey folks I’m glad these examples kicked off this conversation, I really love this community!

It has highlighted how buggy my initial code was

I do have an updated and more complete example I’ll post on GitHub shortly (ie; next few weeks). Should address the bugs, exception capturing, and unit conversion issues.