Open Document <dsound.h> not working in VS2017

I am unable to open dsound.h, xinput.h and windows.h with Visual Studio 2017, but stdint.h is opening with no problems.
I am building project exactly like Casey and program is compiling and running just fine.

Edited by Maciej on
How are you building in VS2017? Do you have proper solution/project set up, or are you using external build.bat command?
How are you "opening" them? And why would you want to open them? You could simply browse to folder and open it as file. Its somewhere in C:\Program Files (x86)\Windows Kits\10\Include\10.0.x.0\um folder.

Edited by Mārtiņš Možeiko on
I am using build.bat and VS only as a debugger. When I recreated project in VS I can open all headers and jump to all definitions. Open Document <dsound.h> (Error:"File 'dsound.h not found in current files's directory or in build system paths. ...") and XUSER_MAX_COUNT -> Go to Definition (Error: "A definition for the symbol 'XUSER_MAX_COUNT ' could not be located" are not working for example. I located all headers in C:\Program Files (x86)\Windows Kits\...

I want to resolve this issue because Casey is using VS in the same way and it's working for him, it's sometimes convenient to quickly jump to definition and I don't understand what's going on and want understand how to configure VS properly.

Edited by Maciej on
Yeah, if you don't have proper solution/project created then goto definition or opening includes on right click context menu sometimes work and sometimes doesn't. Who knows why... For proper intellisense you'll need to create normal solution/project based build.

The difference from Casey's videos could be that he is using VS2013 instead of VS2017.
You can fix the open header on right click quite easily.
Open the debug project, if it doesn't have the source code (win32_handmade.cpp) open, launch a debug session with F11 and the sources should open.
Next, open the properties page for the source file (remember not the project properties, the source file ones -> right click on the source code, select "win32_handmade.cpp Properties") and there you will have "Include Search Path" under the General category. Add there the path to the Windows Kits headers (latest update is 10.0.14393.0 so the path is C:\Program Files (x86)\Windows Kits\10\Include\10.0.14393.0\um or similar ... just search where it is installed).

For those interested, basically this started happening with VS2015 (and why Casey didn't encounter it with VS2013) when they changed the way c++ project settings are stored - before they were global and applied to every project now they are part of the project settings (this is especially problematic with paths that depend on other settings in the project file, for example windows kits version). Debug projects don't have any settings aside from the most basic ones (just create a template project and see how many settings it has) so it doesn't know where to look for those files.
Also VS fails at recognizing what is installed because of this convoluted mess of project settings and you are often left scratching your head trying to figure why it is searching for includes in the Windows Kits version 10.0.10240.0 folder instead of the actual install directory, because some monkey UI designer at M$ figured it would be nice if there was a "Windows Kits Version" field in the settings (nice to know that a simple vcvars batch script is more powerful than the actual IDE at figuring out paths, too bad VS ignores it completely).

So yeah, hope it solves your problem and sorry for the long post and the vent ... I started coding along with Visual Studio and that changed on day 21 video, when I hit these problems and some more (seriously what Casey says about VS getting worse with every version is true).
ripple
(nice to know that a simple vcvars batch script is more powerful than the actual IDE at figuring out paths, too bad VS ignores it completely).

You can make IDE to use settings from env variables, if you launch devenv.exe with "/UseEnv" argument.

Edited by Mārtiņš Možeiko on
@ripple
Thank you for your post, it was very insightful.
I did what you said and everything is working now.

BTW, how VS is finding source code?

Edited by Maciej on
Intellisense probably does that from include directories specified in project settings + some global SDK folder locations.

In debugger its doing it from debug information. pdb files for each symbol (function name, variable name) has a location info. Which includes file path, name and line number.


Edited by Mārtiņš Možeiko on
As of 12/16/2018, it seems that the way for Visual Studio 2017 to find these header files has again changed. There is an option at the bottom of the View menu called Property Pages. There are different Property Pages for many different items in your solution.

To get to the a menu where you can add an include search path, it seems you need to select the Property Pages for the win32_handmade.cpp file. If you right-click inside the source file, sometimes you are lucky enough to have a valid menu displayed when you choose win32_handmade.cpp Properties. If the correct menu is displayed, there is an option in these Property Pages to update the Include Search Path with the path to Windows.h, XInput.h, etc. The path you need to include may be something like C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um.