| T O P I C R E V I E W |
| .oisyn |
Posted - Oct 08 2009 : 08:06:52 AM
Hi,
VA has a file called stdafx.h in it's install dir that it parses before any other headers. I use this file to add some definitions of my own. Unfortunately, as the comments in the file say, the file is overwritten with every new installation of VA.
I'd like to request that you support another file, called something like stdafx_user.h, that is parsed immediately after stdafx.h, but which isn't overwritten by new installation of VA, so users don't have to back up and restore their changes every time they install an update to VA :) |
| 5 L A T E S T R E P L I E S (Newest First) |
| .oisyn |
Posted - Oct 19 2009 : 09:38:13 AM
quote:
Originally posted by feline
The problem with simply adding a #include to your own custom header file is that any modification to either the main StdAfx.h or StdAfxVA.h will be lost when you next install a new version of VA.
I meant it the other way around. The user file, which is not overwritten with a new install, includes the original installed stdafx.h file from the VA X install dir. |
| tandr |
Posted - Oct 14 2009 : 12:59:53 PM
how about following solution
1. StdAfxVA.h would have following 2 lines (always)
at the beginning
#include "stdafxva_user_pre.h"
and at the end
#include "stdafxva_user_post.h"
2. VAX (on install) will create these files if they do not exist in in the same directory where StdAfxVA.h is sitting, and do nothing (or "touch" them) if they do exist.
3. if user feels like adding anything in them, it will be kept between install. If not, there is no harm in including empty file, right?
|
| feline |
Posted - Oct 13 2009 : 2:21:56 PM
You make a good point, I have put in a case to update the comments in the default StdAfx.h file.
case=33777
The problem with simply adding a #include to your own custom header file is that any modification to either the main StdAfx.h or StdAfxVA.h will be lost when you next install a new version of VA.
I see an appeal to a totally separate file that does not have to be kept in sync, but as it stands it is *very* rare that we make any changes to the main StdAfx.h file. So you can largely ignore the problem of keeping the files in sync, and just check once a year, or if odd problems start to show up. |
| .oisyn |
Posted - Oct 13 2009 : 06:48:02 AM
Then maybe you should update the comments of the file rather than pointing people to some information not to be found anywhere but on the forums ;). But thanks for the info, and my apologies for not searching the forums.
Anyway, this certainly helps not losing my changes, but my request was to have an extra file as an addition to the original stdafx.h that comes with the installer. That way, I will always have the latest version, but still have my own definitions intact. Would it be possible to do an #include <c:\\program files\\va x\\misc\\stdafx.h> inside the user stdafx.h, so that it still takes it's definitions from the installed file? |
| feline |
Posted - Oct 08 2009 : 09:46:08 AM
The comments in the file are accurate, but slightly out of date. From this FAQ entry, describing the second copy of StdAfx.h
http://docs.wholetomato.com?W302
quote:
Visual Assist X's installer does not know about this user specific file, and it never updates it, so you no longer have to worry about loosing your changes when installing a new build of Visual Assist X.
Visual Assist X checks for this user specific file. If this file is found then it is used, otherwise Visual Assist X uses the default file.
You will need to "diff" your local file with the default version occasionally, to make sure that you are not missing any new entries that have been shipped with a new build of Visual Assist X.
Apologies for the confusion, but I have been pointing people at this FAQ, which explains this, for quite a while now. |
|
|
