Feature-request: split the strings.xml for in-device and settings related strings

App can't crash because you can't build it  (Undefined symbol ':StringSymbol' detected).

In my case, it can, because of the way I access the strings. I have

(:typecheck(false))
function loadString(string_id as Symbol) as String {
    return WatchUi.loadResource(Rez.Strings[string_id] as Symbol) as String;
}

And then I call loadString(:my_string), rather than WatchUi.loadResource(Rez.String.myString).

Each call to loadString generates much less code than the corresponding call to WatchUi.loadResource would have done (saves 5 bytes for the call itself, and 14 for the argument) - but yes, I guess it does have the downside that it subverts the compiler's undefined symbol checking.

But I'm curious how it works since it's from 4.2.x:

No device needs to know about the new "scope", because anything with that scope is left out of the .prg file. Settings still work because all the information about the settings is (and always has been) encapsulated in the MyApp-settings.json file (which is sent to the store in the .iq file).

App can't crash because you can't build it  (Undefined symbol ':StringSymbol' detected).

In my case, it can, because of the way I access the strings. I have

(:typecheck(false))
function loadString(string_id as Symbol) as String {
    return WatchUi.loadResource(Rez.Strings[string_id] as Symbol) as String;
}

And then I call loadString(:my_string), rather than WatchUi.loadResource(Rez.String.myString).

Each call to loadString generates much less code than the corresponding call to WatchUi.loadResource would have done (saves 5 bytes for the call itself, and 14 for the argument) - but yes, I guess it does have the downside that it subverts the compiler's undefined symbol checking.

But I'm curious how it works since it's from 4.2.x:

No device needs to know about the new "scope", because anything with that scope is left out of the .prg file. Settings still work because all the information about the settings is (and always has been) encapsulated in the MyApp-settings.json file (which is sent to the store in the .iq file).

good trick, probably I'll save less, because usually use

var s = Rez.Strings;

WatchUi.loadResource(s.myString).