Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Project-Relative Additional Parse Directories

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

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

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
swinefeaster Posted - Feb 23 2006 : 1:16:55 PM
is there any way in VAX to specify additional source directories to parse *relative* to the project or solution? can you use VS2005 $(xxx) macros in the VAX option pages...?

the reason i'm askin is that we've recently switched to splitting up the project into various dlls, so a lot of common code does not get automatically parsed. i mean, VAX finds out about it through the includes, but you can't the OFIW or FSIW dialogs (obviously).

what's the best way around this, without having to add all the header files for these dlls into the project itself?

keep in mind this has to be relative because if we work in a branch, the absolute path will change.

thanks

swine
30   L A T E S T    R E P L I E S    (Newest First)
support Posted - Sep 19 2006 : 01:57:25 AM
Case 2481 is fixed in build 1535.
sean Posted - Sep 13 2006 : 1:53:37 PM
[greg and I have continued this in email]
sean Posted - Sep 12 2006 : 2:32:46 PM
Thanks for the logs Greg. I see the problem now. case=1072 was specifically about support for user macros - we do support those. What we don't currently support is additional include directories being set in property files (as opposed to project files). case=2481
gstelmack Posted - Sep 12 2006 : 10:51:00 AM
quote:
Originally posted by sean

Gregs: Just to confirm, can you send me va.log of opening the solution? If the IDE opens with the solution already open, close the solution, enable logging and then open the solution. Wait until cpu goes idle and then exit.
http://www.wholetomato.com/support/faq.asp#log




I just sent the logs off to support.
sean Posted - Sep 11 2006 : 2:02:37 PM
Gregs: Just to confirm, can you send me va.log of opening the solution? If the IDE opens with the solution already open, close the solution, enable logging and then open the solution. Wait until cpu goes idle and then exit.
http://www.wholetomato.com/support/faq.asp#log
gstelmack Posted - Sep 11 2006 : 10:49:32 AM
quote:
Originally posted by sean

Greg: take a look at my 11:50pm post over at:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=4530

Does that describe the problem you are experiencing?



Yes, that looks about right.
sean Posted - Sep 07 2006 : 11:53:56 PM
Greg: take a look at my 11:50pm post over at:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=4530

Does that describe the problem you are experiencing?
sean Posted - Sep 07 2006 : 1:30:58 PM
Yes - if you have a small repro sample, please email it to me via my forum profile.
gstelmack Posted - Sep 07 2006 : 11:55:53 AM
Has there been any movement on this? I'm running into a similar issue, where we just converted all our projects over to using Property Sheets in Visual Studio 2005, and are using custom User Macros to specify include roots. For example, we'll have a custom User Macro set in a base property sheet like:

MY_CUSTOM_MACRO = ..\\..\\..\\library\
and then another property sheet will have an Additional Include Directory set like:

$(MY_CUSTOM_MACRO)\\MyCustomLib\\inc

and then the project will use the property sheets. But Visual Assist does not find / parse any of the headers in MyCustomLib.

I see that case 1072 about property sheets is listed as "fixed" in 1531, but I'm still seeing this specific issue in 1534.

Are you still looking for a small repro sample? If so, that may be something I can try and put together.
support Posted - Aug 08 2006 : 01:22:33 AM
Case 1072 is fixed in build 1531.
feline Posted - Apr 02 2006 : 3:26:30 PM
can you start a new thread for OFIR please? this thread is getting a little difficult to get my head around each time i have to re-read it

you do realise that there is the whole "fun" question of how to define the Repository to consider? which does not actually have anything to do with VS2005 macro variables

i do see the appeal, i use a 3rd party library myself, Qt in my case.
swinefeaster Posted - Mar 29 2006 : 4:43:23 PM
i know i know... however i can assume that many others would have a similar situation too (for large projects, anyway). maybe what you need is a OPIR and FSIR dialogs (R for Repository) or something like that...

*please please please*

:=)
feline Posted - Mar 29 2006 : 1:31:36 PM
look at point 2 from the other point of view, you are normally using standard win32 libraries, would you expect all of the files for these libraries to show up in OFIW?

i appreciate that you have a slightly different situation, but remember this dialog is called Open Files In Workspace.
swinefeaster Posted - Mar 28 2006 : 7:47:27 PM
ok well i guess one step at a time... fix the macros and i'll see... *sigh*

thanks
feline Posted - Mar 28 2006 : 3:44:29 PM
to be honest i am not sure about either question. on point 2, i am fairly sure the files will not automatically show up, since the SharePool files are not actually in the solution.
swinefeaster Posted - Mar 27 2006 : 6:04:55 PM
yes, i believe that is all i need...

1. it would have to be rechecked each time a new solution is opened, however. (or i guess vc could just be restarted)

2. would this cause SharePool files to be included in OFIW and FSIW dialogs? or would you have to uncheck the "show only symbols defined in current workspace" check?

thanks
feline Posted - Mar 27 2006 : 5:25:40 PM
in my test i used a relative directory variable via the property pages. once this is fixed, should this cover all of your problems? or are there additional things going on here?
feline Posted - Mar 24 2006 : 6:26:16 PM
i have reproduced the property pages not being supported

case=1072
swinefeaster Posted - Mar 22 2006 : 5:13:04 PM
ok i just send you another video *gulp* of how you can set up a user macro and all that. let me know if you need more info on anything.

swine
feline Posted - Mar 22 2006 : 3:30:19 PM
i agree these macro's should be supported. *goes and scans the entire thread*

i never did work out how you are supposed to specify these variables in files. the link you posted did not get me very far. can you post the content of a basic .vsprops file to this thread? i can then just take an existing one, and try to make it work here.

i am getting confused by the number of points we are dealing with at once in this thread, so if you don't mind lets try to do this one small step at a time.

if i can produce a small sample project, where a .vsprops file is used to define an environment variable - just like your $(SharePoolDir) - then we have a nice clear example. this bypasses the whole question of relative directories, and lets us focus on what we want VA to do.
swinefeaster Posted - Mar 21 2006 : 6:36:17 PM
sorry i was unclear --- 1444 did not change the workings of the OFIW or FSIW dialogs, but rather broke the autocomplete suggestions for sharepool symbols (the uncolored symbols like i showed you in the video).

yes, i am using the "good ol' right click on project" method. but no it is not an enviroment variable, but a vs2005 officially-accepted user macro ;), which my whole point is that you guys should support it!

cheers,

matus
feline Posted - Mar 21 2006 : 6:10:17 PM
i have just checked, VS2003 and VA 1440 the OFIW dialog lists all open files. retesting this in VS2005 with VA 1444 and any open *.txt files or *.cpp files that are not part of the solution are listed in OFIW.

so this still works for me, so i would expect it to work for you.

i am expecting VA to parse your projects additional include directories, presuming they are actually set using the good old right click on project in solution explorer -> properties method. you appear to be using an environment variable here to indicate the correct location for the SharePool source code. is this true?

do you know which version of VA you were using before? 1440 does not seem to contain much in the way of fixes above and beyond 1440, so you may find moving back to 1440 helps. however by the same logic 1444 should not have broken things for you.
feline Posted - Mar 20 2006 : 5:47:13 PM
i have the movie, apologies for the delay, i have been down with the flu *sigh*

these movies are both helpful and very hard to follow, since you know what you are doing, but i have to guess what you are doing and what to follow attention to.

for OFIW it *looked* like a SharePool file was listed as long as it was open, but only if it was open. is that correct? if so then this explains what is going on, and in fact this is not actually related to the directory structure layout at all.

the bigger mystery to me is that VA seems to know all about these SharePool classes, so it seems to have found the code. but how has it found the code?

can you post the information you get from:

VA Options -> About -> Copy Info

this may not help, but it is a start. somehow, from somewhere, VA is picking up the SharePool code. once we know how and where this should help.

as for F7, from the following to links:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=3038
http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_072804a.aspx

you probably want to remap F7 to "Build.BuildOnlyProject" in IDE tools menu -> options -> environment -> keyboard
this is what Microsoft say does this, but you may want to check out "Build.BuildSelection"
swinefeaster Posted - Mar 17 2006 : 9:10:50 PM
ok i can no longer alt+g into the SharePool code now that i updated to 1444. this is becoming more of a problem :(.
swinefeaster Posted - Mar 13 2006 : 5:08:33 PM
ok i just sent you a video of this.
swinefeaster Posted - Mar 13 2006 : 5:00:03 PM
well there's no concept of Active Project in .net. in vc6 you just set the active project and that builds, along with all its dependencies. in vc8, you can set up a startup project, but that's different. F7 still always builds the whole solution. the only way of doing one project is to right click on it and go Build --- using the mouse just sucks.

yes, alt_g always jumps to the correct tree...
feline Posted - Mar 13 2006 : 4:26:56 PM
*ouch* i was not aware that VS2005 had broken F7. have you looked into IDE build menu -> configuration manager ?

i have often used this in VS2003 to trim down the build size, but i have not really used it in VS2005. hopefully unticking SharePool in here will stop the IDE from ever building it.

personally i am confused by alt-g working. does alt-g always jump into the correct SharePool directory tree?

at a very basic level what works and what is broken? does VA offer suggestions on the classes from SharePool? are they coloured as types?
swinefeaster Posted - Mar 13 2006 : 1:48:18 PM
Yes, I have a project for SharePool. I usally build it in another instance of vc8, but only if i have to.

Yes, alt-g does allow me to jump into SharePool. And after the file opens, it appears in the OFIW and FSIW dialogs (even though its not in the workspace).

Get from default intellisense is OFF.

I don't really want to add SharePool to the solution. That would definitely get vc all excited, and especially now that they totally screwed up the function of F7 --- SharePool would also build each time I pressed F7, even with no dependencies.

Thanks,

swine
feline Posted - Mar 11 2006 : 11:40:10 AM
now i understand. at this point we need to focus on finding you a work around, since any change to VA will take time to appear.

i am making the wild assumption that you have a solution for SharePool, so you in fact have:

C:\\Branch1\\SharePool\\SharePool.vcproj
C:\\Branch2\\SharePool\\SharePool.vcproj

these solutions are used to actually compile SharePool, so by definition they must actually be kept up to date, or else SharePool would stop building.

have you considered simply adding the relevant SharePool.vcproj to PcApp as a project, and then removing all build dependencies? this does still leave you with the problem of VS2005 getting all excited though, which can be bad if you are using C++.

what have you set:

VA Options -> text editor -> listboxes -> get content from default intellisense

to? the fact that you are getting intellisense on this code is interesting. does alt-g allow you to jump into the SharePool directory tree?
swinefeaster Posted - Mar 10 2006 : 7:55:20 PM
ok let me explain!

we have two solutions, one called SharePool (it's got all the common stuff in dlls), and one called PcApp for example (it's builds the exe).

directory structure is as follows:

c:\\Branch1\\SharePool
c:\\Branch1\\PcApp

c:\\Branch2\\SharePool
c:\\Branch2\\PcApp

so... PcApp links to SharePool in its branch, relatively. actually we define a user macro called $(SharePoolDir) which in PcApp is "$(SolutionDir)..\\SharePool\\" and thus becomes "c:\\Branch1\\PcApp\\..\\SharePool".

most developers wont need to build SharePool at all, as the compiled dll binaries are shared on a network folder, and we got custom build steps to copy them over for the correct branch ;).

i don't wanna just include all those headers from SharePool in PcApp, as i would have to manually take out all the cpps, and then maintain any changes to synchronize it with the SharePool solution.

vc8 has no problem finding the headers. i can even do autocomplete with VAX (or is it being done by vc8?) but those symbols in SharePool are not colored in the autocomplete dropdown box, and most importantly, these symbols cannot be found in the OFIW and FSIW dialogs, as they are not in the workspace.

it would be great if i could add extra solution-relative directories (or using vc8 user macros) so that these symbols would appear. again i don't want to add them to the solution, as that would make vc8 think too much...

cheers,

swine

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