Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Problems with listboxes and incorrect underlining

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
bewary Posted - Feb 12 2008 : 7:18:06 PM
I just want to echo others that have reported problems with listboxes and underlining not working properly. It is generally broken for me in builds 1626 & 1561. I have to enable Intellisense in order to get any sort of method list with the dot/arrow operator. I have to turn off the underlining of "mistyped symbols" in order to make my code readable.

This "fix" is a kludge and there's not much left in VA that works for me except the coloring of keywords.

FYI, I've tried uninstalling old versions of VA before installing new versions, as well as rebuilding the symbol database and restarting the IDE.

Please make this a priority fix.
15   L A T E S T    R E P L I E S    (Newest First)
feline Posted - May 22 2008 : 09:45:41 AM
The StdAfx.h edit, it would depend on the actual macros you are using, and sometimes requires a bit of experimentation. The basic idea is to show VA a very simple macro that bypasses the problems with macros including other macros.

Since I am not quite sure what your code looks like I am guessing what will work here, but having a macro resolve to a simple open or close curly bracket should be fairly safe.


Since the registry keys have worked for you I have added a FAQ entry describing them:

http://docs.wholetomato.com?W363

Turning this on by default is probably not a good idea. Firstly I suspect it caries a performance penalty. Secondly you do not always want VA evaluating all macro's as deeply as possible, for example INT is just fine as it is.

A final point to consider is that we do not want to encourage being to clever with macro's, because it is fairly easy to think up situations involving conditional macro's that VA is virtually unable to resolve correctly, since it does not know all of the #define values that will be set when compiling the code.
bewary Posted - May 21 2008 : 8:44:06 PM
feline,

I'm not sure exactly what to try for your first suggestion. In stdafx.h, should I enter the complete macros we are using or only the single curly brace?

Your second suggestion, the changes to the registry, seem to do the trick. If that doesn't cause other problems, maybe it could be turned on by default in future versions of VA?

Thanks,
B
feline Posted - May 20 2008 : 2:04:36 PM
There are two possible approaches here. The first is to add a couple of entries to VA's "StdAfx.h" file as explained in this FAQ entry:

http://docs.wholetomato.com?W302

and add something like:

#define begin() {
#define end }

at the bottom. 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


The second thing to try, if you have a recent version of VA, is to close all instances of the IDE and then create the following string registry key:

[HKEY_CURRENT_USER\\Software\\Whole Tomato\\Visual Assist X]
"LimitMacro"="No"

And set the following registry value:

[HKEY_CURRENT_USER\\Software\\Whole Tomato\\Visual Assist X\\VANet8]
"LimitMacroParsing"=hex:00

This was set to 01 (the default) for me on my test system. If you try this, after making these changes and loading the IDE does this make any difference? I have seen this work here, in some simple tests. If this works more generally then I will add an FAQ entry for this.
bewary Posted - May 19 2008 : 5:58:33 PM
Yes, but our solution is really only a work-around. It still seems like a bug that you guys should probably fix.

I'm pretty sure playing with settings won't help, as we've been playing with settings ad nauseam for many months across a few different versions of VA X (1440, 1561, 1626).
feline Posted - May 17 2008 : 09:48:42 AM
Are you happy with your solution?

There are a couple of things that we might be able to do with VA settings to try and fix this problem, but if you have solved the problem then there is no need.
bewary Posted - May 16 2008 : 2:30:44 PM
Feline,

I think I've found the exact cause of this problem. I tried your suggestion of moving the test function around in the file that was having underlining problems. The problem only occurred after I moved the function below code that uses a pair of macros. These macros are common throughout all of our code, which explains why so many of our developers were seeing this problem.

Here's the problem:

Using a macro that takes empty parentheses and is defined as another macro, which in turn contains only one curly brace.

Pretty obscure, eh? Here's an example, albeit fairly illogical:

#define begin() begin1
#define begin1 int b1; {

#define end end1
#define end1 int e1; }

//this function does not have underlines
void MyFunc1(int x)
{
begin();

x = 1;

end;

}

//in this function, MyFunc2, y, and m are underlined and not recognized (and sometimes MyObject too)
void MyFunc2(int y)
{
y = 2;
MyObject m;
m. //using the dot operator fails to bring up MyObject methods
}

I should note that MyFunc2() can also contain the begin/end macros and the underlines are still there.

Here are the details that I discovered through a lot of trial and error:

1) The macros cause problems only if they include an unmatched curly brace (even if the matched brace is in another macro)
2) The macros cause problems only if one, and only one, takes empty parentheses (i.e., both macros can take empty parentheses, or both no parentheses, and everything is fine)
3) The macros need to call other macros for the problem to manifest
4) It is often helpful to clear the cache and rebuild the symbol database during testing
5) The macros can be defined in any file
6) Almost all of our code is in namespaces

I have worked around this problem by removing the empty parentheses from the "begin()" macro definition. Luckily we don't have to change all of our calls to "begin()" since the empty parentheses in the source are ignored by the compiler. VA X now appears to be working properly for us.

Thanks for your help!
B
feline Posted - May 13 2008 : 10:20:31 AM
This is progress, even if it does not feel that way

VA does not underline anything in a file when you first open it. You need to edit the file before VA starts underlining. This is a performance optimisation, to speed up just opening and reading files.

In the main file where this test code is underlined, can you try placing the test function below the #include statements but above all of the functions? Do you still see underlining?

If you do can you try moving it to above everything, so it is the very first thing in the file. Do you still see underlining?

By simply moving the function up and down the file you may be able to work out what triggers the underlining problem.

If a specific header file looks to be the problem, can you try opening this header file, and placing the text function into the header file, and see what happens? Does VA still underline the code, or is it understood correctly?
bewary Posted - May 13 2008 : 09:47:45 AM
feline,

We do not have a plug-in for editting or running Doxygen. It is simply run as a pre-build event.

I tried your test. That simple function at the end of an existing project file causes VA to underline MyFunc and x. Putting it in it's own file produces no problems. The weird thing is that even if I include the same header file (stdafx.h), VA doesn't exhibit problems when the func is in its own file. Does VA not parse stdafx.h if it doesn't need to?

The odd thing is that I can include objects defined in other project files, and VA recognizes them even if I don't #include the correct header file.

I also tried putting the func inside the project namespace in both files, but it didn't seem to have an effect.

Finally, I cleared the cache and told VA to rebuild the symbol database. Upon restarting the IDE and opening the solution, VA reparsed the code. When it was done, the MyFunc test code that was previously underlined was recognized correctly by VA. However, as soon I started to edit the code, it was immediately forgotten and VA underlined it. This does not happen in the stand-alone file you had me create.

It appears the problem may be related to code in the included header files. Incidentally, most of our Doxygen documentation is in our header files. This could get tricky to track down. Unfortunately, I don't have time to add headers until VA breaks. I'm not sure how I'd do that anyway since including the same stdafx.h in the new file doesn't cause problems. Ugh!
feline Posted - May 13 2008 : 08:26:46 AM
Do you have any form of IDE plugin for working with Doxygen? When I have used Doxygen it was a stand alone program that scanned the source code, and had no impact on the IDE.

You are quite right, if you open a single file on its own VA will not know about any other directories, files, etc. So some things will be underlined as mistyped symbols.

The fact that VA seemed to work fairly well on the file on its own suggests that the Doxygen comments are not the problem.

Looking back over this thread, you produced the very simple example:

void MyFunc (int x)
{
    x = 1;
    return;
}


and said that VA does not understand this.

In your main solution can you please add a new CPP file, and then just add this test function to this file, so this is the only code in the file. Do you still see problems, or does this work correctly?

It is possible one of your header files is causing problems for our parser. If so, any code below the problem #include line might show problems. If so then this function should work correctly in a new, empty file, but show problems when placed at the bottom of one of your normal code files.
bewary Posted - May 12 2008 : 2:29:22 PM
feline,

I tested a simple function as you suggested. When inside the project/solution in VS2005, VA underlined my object variable a few seconds after I typed it. Before VA underlined it though, VA seemed to recognize what it was and the dot operator correctly brought up the member function list. However, as soon as VA underlined everything, the dot operator no longer worked.

I then opened the same file stand-alone in VS2005. The underlines no longer appear and everything seems to be normal with the new function I created. However, other parts of the file are underlined and unrecognized by VA. My guess is that VA does know about the other directories and paths that it would need to parse when I open the files outside of the project file. We also use environment variables to provide code locations, though this is nothing new for us and VA has worked fine with those in the past.

The only other difference I can think of between my projects that work vs. the one that doesn't is that the latter uses ClearCase for source control. We do have a few ClearCase-specific settings in our VCPROJ files, though if I remove them it doesn't help VA. Also, we usually let DevStudio automatically generate our solution files.

As far as Doxygen goes, we use it fairly extensively both in header and CPP code. We use a lot of the available syntax, including @brief, @details, @return, @param, etc. and same-line variable comments like //!<

We also use the most recent version of Doxygen.

So at this point it looks like the problem is a VCPROJ/Solution file setting. It's also possible the Doxygen is the culprit and it did not interfere in my single-file test because it was not parsed by VA.

Thanks,
B
feline Posted - May 12 2008 : 12:19:18 PM
VA Outline is a relatively new feature, you will see it if you are using VA 1626.

The fact that you are seeing this problem across such a wide range of VA versions suggests that it is fairly fundamental.

I do not see anything odd in your VA about info.

Lets see if we can find out what is going on here. Consider this very simple example, all of this code is placed into a single header file:

class testDoxygenCommentedClass
{
	//************************************
	// Method:    getHeight
	// FullName:  testDoxygenCommentedClass::getHeight
	// Access:    private 
	// Returns:   int
	// Qualifier:
	//************************************
	int getHeight()	{ return 1; }
	//************************************
	// Method:    getWidth
	// FullName:  testDoxygenCommentedClass::getWidth
	// Access:    private 
	// Returns:   int
	// Qualifier:
	//************************************
	int getWidth()  { return 2; }
};

static void testUsingClass
{
	testDoxygenCommentedClass foo;
	foo|;
}


If I now type a dot where the red caret is VA lists the class members for me. Obviously the comments here are not actually Doxygen format, but I have used VA with Doxygen format comments without a problem. So there must be something different about your comments.

Can you take one of your problem classes, and add a simple "testing" function at the bottom, to use the class in the file, and see if you get any problems?

If you do, can you open this file on its own in the IDE, so No solution open. I am wondering if the problem can be reproduced like this, in isolation. Does this make sense?

It is possible the Doxygen comments are not actually a factor, and that something else in this project is causing the problem. This test should help us to find out if this is the case or not.
bewary Posted - May 12 2008 : 11:53:06 AM
Feline, here's the info:

VA_X.dll file version 10.3.1559.0 built 2007.07.06
Licensed to:
VA X: ... (35-user license) Support ends 2008.08.14
VAOpsWin.dll version 1.3.2.4
VATE.dll version 1.0.5.8
DevEnv.exe version 8.0.50727.762
msenv.dll version 8.0.50727.762
Font: Courier New 13(Pixels)
Comctl32.dll version 6.10.6000.16386
Windows Vista 6.0 Build 6000
2 processors

Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;

Library Includes:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\crt\\src;

Other Includes:
___________________________________________

As far as your other questions:

* The alt-m list is correct except that it leaves out the operator= method.
* I am not seeing a VA Outline option. Perhaps that feature is not in the version I am using. I have also tried VA X v1440 and 1626, but they all exhibit the same problems with the code using Doxygen.

Another potentially important bit that I left out: the large non-Doxygen project that works fine with VA X is using DevStudio .Net 2003. The problems we are currently having are in DevStudio 2005. However, I converted a smaller non-Doxygen project from VS2003 to VS2005, and VA works fine as far as I can tell in VS2005. This seems to point to Doxygen syntax as the culprit.

Thanks,
B
feline Posted - May 10 2008 : 09:34:35 AM
Clearly something is going very wrong here. I have some experience with Doxygen, but when I used it it was only ever structured comments. Comments should not cause any problems for VA.

Are you actually using C or C++ style comments, or are you doing something like:

#if 0
this is a doxygen comment block here
#endif


Can you please go to:

VA Options -> System Info -> Copy Info

and paste the details (from the clipboard) into your reply. This will give us the basic information about your setup.

If you sit in a problem file and use alt-m to show the list of functions in the file, is this list correct? Slightly correct? Totally wrong?

If you show VA Outline how correct is the information that it shows?
bewary Posted - May 09 2008 : 2:39:48 PM
Feline,

The problems I tried to describe generally occur everywhere in our code, not just with templates inside templates. For example:

void MyFunc (int x)
{
x = 1;
return;
}

Even in code as simple as that, x is underlined by VA and VA cannot tell me it's an int.

Now, I have an interesting development. My team has a product that uses no Doxygen (http://www.stack.nl/~dimitri/doxygen/index.html) commenting at all. I worked with that project for years with VA and had no problems at all. When my team started up a new project and began using Doxygen heavily, most of us started having VA problems as I have described. There is a lot of unique syntax in Doxygen, and I wonder if it is confusing VA. Have you guys tested VA extensively with code that makes heavy use of Doxygen?

I should note that after using VA for a week or two without fiddling with the options (i.e., I gave up), VA started recognizing more and more and now it often brings up member function lists when using the dot/arrow operator. It still randomly has the problems I've described, but it is better and I have no explanation as to why. Also of note, I turned off "Get Content from Default Intellisense". That option wasn't the panacea I hoped it would be.

Thanks for listening.
B
feline Posted - Feb 13 2008 : 08:26:04 AM
There is a known problem with using STL iterators across STL types that use a template inside a template, e.g.

typedef std::map<long, std::pair<long, long> > typedefComplexMapFullName;

This particular issue has been fixed internally, and should be fixed in the next build of VA.

Is this something you do a lot of? Without some idea of what is causing your problems I cannot say if we are working on it, or even aware of the problem.

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