Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Exclude Files?

You must be registered to post a reply.
Click here to register.

Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji

Forum code is on.
Html is off.

Check to subscribe to this topic.

T O P I C    R E V I E W
gstelmack Posted - Jan 05 2009 : 12:32:02 PM
I would like to know if I can exclude certain CPP files from being parsed by VAX. We use files that are a concatenation of lots of C++ files to improve build performance on certain platforms, and because these are so big VAX can take a little while to parse them. And because they change on most builds, VAX is regularly slowing down the IDE. I would like to be able to tell VAX to ignore these.

Right now I can ignore certain extensions; any chance of getting a wilcard option to exclude groups of files?
22   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Jan 06 2014 : 11:37:48 AM
I missed that change, thank you for the update and the work around. I am glad you were able to fix this, and keep on using this work around.
sneftel Posted - Jan 02 2014 : 07:03:36 AM
Note that in recent builds, "#if 0" is special-cased and ignored by VAX. Use "#if 1 == 0" instead.
feline Posted - Sep 17 2013 : 9:05:38 PM
Thank you for the update, I love this solution that is so brilliantly simple and elegant. I have made a note of this for future reference.

You do have to add this to each of the files to exclude, so it won't work well for everyone, but its going to be quite helpful now and then.
sneftel Posted - Sep 17 2013 : 11:12:10 AM

At the top of the generated code files:

#if 0
_asm {

Relies on (1) VAX following both branches of a preprocessor conditional, and (2) its refusal to parse inline assembly blocks.
feline Posted - Sep 05 2013 : 2:49:10 PM
A good answer, thank you for the details. I have put a note on the case that the plugin solution does not work for 64 bit systems.

As a short term solution, are you able to place the generated code into a separate project in your main solution? Having a separate "editing only" solution would be an even better solution, but keeping the two solutions in sync, editing in one solution but building from the other solution is likely to be more complex.

Hence wondering about using projects, so you are still just using one solution. The generated symbols will still show up in the Open File and Find Symbol dialogs, but you can use the following options to help narrow down the symbols you actually want to work with:

VA Options -> Advanced -> Refactoring -> Display project nodes in Find References results
VA Options -> Advanced -> Refactoring -> Display project nodes in Rename dialog references lists
VA Options -> Projects -> File Handling -> Restrict Goto (alt+g) results to active project
sneftel Posted - Sep 02 2013 : 05:15:12 AM
Basically, we use a reflection system which involves code generation. A class Foobar will lead to the generation of symbols named FoobarClass, FoobarClass_Members, getVtableFoobar, etc. These symbols are only used internally by the reflection system, but they lead to an immense amount of cruft in the Find Symbol window.

Some things I've tried:
* The VA_IGNORE_CODE_START thing. Doesn't have any effect; I think comments are removed before the preprocessing step.
* Defining the codegen symbols as, e.g., void* VAX_IGNORE_SYMBOL(getVtable)(...), with #define VAX_IGNORE_SYMBOL(x) /*nothing*/ in va_stdafx.h, and #define VAX_IGNORE_SYMBOL(x) x elsewhere. This likewise produces all the original symbols.
* Giving the codegen files all a special extension. Unfortunately, we release for a _lot_ of platforms, and some of their toolchains choke on source files without a .cpp extension, so this isn't a practical solution for us.
feline Posted - Aug 29 2013 : 1:08:15 PM
I was not aware of this, thank you for the update. This is most unhelpful, as you say.

What problem are you trying to solve by excluding directories? I am wondering if it would be possible to find another solution that will work for you.
sneftel Posted - Aug 28 2013 : 07:52:49 AM
Unfortunately, the free version of MS Detours (which the plugin relies on) doesn't work with the x64 architecture, so it's not an option for me. (The non-free version costs ten thousand bucks. Yikes.)
feline Posted - Nov 16 2012 : 3:37:53 PM
Unfortunately no progress to report on this yet. This is a request that has come up a few times, as you have seen, and it is still a feature we are considering adding. Working out which features to add next is a tricky balancing act.

Have you looked into the plugin linked to in this thread? A few users have used this successfully.
sneftel Posted - Nov 13 2012 : 11:39:05 AM
Any motion on this? Judging by a quick search, case=25837 seems to be on a lot of people's wishlists.
Konrad Posted - Jul 10 2009 : 11:44:08 AM

The following code works for me and avoids hard coding the return address.
Add the definition:
static void * VAXRetAddress = 0;

and change the contents of the xCreateFileW method to

void *retAddr = _ReturnAddress();
if ( !VAXRetAddress )
    if( lpFileName && wcsstr( lpFileName, L"\\\\mfc\\\\" ) )
        VAXRetAddress = retAddr;
        return INVALID_HANDLE_VALUE;
else if( retAddr == VAXRetAddress )
    LPCWSTR *filter = g_filterList;
        CAtlRegExp<CAtlRECharTraitsW> reFilter;
        if(reFilter.Parse(*filter, FALSE) == REPARSE_ERROR_OK)
            CAtlREMatchContext<CAtlRECharTraitsW> mcFilter;
            if(reFilter.Match(lpFileName, &mcFilter))
                return INVALID_HANDLE_VALUE;

return (*_fnCreateFileW)(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, 
         dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);

I tried finding the address using the full regex, but the Qt plugin was calling into VaPkg.dll from another process and the wrong address was being registered. Very strange.

I hope this is useful to someone.

Konrad Posted - Jul 10 2009 : 09:49:40 AM
Hello Pavel,

Sorry for not replying earlier. Thanks for your quick reply. I was able to finally get it working and learned a few new things about Windows in the process.

Finding the proper return address could be automated, but the main problem would be saving the address across runs. I will think about it some more.

Many thanks again.


pmadr1 Posted - Jun 01 2009 : 02:43:19 AM
Hi Konrad,

I had also problems with CreateFileW function and they was caused by test for the address.
1. release and debug version have different addresses
2. address can differ on different PCs
So I added bigger interval for matching the address (see code bellow).

For debugging purposes I used message box (see bold section) and found out real address when VAX is opening file for parsing.


LPCWSTR filename,
DWORD access,
DWORD sharing,
DWORD creation,
DWORD attributes,
HANDLE _template
void *retAddr = _ReturnAddress();

/* for debugging
if( filename && wcsstr( filename, L"\\\\filter\\\\" ) )
CString s;
s.Format("1. xxxx: %p\\n", retAddr);
MessageBox( NULL, s.GetString(), "File", MB_OK );

// 0x01C4CE1E - debug
// 0x0184CE1E or 0x0183CE1E - release
if((DWORD_PTR)retAddr >= 0x01830000 && (DWORD_PTR)retAddr <= 0x01850000)
if( filename && wcsstr( filename, L"\\\\filter\\\\" ) )
//MessageBoxW( NULL, filename, L"File", MB_OK );

return (*_fnCreateFileW)(
filename, access, sharing, sa,
creation, attributes, _template);
feline Posted - May 29 2009 : 11:25:36 AM
We are considering the ability to always filter out certain files from the OFIW dialog:


which would help. I have put a note onto this case about removing these items from the Find References Results list as well. This either makes the idea easier or more complex, depending on how it is approached.

Adding the macro to VA's StdAfx.h file should work. For quite a while this is the approach we used to get signals and slots working:


items defined in VA's StdAfx.h file are treated differently. Having said that, trying to use macro's to comment out blocks of code like this has always been slightly tricky. I have made it work before now, but not always first time.

I cannot offer any advice on the plugin from bugfix since I have never tried to use it, or even read the code. If you add some debug / logging, then is this function being used to open the files you want to ignore? It is possible they are being opened via a different function.

Short of setting up two different solutions I am not sure what else to do here. You could have one solution for VA, that only includes the files you want to see, while you use a more complete solution that is used to actually build the program. This is likely to be a maintenance nightmare though.
Konrad Posted - May 29 2009 : 10:24:25 AM
My problem is very similar to this.

I am using VS2005, Qt 4.4.1 and the Qt VS Integration. I would like to filter out the generated moc, ui and qrc files from the Find References ( I know that I can delete them. Sometimes there are lots ) and OFIS ( I know I can use -moc_ ). I am just lazy

I have tried:
1) Using the filter from bugfix. I modified it to hook into CreateFileW and added ".*moc_.*\\\\.cpp$" to the filter but it did not work. Did I miss something? How do I debug the "plugin"?
2) All moc_* files start with QT_BEGIN_MOC_NAMESPACE. So I added #define QT_BEGIN_MOC_NAMESPACE /** etc. to the VAX StdAfx.h. It does not work because this macro is redefined by later includes of the Qt headers.
3) I even tried adding moc_*.cpp to the extensions to ignore in the options dialog, but that didn't work either.

Any suggestions are welcome. Thanks in advance.

Also thanks to bugfix for introducing me to the detours library. I had no idea that something like this even existed.

pmadr1 Posted - May 25 2009 : 04:34:59 AM
I have found out that CreateFileW is called so I can hook on it and it seems to be working.

pmadr1 Posted - May 25 2009 : 04:01:06 AM
Thanks for the plugin, but it doesn't work for the latest VAX and Visual Studio 2005, because function CreateFileA (remapped to xCreateFileA) is not called for files parsed by VAX. It's called just for a few files used by Visual Studio.
Is there another method which is called for each file to be parsed, so I can hook on it?

feline Posted - May 22 2009 : 2:25:56 PM
One approach might be to create a second solution that you use when editing. This solution would only contain the files you want VA to parse, while the main solution which you use for compiling contains all of the files. I can see all sorts of reasons why this is not a good idea though.

You could try adding these specific directories to VA's Stable Include directories list, after setting:

VA Options -> Projects -> C/C++ Directories -> Platform = Custom


Normally this is a bad idea, since you do not want files that are in your stable include directory to be part of your solution, but since you don't want VA to parse these files you might want to try this.

One of our users wrote their own plugin / tool to make VA ignore certain directories:


They were kind enough to give me a copy of the source code, which you can download from here:


This is NOT an officially supported solution, but it it works it should be quick and easy. You will need to modify the code to exclude these specific directories.
pmadr1 Posted - May 22 2009 : 02:32:34 AM

We have same problem with big files which we want to exclude for VAX.
But we can't use solution with VA_IGNORE_CODE_START macros, because:
1. the code is auto-generated by 3rd party tool
2. already contains comments /*

Also we can't change extension of these files and they have to be in the solution.
They are in specific folder and have similar file name ( *_wrap.cxx).

Do you have some hint for us?

Best Regards,
feline Posted - Jan 07 2009 : 09:48:50 AM
The macro's might work, I have tried this before and seen it work, but other people have reported mixed results with this work around.

If the files are not actually open in the IDE then simply turning off:

VA Options -> Performance -> watch for externally modified files and reparse when necessary

may help. VA is designed to parse all of the files in the solution, since normally this is what you want, but obviously it is causing some problems here.
gstelmack Posted - Jan 05 2009 : 1:28:10 PM
Yes, the files are part of the solution so they get built.

That may work. Sounds like it will still parse it, but ignore what's in there, which should be relatively fast.
feline Posted - Jan 05 2009 : 1:21:04 PM
Are these files in a specific directory?

Are they part of the solution?

If they are in a specific directory and not part of the solution it should be possible to configure VA so that it cannot find these files.

However if they are part of the solution then we need to try something else. One possible approach would be to have the long file start with the macro VA_IGNORE_CODE_START and the macro VA_IGNORE_CODE_END

Before you ask these do NOT exist. You will have to create them. If the file starts with:


and you add

#define VA_IGNORE_CODE_END **/

to the bottom of VA's StdAfx.h file as explained in this FAQ entry:


This file is used to help VA's parser with difficult code, and can be used to work around odd effects. After modifying this file you need to rebuild the VA symbol database for the changes to take effect:

VA Options -> Performance -> General -> Rebuild symbol databases

It is *possible* we can trick VA into thinking the file is all comments, if it does not contain any /* */ format comments.

© 2019 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000