1

I'm working on a project in VSCode and my folder configuration is currently laid out as the following:

  • workspaceFolder
    • bin
    • src
    • resources
      • music

When I build the project I have it specified in the tasks.json file as below:

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "C++ Program",
            "command": "cl.exe",
            "args": [
                "/Zi",
                "/EHsc",
                "/Fe:",
                "${workspaceFolder}\\bin\\theProgram.exe",
                "${workspaceFolder}\\src\\*.cpp"
            ],
            "options": {
                "cwd": "${workspaceFolder}"
            },
            "problemMatcher": [
                "$msCompile"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

This builds my 2 cpp files in /src and creates an exe in the /bin folder, as expected. What isn't functioning as I'd expect is the audio. I cannot figure out why the configuration I'd want (below) doesn't work.

Within the main .cpp file (path = ${workspaceFolder}\src\main.cpp) I have the following variable that is used by the windows.h mciSendStringW function:

wstring current_song;
current_song = L"../resources/music/song.mp3";

I would expect this to work - both the SRC cpp AND the program exe are located one folder beyond the resources folder, but the relative path doesn't seem to work.

I suspected the relative path was that of the workspaceFolder, so I tested changing the path to:

current_song = L"./resources/music/song.mp3";

and the audio still did not work when running the exe from the /bin folder. When I build and move the exe from the /bin directory to the workspaceFolder, the audio plays fine.

Why isn't the ../ file path working, or is there something else at play here that I'm not understanding regarding relative file paths and CL building in VSCode?

Xyr0
  • 11
  • 3
  • 1
    Clearly your EXE's working directory is not where you are expecting it to be at runtime. Verify that with `GetCurrentDirectory()`. But you really should not be relying on relative paths to begin with, always use absolute paths only. It is fairly trivial to query your EXE's current path at runtime (via `GetModuleFileName(NULL)`), strip off the filename portion, and tweak/append the remaining path as needed to create other paths that are relative to your EXE. The Shell API has [many path handling functions](https://docs.microsoft.com/en-us/windows/win32/shell/shlwapi-path) for that very purpose – Remy Lebeau Sep 01 '20 at 21:54
  • I'm not sure I follow what you're saying at the beginning - I set up both a GetCurrentDir check 7and a GetModuleFileName check and got the current directory/filename and it was as expected (D:/My Documents/Programming/thisProgram/bin/the.exe), which should mean that a relative path from the EXE in use would be "..\\resources\\music\\song.mp3" which isn't working (noting here I tried both / and \\ just in case something was tripping up with it)? I don't understand why changing the relative reference to ".\\resources\\music\\song.mp3" and moving the EXE up 1 level out of the /bin directory fixes – Xyr0 Sep 02 '20 at 04:16
  • what EXACTLY does `GetCurrentDirectory()` report? – Remy Lebeau Sep 02 '20 at 04:23
  • "D:\My Documents\Programming\thisProgram\bin" is exactly what it returns when I run it next to the audio file path code. – Xyr0 Sep 02 '20 at 04:52
  • Looks fine to me, so the problem must not be with the file path, it is likely with your audio command instead. Please [edit] your question to show the actual code you are using. And have you tried using an absolute path yet, rather than a relative path, like I suggested earlier? – Remy Lebeau Sep 02 '20 at 04:55

0 Answers0