• Replies 42 replies
  • Subscribers 19 subscribers
  • Views 4949 views
  • Users 0 members are here
Options
Related

Eclipse > VSC: Symbol Not Found

chrishares
over 2 years ago

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

  • over 2 years ago in reply to FlowState

    Instead of DeviceName, try something unique like "_DeviceName" or "MyDeviceName" (both in the resource file and your code.) Maybe that will fail to compile.

  • over 2 years ago in reply to FlowState

    In case you want full git control, one could opt for submodules...? The code is shared and you need some minor tooling around it but you have both the "link" and the file locally in your tree.

    The biggest issue is probably keeping all the submodules in sync across 50 projects.
    Than again, this would probably be a good starting point to look into reorganzing code to be both more barrel-able and linkable. I think some of the linked files is better of in a barrel. But those files cannot use the main project's code, it has to be more generic and let the project deal with the specifics.

  • over 2 years ago in reply to waterkip

    Yeah I use submodules for a couple of projects that are in different repos but have significant shared code.

    One problem with that is you can't pick and choose what you want from the submodule and keeping stuff in sync would be a problem if shared across many projects as you said. In some ways, the fact that a submodule is versioned is a good thing tho. (In my case, where it's just one submodule shared by two projects, it's nice because the version of the submodule is pinned and I control whether I get the latest stuff or not.)

  • over 2 years ago in reply to chrishares

    If the resoure is in your barrel, with a Module like

    Module MyMod {

    You don't use just Rez, you use MyMod.Rez.

    Barrels also add overhead and aren't supported on all devices, which is why I tend to just use the mc files as shared files and not as Barrels.

  • over 2 years ago in reply to FlowState
    FlowState said:

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

    I'm not saying you have that. I'm saying that this approach can cause additional files that aren't consumed by the project still get compiled into the project. Given two classes in the shared source directory and you only use one of them. This causes your project to compile both of them into the .prg

  • over 2 years ago in reply to waterkip
    waterkip said:
    I'm not saying you have that. I'm saying that this approach can cause additional files that aren't consumed by the project still get compiled into the project. Given two classes in the shared source directory and you only use one of them. This causes your project to compile both of them into the .prg

    I understand that. I'm saying that because my shared code isn't general-purpose (it's app-specific), I don't have that problem.

    And I suggested that if you do have that problem, the solution is to symlink to individual files and not folders.

    But again, either way (symlink folder or symlink individual files), you still have various issues. It's not nearly as seamless as Eclipse links.

  • over 2 years ago in reply to jim_m_58

    The problem is that they try to use the main project resources and not the ones in the barrel.

  • over 2 years ago in reply to FlowState

    Another option: Docker! Or Docker Compose.

    You can add a source/resource path for your links and in your docker-compose.override.yml you can copy those files into the desired location and boom. Runs.

    I use a similar approach for including my barrels into projects. 

  • over 2 years ago in reply to waterkip

    That's an interesting solution but then you obviously can't do everything from within VS Code, such as open a project, see all the relevant source files, run the app, etc. (I realize that's not a concern for you.)

    If you're already ok with not having absolutely everything work in VS Code, then symbolic links work just as well as this solution. Docker is great but there's a bit of overhead.

    (I use the command line for a lot of git stuff, but it would still be nice to have working IDE-level source control stuff, like diffs, annotations, etc.)

    EDIT: you could even combine the git submodule approach with the symlink approach, if you don't want to put all your projects in a monorepo.