I suggest you ...

Allow me to link Visual C++ filters to specific directories

Please give me a way to associate a directory for a given filter (ie folder) in VC++. The directory would be used as the default when I click on a filter and run the Add New wizard. This would help greatly on larger projects with elaborate directory structures.

Here is an example of how the current setup is maddening. Imagine I am working on something that has a directory structure like this

\msvc << VC++ files here
\brandX << build/make files for your competition

I can create Filters in VC++ that match this.
Header Files
Source Files

The problem is that there is no durable connection between the filter and its corresponding directory. This is maddening when I try to add new code. Say I want to add a dictionary class, so I right click on Header Files\Collections and pick Add New -> Header File. But the default directory is off in the build folder where the project files. So I have to remember to navigate to the correct folder: include\Collections.

Then I follow up by making the CPP file. Right click on Source Files\Collections and select Add New -> C++ file. But now the default directory is of in the include folder. After I finish this class, I make another, starting with the .H file. Again, I have to always remember to navigate back to the include directory.

What I want is the ability to configure the default directory for a filter, so that when I add new source files, the wizard defaults to the path associated with the filter I clicked on. If I don't configure my filters this way, VC++ can just behave the way it already does.

336 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
H^2 shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • TRON commented  ·   ·  Flag as inappropriate

    The good thing about the current approach (having a virtual filter-based hierarchy that doesn't have 1 to 1 filter-directory association) is that it works with every kind of messy filesystem layout regardless whether it started out as a VS or non-VS project. And of course it is backward compatible with older VS project files. Even if they introduced something new to support a more strict/organised workflow they would have to keep the old ones too. Sometimes filtering makes it possible to reorganise of a messy project from another platform at least at the VS project level.

    All of my own C++ projects are usually placed to their own directory. This includes all header and C/C++ files. My project is rooted in a single directory and might have several subdirectories to organise things. For ease of access/editing (locality) I keep the header files along with their implementation c/cpp files in the same directory with the same filename (only the extension differs). When I'm writing a library I create a special include file in the root directory of my library: this include file includes all necessary header files from subdirectories that might be needed by the users of the library. When my solution has multiple projects they include each other via those "root" header files (1 root/main include file per project). When project A wants to include project B I usually include B's header in the PCH of project A to achieve quick compile times. When I want to release my library as a header + .lib combo the set of header files in a lot of subdirectories mixed with implementation C/C++ files is far from ideal however I have a very good solution to this problem: Using "cl /E" I preprocess/expand the root include header file into a mega-header that contains all header files and release that single mega-header with the .lib files. My project filesystem and filter hierarchy are the same and unfortunately I have to synchronise them manually. It would be nice if VS could give me an additional option to be able to add actual directories to the project (besides being able to add filters as "virtual directories" for backward compatibility). The added directory should look the same in the project view as the filesystem hierarchy itself, being able to hide directories/files and/or being able to exclude them from build would be necessary (explicitly or perhaps using a set of filter expressions).

    Unfortunately the freestyle C/C++ ways of doing things (like archaic header file inclusions) are very far from newer solutions like C# that have much better dependency management and ways of seemlessly enforcing modularity (at the source code level too). This saves the developer from many unnecessary choices like how to organise the filesystem to support modularity and what rules to use for header inclusions (to avoid include hells, bad compile times, funny include paths, etc), how to release static/dynamic libs. I work with my own ruleset to resemble the modularity of newer languages and in order to eliminate some decisions from my development process.

  • Sergiu commented  ·   ·  Flag as inappropriate

    Would be even better to automatically create and reflect the structure from the disk and have no filters.

  • Yana N commented  ·   ·  Flag as inappropriate

    It's so frustrating that on the one hand the Visual Studio supports declarations like the following one

    <ClInclude Include="include\**\*.h;source\**\*.h" />
    <ClCompile Include="source\**\*.cpp" />

    while, on the other hand, cuts down this effortless extensibility with filters that cannot keep up with anything more complex than extension-based filtering.

    At least give as “Paths” selector with an ability to override less specific “Paths”, i.e. between “source\alg” and “source” - “source\alg” wins.

  • Marián Špánik commented  ·   ·  Flag as inappropriate

    This can be work-arounded by enabling "Show all files" in the solution explorer but it then display a lot of build folders, e.g. Debug, Release and x64. This reminds me first versions of DOS when partitions didn't have directories (although I am too young to live through it) so all files were in a root directory of the partition... it was overcomed a really very long time ago. This is a must, why wasn't it still implemented?

  • Joe commented  ·   ·  Flag as inappropriate

    I concur with Steven Logan. (I'd go one step further and get rid of the filter file all together--every developer I know who is aware of this file is aggravated by it.)

  • Ketschak commented  ·   ·  Flag as inappropriate

    I also think that this feature would be a good improvement. It would also be very nice if we could mark a filter as a "folder reference" which then simply lists all files and subfolders which are currently located in the folder. No need to add/remove items if the folder content changes.

    Here is my workaround to the problem: I wrote an extension which adds a "duplicate" command to the context menu. The command creates a copy of the selected file in the same folder and adds the new file to the same filter as the selected item. After that I change the new file accordingly.

  • Daniel Albuschat commented  ·   ·  Flag as inappropriate

    It would be even better if the content of the filter would be automatically populated by the actual files in the linked directory - that way, e.g. for resources, just putting a resource in a directory will add it to the VS project. Yay.

    Btw., my current "workaround" for the problem you are mentioning, which is bugging me, too, is this: Type "..\..\source\" in the file name input box, press enter, and you are in the correct location, then select the file and hit enter again.

  • Tobias Hummrich commented  ·   ·  Flag as inappropriate

    Oh my, if this would be in VS, it would be really great. Someday VS might become even as good as ... ;-) kidding.

    But really: As it is it is no fun to introduce a new class. With this (above) the IDE would get a large improvement.

Feedback and Knowledge Base