The function equals has bug when operand contains non-ASCII?

li2niu over 5 years ago

https://youtu.be/xzEiET8Z-UY

As the video. I have two menu items, Count(计数) & Time(计时).

In English mode, I can select Count to choose from 100 to upper and select Time to choose from 1 to upper.

However, when I switch language to Chinese, the two items are the same(the pickers are both Time pickers). Why?

I don't own a physical device that supports Chinese, so I have no idea about the actual running status.

Top Replies

Travis.ConnectIQ over 5 years ago +2

The mention of Menu2 in this thread is completely misleading. The menu items are picked based on position (where you tap for a touch device or the centered item on a button device). The issue is with the…
li2niu over 5 years ago in reply to jim_m_58 +1

jim_m_58 said:
APAC and ROW devices are different HW and Part numbers, You can't add Chinese to a ROW device.

Yes, I know that.
li2niu over 5 years ago in reply to jim_m_58 +1

Yes, I am sure it is a bug about the function equals. Maybe the function hashcode inside the String doesn't support a non-ASCII character.

All Replies

li2niu over 5 years ago in reply to flowstate

flowstate said:
who knows if it's also a problem on a real device)

Yes, it happened on a real device as well. My colleague told me that several hours ago.

li2niu over 5 years ago in reply to flowstate

I failed to use

item.id

to compare before. So I have to use another English label. id is a hidden property.

It should be

item.getId().

It is more elegant.

You do inspire me.

jim_m_58 over 5 years ago in reply to li2niu

Maybe it's related to Chinese characters being 16 bit vs 8 (UFT-8)

flowstate over 5 years ago in reply to li2niu

Yes, exactly.

I think you realize this, but you just need something like:

function onSelect(item) {
    var id = item.getId();
    if (id == :time) {
        // push time view
    } else if (id == :number) {
        // push count view
    }

Travis.ConnectIQ over 5 years ago

The mention of Menu2 in this thread is completely misleading. The menu items are picked based on position (where you tap for a touch device or the centered item on a button device). The issue is with the string compare being broken, and this exposes itself because the app itself is using the name to identify the menu that is picked.

I'm pretty sure the bug you're seeing is the same as this one that has already been reported:

https://forums.garmin.com/developer/connect-iq/i/bug-reports/bug-in-compilator-with-string-equals-and-utf8-symbol

li2niu over 5 years ago in reply to flowstate

Why should I use ‘==’ rather than ‘equals’

flowstate over 5 years ago in reply to li2niu

Because the ID is a symbol (as in your sample code), and you're comparing it to the symbols :time and :number. You don't need to use equals() to compare symbols.

It will be slightly faster, and consume slightly less memory in code.

Travis.ConnectIQ over 5 years ago in reply to jim_m_58

jim_m_58 said:
Here's simplified Chinese with Gregorain Info.

jim_m_58 said:
Notice the characters aren't Chinese

This is a totally separate issue. There was a bug with the tram slated weekday/month name strings in the simulator. The data was written as wide character strings (UTF16 on Windows, UTF32 on Mac/Linux) and was being treated as UTF8.

You can display Chinese/Japanese/Korean/... text in the sim. As with anything else, the font needs the glyphs and the string has to be encoded properly.