Eclipse > VSC: Symbol Not Found

Hi,

As per a previous thread, I am moving all my 50 projects from Eclipse to VSC.

I am getting a runtime error, which I wasn't getting previously

Error: Symbol Not Found Error 
Details: Could not find symbol 'DeviceName'

The resource file is, which is in a sub-folder.

<resources>
    <string id="AppName">hTemp</string>
    <string id="DeviceName">Vivoactive</string>
</resources>

It compiles and picks up the AppName ok.

Any ideas?

Thanks

Chris

Top Replies

All Replies

chrishares over 2 years ago in reply to _psx_

waterkip said:
I really like to see your barrel and your project, because I'm not able to wrap my head around your setup

I have a shared module, which includes a function (DeviceName) which pulls the device name from the string resources. This was a linked file .mc file in Eclipse, and is now a Barrel in VSC. Hope that helps.

jim_m_58 said:
The barrels are new with the move to VS C, correct?

As it's a simple function, I've moved the code in-line, and it works perfectly. So I've concluded it is Barrel related, and in the future need to find a way for a Barrel to access a host projects String resources.

_psx_ said:
You have to install one additional plugin before install ciq

I decided to make the jump now, as a Garmin Blog highlighted that they had stopped supporting Eclipse.

FlowState over 2 years ago in reply to chrishares

chrishares said:
In March, I was able to reinstall Eclipse, but a week ago, I couldn't get Eclipse to work as it I couldn't get the Garmin IQ Plug-In extension to install.

Does this help:

https://forums.garmin.com/developer/connect-iq/f/discussion/301452/eclipse-support/1460146#1460146

Personally I hate eclipse (I used it at work for years) and would never use it for any new projects (work or personal), but I can understand why you'd want to keep it around for existing projects. The only reason I keep Eclipse around is for CIQ.

FlowState over 2 years ago in reply to chrishares

chrishares said:
I have a shared module, which includes a function (DeviceName) which pulls the device name from the string resources. This was a linked file .mc file in Eclipse, and is now a Barrel in VSC. Hope that helps.

I think people are having trouble understanding how your project can compile properly but fail at runtime (not that it's your fault).

Anyway, I would do what Jim suggested and use a source directory override in your jungle file to include shared source code. Barrels aren't really equivalent to linked source files/folders.

If you were linking to individual source files in the past, you may have to reorganize them into separate folders.

Another possibility is to use symbolic links, but there's various issues with that (especially on Windows.)

chrishares over 2 years ago in reply to FlowState

FlowState said:
I think people are having trouble understanding why your project can compile properly but fail at runtime (not that it's your fault).

Thanks, can see it's difficult to understand. It's a massive project, and I have 50 Apps, which all share libraries (which is why this whole process is a nightmare!)

I would believe it compiles, as I guess it can see the string when compiling the Barrel (as referenced as a project). Maybe a bug in the compile process.

waterkip over 2 years ago in reply to chrishares

The barrel has no clue about your Rez.Strings in your main app. But I'm puzzled how it can compile. When I try to access the string resource from within a barrel is just dies and doesn't compile. So how you got that to compile and get a runtime error is a puzzle to me.

FlowState over 2 years ago in reply to chrishares

Yeah, it sounds like a nightmare.

I'm on Windows, and this is what I did for a couple of apps which have common source code, resources, and jungle content (I used to use links in Eclipse):

1) Changed developer settings in Windows so that elevation to administrator privileges isn't required to create symlinks

2) Changed my eclipse links to symbolic links

3) Changed VS Code settings to follow symbolic links for searches

Both of my apps already have sourcePath and resourcePath overrides in order to point to the linked shared content within the project folder.

e.g. My project folder looks something like this:

app/source

app/resources

app/monkey.jungle (barebones jungle - points to project manifest and sets any app-specific variables)

app/shared/source (symlink to common folder)

app/shared/resources (symlink to common folder)

app/shared.jungle (symlink to common file - has the bulk of the jungle content)

The thing which sucks about this solution (in Windows) is that git-specific features don't work properly in VS Code for linked content (e.g. I can't see line-specific source control information) and git diffs don't work at all (VS Code tries to compare the symlink to the actual linked file lol).

Other than that it works fine for me.

waterkip over 2 years ago in reply to FlowState

Doesn't that increase the size of your project for stuff that is common but not used on your project? Aka, the same as importing a full barrel instead of just the annotated bits that you need?

I remember/recall that being a problem for OP in a different thread.

FlowState over 2 years ago in reply to waterkip

waterkip said:
Doesn't that increase the size of your project for stuff that is common but not used on your project? Aka, the same as importing a full barrel instead of just the annotated bits that you need?

I remember that being a problem for OP in a different thread.

I don't have general-purpose libraries for my apps, I have common code that's shared between:

- A specific app that has both a device app and a widget version

- Data field apps which have multiple "clones"

One way around that would be to symlink only the files you need, as opposed to a whole folder.

The biggest issue with symlinks is the fact that VS Code doesn't resolve them in all circumstances (i.e. git/source-control stuff), at least under Windows.

chrishares over 2 years ago in reply to waterkip

waterkip said:
The barrel has no clue about your Rez.Strings in your main app.

I completely agree. Previously it was 'shared code' now it's external in a Barrel, so doesn't make any sense in the Barrel.

FlowState over 2 years ago in reply to chrishares

chrishares said:
. Previously it was 'shared code' now it's external in a Barrel, so doesn't make any sense in the Barrel.

Yeah, that's why I don't get how it compiles. It def sounds like a bug, unless...

...maybe :DeviceName is a symbol that's used by some Monkey C library. That's the only possibility I think of.

Kinda like how I was playing with some code and much to my surprise, code which looked like "SomeStandardClass has :foo" compiled even though I didn't have any methods, member variables or classes named "foo" in my code. There must be something in a Garmin library named foo.