| T O P I C R E V I E W |
| MrDoomMaster |
Posted - Jan 09 2007 : 3:46:33 PM
Hi,
I've read the documentation regarding the C++ Directories option in the VAX settings. It does not seem, however, that the "Platform" option is project-specific.
Here's my scenario. I am coding for a platform that has its own version of the STL and CRT libraries, so therefore I don't want visual assist parsing through ANY of the microsoft-specific header/source directories for symbols. I want Visual Assist to ONLY parse through the custom directories I specify. The thing is, when I switch between this platform specific project and other windows projects, I'm constantly having to switch the "Platform" between "Custom" and "Win32" depending on what project I'm using.
Basically I would like the "Platform" option to be project specific somehow, so that the project option would switch to "Custom" and "Win32" depending on what project I open.
Any ideas? |
| 22 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Aug 14 2008 : 11:06:37 AM
How often do you change the platform?
How many platforms do you need to swap between?
You could emulate this effect by using a batch file or script to move / rename the directory holding the VA symbol database at the same time as you update the registry keys that list the stable include directories.
Finding header files, I have replied with some questions about this in your other thread. |
| oooooooo |
Posted - Aug 13 2008 : 10:00:45 PM
It will be very inefficient for large project with huge code base, such as windows CE 6 development. Can you have a feature that allow different subcategory of custom platform. Developers can switch among these subcategories without rebuild the symbol database. In other word, each subcategory has its own database.
Besides, I found the software can not iterate all levels of subdirectories to find all the headers. For example, if I put C:\\wince6 in the header, it does not go through the whole subdirectories. |
| feline |
Posted - Jan 19 2007 : 08:12:46 AM
quote:
Originally posted by euroq
Aww too bad adding the platforms in the registry didn't work. There are several editions of the Symbian OS SDK; I have 5 installed on my computer at the moment. Basically newer editions as new phones come out. The differences between the various SDKs are minute, but frustrating.
We are not sure where the IDE gets its platform information from - we just get it from the IDE via COM, but I have thought of a different approach.
If all the IDE's are closed then you can easily edit VA's custom platform directory list by simply changing the correct key in the registry. Assuming you are using VS2005 then it is the key:
HKEY_CURRENT_USER \\ Software \\ Whole Tomato \\ Visual Assist X \\ VANet8 \\ Custom \\ SystemInclude = *directory list*
You can force VA to rebuild its symbol database by deleting the directory tree:
C:\\Program Files\\Visual Assist X\\vc8\
A little brutal, and not something I would normally recommend, but if you don't mind loosing file history (used if the IDE crashes), etc, then this should quite nicely.
So the theory goes as follows:
Set VA to use the custom platform.
Create a batch file for each SDK to:
* set the VA custom registry key to the correct set of directories
* delete the symbol database directory tree
* load the IDE
At this point VA should rebuild its symbol database using the directories for the current SDK.
I have not actually tested this, but on paper it should work just fine. Changing the registry key does work, I tried that. Obviously be careful not to delete the Visual Assist X directory with your batch file, since then you will have to reinstall VA  |
| feline |
Posted - Jan 16 2007 : 06:22:52 AM
The first question is how is the IDE and VA configured?
If the VA C++ directories platform is still set to Win32, and this platform still points at the Win32 CTR and STL libraries then this is where VA has been told to look for things.
If you have swapped VA's platform to Custom then the projects additional include directories should have more of an effect on things. |
| MrDoomMaster |
Posted - Jan 15 2007 : 3:40:01 PM
Suppose I have a VS makefile project. This project uses an SDK that has its own versions of CRT and STL. I add all of the required include directories for this SDK in the project settings. Although I have done this, the "win32" includes I believe are still available to Visual Assist to parse through.
At this point I am not guaranteed that visual assist will either parse Win32 CRT and STL libraries, or my own SDK's versions of those libraries. |
| feline |
Posted - Jan 15 2007 : 3:10:25 PM
Most users are unlikely to need more than one custom platform. I will ask the developers if there is an easy way to "fake" this. Some SDK installers add additional platforms to the IDE, which VA then picks up and offers. So if we can add a set of custom platforms to the IDE this will do the job.
case=4538 |
| euroq |
Posted - Jan 15 2007 : 2:56:42 PM
quote:
Originally posted by feline
quote:
Originally posted by euroq
I just thought of something. Does anyone know how to add new Platforms other than Win32? If so, that would solve my problem. Even if I had to close shut down the IDE every time I switched to a project with a new platform, that would be completely acceptable to me considering it's better for me to have VAX's intellisense after a minute of scanning in the background than to not have it at all.
How many platforms do you require? I have just been having a look at this and the really simple "just add a couple of registry keys" hack does not work.
If you only need 2 platforms then you can do this already. Since you are using an external compiler you can set the IDE's Win32 global platform to configuration 1, and set VA's Custom platform to configuration 2.
Aww too bad adding the platforms in the registry didn't work. There are several editions of the Symbian OS SDK; I have 5 installed on my computer at the moment. Basically newer editions as new phones come out. The differences between the various SDKs are minute, but frustrating.
Maybe this could be a feature request? Ability to add more than one Custom platform. |
| feline |
Posted - Jan 12 2007 : 1:47:20 PM
quote:
Originally posted by euroq
I just thought of something. Does anyone know how to add new Platforms other than Win32? If so, that would solve my problem. Even if I had to close shut down the IDE every time I switched to a project with a new platform, that would be completely acceptable to me considering it's better for me to have VAX's intellisense after a minute of scanning in the background than to not have it at all.
How many platforms do you require? I have just been having a look at this and the really simple "just add a couple of registry keys" hack does not work.
If you only need 2 platforms then you can do this already. Since you are using an external compiler you can set the IDE's Win32 global platform to configuration 1, and set VA's Custom platform to configuration 2. |
| feline |
Posted - Jan 12 2007 : 1:45:23 PM
quote:
Originally posted by MrDoomMaster
I really don't understand why there's include directories specified by VAX and also by the IDE's global settings. It seems like VA shouldn't need this, since it can use the IDE's global include directories for "global" search paths.
Simply leave VA alone, and it does use the IDE's global settings.
The ability to use something else exists in case you need it. Imagine someone who develops code that has to compile under both Windows and Linux. When doing the Linux part of their development they may want to edit in VS2003 using VA, but they will need to reference a different set of system includes. This is why VA has the option to set your own, but as a general rule we recommend people ignore this, since it is only designed for "odd" situations. |
| MrDoomMaster |
Posted - Jan 11 2007 : 2:43:22 PM
quote:
Originally posted by euroq
quote:
Originally posted by MrDoomMaster
I really don't understand why there's include directories specified by VAX and also by the IDE's global settings. It seems like VA shouldn't need this, since it can use the IDE's global include directories for "global" search paths.
If I have a project that compiles for a platform that has its own versions of the CRT and STL libraries, how can I guarantee that my project will use the CRT/STL include paths I specify and NOT the microsoft specific CRT/STL implementations?
Right now, all you can do is goto VAX settings->Projects->C++ Directories, change the Platform from Win32 to Custom, and put your custom "stable directories" in there.
That doesn't really answer my question... I would like to know *why* VAX requires include directories rather than just referencing the global include directories already provided by the IDE. |
| euroq |
Posted - Jan 11 2007 : 2:35:39 PM
quote:
Originally posted by MrDoomMaster
I really don't understand why there's include directories specified by VAX and also by the IDE's global settings. It seems like VA shouldn't need this, since it can use the IDE's global include directories for "global" search paths.
If I have a project that compiles for a platform that has its own versions of the CRT and STL libraries, how can I guarantee that my project will use the CRT/STL include paths I specify and NOT the microsoft specific CRT/STL implementations?
Right now, all you can do is goto VAX settings->Projects->C++ Directories, change the Platform from Win32 to Custom, and put your custom "stable directories" in there. |
| MrDoomMaster |
Posted - Jan 11 2007 : 12:13:53 PM
I really don't understand why there's include directories specified by VAX and also by the IDE's global settings. It seems like VA shouldn't need this, since it can use the IDE's global include directories for "global" search paths.
If I have a project that compiles for a platform that has its own versions of the CRT and STL libraries, how can I guarantee that my project will use the CRT/STL include paths I specify and NOT the microsoft specific CRT/STL implementations? |
| euroq |
Posted - Jan 11 2007 : 11:28:45 AM
I just thought of something. Does anyone know how to add new Platforms other than Win32? If so, that would solve my problem. Even if I had to close shut down the IDE every time I switched to a project with a new platform, that would be completely acceptable to me considering it's better for me to have VAX's intellisense after a minute of scanning in the background than to not have it at all. |
| euroq |
Posted - Jan 11 2007 : 11:22:52 AM
quote:
Originally posted by feline
If you now close this project and tell VS2003, via its C++ directories settings, as explained here:
http://www.wholetomato.com/products/features/directories.asp
that "C:\\SDK\\chocolate\\" is a standard include directory then when you next open your project you can simply use #include <nice.h> and it will compile. Note that the project its self has not been modified. In this sense this is a "global" setting.
The alternative is to modify the project's "C++ additional include directories" setting - I am calling this a "local" or "project specific" setting.
common terms before we are going to get anywhere
Ah ha! There is such a thing as a global IDE include directory. Didn't know that. Anyways, these are irrelevant for me because Symbian SDKs supply its own compilers (i.e. the build tools are external, so even then the include directories have to be passed to the external compiler, which is done via the project settings).
Unfortunately for me having all of the SDKs available is that most of the SDKs are similar with a few small, irritating exceptions. You know, SDK 2.3 has a few different things than SDK 2.2... which is why being able to browse the header files via VAX is so nice. Who knew that SDK 7.0 doesn't have AppendL(), so I'll have to use plain old Append() because that wasn't introduced until SDK 8.0... and so on... |
| feline |
Posted - Jan 10 2007 : 2:47:25 PM
We are still talking about slightly different things. Let me try to explain what I am talking about.
Assume we install a new SDK to the directory "C:\\SDK\\chocolate\\"
And this contains the file "nice.h", so we have "C:\\SDK\\chocolate\\nice.h"
If you open an existing, or new project and type #include <nice.h> this will fail to compile.
If you now close this project and tell VS2003, via its C++ directories settings, as explained here:
http://www.wholetomato.com/products/features/directories.asp
that "C:\\SDK\\chocolate\\" is a standard include directory then when you next open your project you can simply use #include <nice.h> and it will compile. Note that the project its self has not been modified. In this sense this is a "global" setting.
The alternative is to modify the project's "C++ additional include directories" setting - I am calling this a "local" or "project specific" setting.
Based on this, if you have 10 SDK's then you can add all 10 of them to the IDE's settings, so they are available to all projects, or if they overlap / conflict then you don't, and you simply add the ones you need to each project as you go along.
If you want to make sure that VA has full knowledge of the SDK "chocolate", without making it available to all projects, then assuming you are using VS2003 or VS2005 you can make a new project "Chocolate.vcproj" which contains the files for this SDK and add this into the main project. Then you can simply use the IDE Build menu -> Configuration manager...
to tell the IDE that "Chocolate.vcproj" is never to be built.
This is not a perfect answer, but it does make sure VA knows all about the SDK's on a project by project basis, and it saves having to rebuild the symbol database all the time.
Does this make sense? Part of the problem is the words we are using, and we need to agree on some common terms before we are going to get anywhere |
| euroq |
Posted - Jan 10 2007 : 1:19:37 PM
quote:
Originally posted by feline
How VA works can be changed, but perhaps the more interesting question is, how come your projects currently compile? The VA options dialog we are talking about is there as a copy of the IDE "where are my global SDK's" dialog. It is useful if someone is working under UNIX, or for some other reason needs a configuration quite different to how the IDE is setup.
My understanding is that both of you are swapping between two, or more, "sets" of SDK's. So either you have added all possible SDK's to the IDE, you are changing the IDE's project setting all the time, or the projects themselves know how to find the SDK's.
Assuming the projects themselves know how to find the SDK's, why don't we use the same method to get VA to know about the SDK's?
Does this make sense to anyone other than me?
The situation probably isn't explained correctly, then. As a developer for only Windows apps, one might not understand what we're talking about.
I work with mobile devices. I have about 10 SDKs installed on my computer. About 5 are for Visual Studio .NET specifically. It is very easy to have 3 solutions open at the same time which use different SDKs. The only way VS.NET knows about the SDKs and therefore compiles is via project settings, not some "global" setting. So, when you have the statement #include <header.h>, the compiler simply looks in the directories it is passed to as "include directories" set in the project settings.
By the way, this is the way ALL projects work... there is no such thing as a global IDE SDK setting. There is a default, however, which is set to the project when you create a new one. So if you created a new Win32 app, the project is created as pointing to the default Win32 app SDK according to the template.
Anyways... in the end, I see that you say when you change project platforms you have to restart and rebuild anyways. I'd even take that option over the fact that I can't keep a copy of the include directory locations for the 5 SDKs I point to... I have to manually change the "Custom" directories every time. |
| feline |
Posted - Jan 10 2007 : 12:46:12 PM
euroq you do seem to be in the same position as MrDoomMaster.
First the question about adding extra custom configurations. Some SDK's add additional options to the IDE. I seem to recall the SDK for Pocket PC development doing this. When this happens extra entries appear in the:
IDE Tools menu -> Options -> Projects -> VC++ Directories -> Platform (pull down list)
and the same entries then show up in the VA options dialog. However I am not sure what causes these to appear in the list.
The way VA is currently structured it is not really designed to swap between these platforms on a regular basis. When you change the platform you get the message box:
"You must restart your IDE for this change to take effect"
When you do this restart the symbol database is rebuilt.
How VA works can be changed, but perhaps the more interesting question is, how come your projects currently compile? The VA options dialog we are talking about is there as a copy of the IDE "where are my global SDK's" dialog. It is useful if someone is working under UNIX, or for some other reason needs a configuration quite different to how the IDE is setup.
My understanding is that both of you are swapping between two, or more, "sets" of SDK's. So either you have added all possible SDK's to the IDE, you are changing the IDE's project setting all the time, or the projects themselves know how to find the SDK's.
Assuming the projects themselves know how to find the SDK's, why don't we use the same method to get VA to know about the SDK's?
Does this make sense to anyone other than me? |
| MrDoomMaster |
Posted - Jan 10 2007 : 11:45:07 AM
quote:
Originally posted by feline
I can see the appeal of project specific settings, but it is the need to rebuild the entire symbol database that bothers me. If you only ever change projects by reloading the IDE then maybe this would not be to bad, but this is a concern, given how things currently work, if you close the solution and load a new solution.
Alternatively what happens if you open two IDE's, with different projects, at the same time? There will be two instances of VA with different stable include directories in the symbol database.
I would prefer to find a different, hopefully safer, solution to this particular problem
The solution to this problem is easy, but it may be inefficient/unreasonable. The cache used by VAX to store parsed symbols can be project specific as well. You can add them to one large file somewhere in the project folder. The downside to this is that you now have a very large file (I assume it's large) in your project folder. In 99% of all cases, the existence of this file, even if it is large, would not bother me. It doesn't even have to be under version control (Fresh project check-outs would require a 1-time parse for each project, which isn't totally unreasonable).
That's a fine solution, in my opinion. This way when you open multiple projects, the symbol database for VAX is loaded from the project directory and used. You could even go as far as creating a sort of difference engine that will only update portions of the symbol database that have changed, which I would assume could be done at project load and if done correctly would be a speedy operation. |
| euroq |
Posted - Jan 10 2007 : 11:15:50 AM
I believe this may be the same question as above...
I use VAX for Symbian programming. There are multiple SDKs, depending on which device you're programming for (i.e. different phones have different stable directories). So I would like to be able to open up a solution in Visual Studio 2003 and have that particular solution's SDK's stable directory database be loaded.
If that's possible, how?
(I think what I actually want would be more than two "Platforms," i.e. the ability to add more than just one "Custom" platform)
If not... why would it not be possible for VAX to have more than one stable database? Simply ID them by a number or name (for example, there is already Win32 and Custom under the Project directories settings, their unique IDs would be "Win32" and "Custom", and those particular DBs would be saved under that directory). Each instance of VAX would simply load whichever stable database it's pointing at. |
| feline |
Posted - Jan 10 2007 : 07:39:00 AM
I can see the appeal of project specific settings, but it is the need to rebuild the entire symbol database that bothers me. If you only ever change projects by reloading the IDE then maybe this would not be to bad, but this is a concern, given how things currently work, if you close the solution and load a new solution.
Alternatively what happens if you open two IDE's, with different projects, at the same time? There will be two instances of VA with different stable include directories in the symbol database.
I would prefer to find a different, hopefully safer, solution to this particular problem |
| MrDoomMaster |
Posted - Jan 09 2007 : 6:08:33 PM
Thanks for the work-around solutions, Feline.
Might I make a feature suggestion for the future: It wouldn't be completely unreasonable for visual assist to create "project files" itself, in the same directory as the vcproj file (Make it a text-based configuration for source control, preferably even XML). This would provide a way of creating "custom" directories to parse through, that will be loaded with any given project. I'm sure there's other project-specific things that would be able to use such a great idea; unfortunately I cannot think of any others at the moment.
I realize the developers get tons of feature requests and bug reports on a daily basis, but it would be nice if this one could somehow get added to the queue. I'm sure that others might find this useful as well, but I can't say for sure :) |
| feline |
Posted - Jan 09 2007 : 4:55:12 PM
These settings are used to build the stable include directories part of the symbol database, so almost by definition they are not designed to change very often.
The settings ultimately come from the registry. If you have a shortcut to the solution file, you could replace that with a shortcut to a batch file that first updates the registry, and then loads the IDE with the correct solution.
This is quite an ugly solution though.
You could change this to custom and remove all of the directories. Then each project will specify its own set of include directories, one project referencing the default ones, and the other project referencing the replacement ones. |
|
|
