Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Color coding not functioning correctly

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
NOPcode Posted - Sep 25 2008 : 11:01:19 AM
current 1649 build, VS2008 sp1.
This has been a long-running annoyance for me, and every new build I think it's fixed but then comes back.

The color coder will quite often think that class names are local symbols, when they are not. It will often screw up and also think that base class functions are local symbols. Also, it will think that some class names are preprocessor macros when they are not.

Going back and forth between two open files I can see that VX will first color-code the class name properly (I chose Red so I can see it), and then apply the Variables color coding (grey) with the Local Symbols in Bold setting, or else color as a macro (purple).

Using the "Go" button takes me to the proper class definition .h file, and in both the class's .h and .cpp files the color coding for that class is correct.

19   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Oct 15 2008 : 1:35:08 PM
It would be foolish to rule out running two IDE's at once, but this should not be a factor. We have made some recent changes to try and fix the few remaining problems with running multiple IDE's at the same time.

Once the problem shows up if you place the caret into "double" what does VA show in its context and definition fields? Does alt-g do anything other than simply beep? I am wondering if VA has picked up some form of definition for "double" from somewhere.

If you use the variable does alt-g take you back to the declaration correctly? I am wondering if this is "only" a colouring bug, or if there is a parser problem at work here as well.
NOPcode Posted - Oct 15 2008 : 12:56:26 PM
quote:
Originally posted by feline
When this problem shows up what happens if you add a new "double" variable with a random name, just a random string of characters?



The member variable name doesn't matter. double eddgdfg would give the same result.

Is it remotely possible that the fact that I sometimes have both VS2008 and VS2003 (but not 2005) running at the same time be a factor?
feline Posted - Oct 10 2008 : 7:21:55 PM
This is very strange. It certainly sounds like something odd in the symbol database, which explains why the symbol database rebuild fixes it for a while. Not that it tells us the trigger.

When this problem shows up what happens if you add a new "double" variable with a random name, just a random string of characters?

I am wondering if the problem is specific to the combination of type + variable name, or if it effects all variable names, even ones that you have not used anywhere else in your project, hence the random variable name.
NOPcode Posted - Oct 02 2008 : 12:27:19 PM
I was able to catch it not color coding member data properly, and even got a screenshot of weirdness that *might* help. The project in question is a Win32 dll, and does not use SQLite (or any other 3rd party libs), but I do have SQLite in other projects and it's in the VS2008 include settings. If I change the type from double to int it colors properly, but changing it back (or an int member to a double), it doesn't. Hovering over the double keyword doesn't get any action, unlike if I did DWORD for example.
Intillisense Quick Info shows the proper tooltip.
Clearing the VAX cache and letting it rebuild makes it go away for a while.

What is color coded wrong.




And I get this for a tooltop. The tips for the items above and below it are right - ex: bool myclass::m_fSyncMaster
NOPcode Posted - Oct 02 2008 : 07:22:50 AM
quote:
Originally posted by feline

Do you have any other IDE plugins installed?

Any system utilities that might be trapping the mouse pointer?

I don't see how these two things could be connected, but you should not be seeing either problem, so maybe they are.



No, just VX 1469. No macros, either. I *do* also have VS2003 and use it, because of some legacy code we're slowly porting away from.

I can't speak to the VS2005 mouse problem (I never saw it there before I upgraded to VS2008, and even then, it was at a C# shop, not C++ as now), but my experience matches Dany's, but I don't have any of the things he has installed.

Basically, on my dev machine, I try to keep it very clean to avoid any interactions with the software and to avoid "all other developers must have XYZ in order to code like I do".
Dany Posted - Oct 02 2008 : 01:14:56 AM
I don't blame VA X for the mouse problem, because disabling it did not change anything. I just wanted to state, that it is not only on VS 2008 but on VS 2005 too, though I didn't see it in the last month or so.

My add-ins are:
- GhostDoc for VS 2005 (startup) -> acts only by command (menu or shortcut)
- Registry Explorer (no startup) -> acts only by command (menu)
- a self written one to put strings into resx (no startup) -> acts only by command (menu)
- VA X (startup)

The only system utility handling the mouse is VBScroll, which enables the scroll wheel in VB6 and Office VBA, but nothing with the buttons. And the mouse problem occurs on one source window only (switching to another one the mouse work just fine; going back -> *dang*).
feline Posted - Oct 01 2008 : 06:23:38 AM
Do you have any other IDE plugins installed?

Any system utilities that might be trapping the mouse pointer?

I don't see how these two things could be connected, but you should not be seeing either problem, so maybe they are.
Dany Posted - Oct 01 2008 : 01:01:54 AM
P.S.: The mouse problem appears in VS2005 as well (sometimes at least)... And sometimes only a right-click works before closing and re-opening.
feline Posted - Sep 30 2008 : 2:32:34 PM
I have no idea if the mouse problem is connected or not, but you should not be seeing problems like this with the mouse.

Have you installed VS2008 SP1 yet? In a recent forum thread someone reported that installing this fixed a problem they were having with the IDE. I don't remember the details off hand, but nothing here reminds me of that thread.
NOPcode Posted - Sep 30 2008 : 12:38:19 PM
Hmmm, maybe. The only thing that I have noticed (but did not think it was related) is that sometimes the mouse will not function in a source file (cannot select text or right-click), until I close that source file and re-open it (this is NOT by exiting VS2008, just closing fred.cpp and reopening it from the project).

I think the header was also mis-colored, but since it's not happening right now (of course)...

When it starts to happen I'll see if any of the things you mentioned fail and ping back here.
feline Posted - Sep 30 2008 : 08:12:46 AM
When you see this colouring problem are other things effected as well, or is it just colouring?

What about the Alt-m list, VA Outline, Alt-g, listboxes? If this was a wide ranging parser problem then I would expect problems to show up in other areas of VA, in other places as well.

If you look in a header file, at a class declaration, do you see the class name coloured correctly there or not?

Once the problem starts can you try adding a new, dummy class with a unique name (something totally random is fine) to a header file and see if the class name is coloured correctly or not?
NOPcode Posted - Sep 29 2008 : 11:16:13 AM
In the Performance setting, I have turned on:
Keep Symbols in Memory
Watch for external files
Parse all files

All code is local, no network drives at all.

I should mention that it is the exact same project from Friday to today, so the code amount didn't change from then to now.
feline Posted - Sep 29 2008 : 11:07:00 AM
The good news is that this rules out some things. It is not as simple as VA getting consistently confused.

Do you have:

VA Options -> Performance -> Parse all files when opening a project

turned On or Off?

Is all of your code local, or is any of it stored on some form of network drive?

If the amount of code VA is seeing / parsing is changing then this might explain things. Another thought is macros that have multiple definitions, so depending on the order in which files are parsed VA may be picking up different macro definitions.
NOPcode Posted - Sep 29 2008 : 07:24:56 AM
quote:
Originally posted by feline

Lets try a different approach. Do you see this problem for all class, or only some?
Does it only effect classes that you have created in your solution, or system classes and classes from 3rd party toolkits as well?

I am looking for some form of pattern, something to offer a clue as to the cause of the problem.




Some, but at times, all of them. As for which classes, it will at time affect both my own classes, the 3rd party classes, and ones where I derive from both - both simple and complex. I've tried to identify what is the root problem, but it seems fairly random - that is, it will not for a while have a problem, and then it will and clearing cache & etc won't fix it.

For example, I came in this morning and it's coloring correctly. But when I left Friday, it was not. I exit VC2008 when I leave for the day, but do NOT turn the computer off (nightly backups). It's rather maddening.

feline Posted - Sep 29 2008 : 06:35:16 AM
Lets try a different approach. Do you see this problem for all class, or only some?
Does it only effect classes that you have created in your solution, or system classes and classes from 3rd party toolkits as well?

I am looking for some form of pattern, something to offer a clue as to the cause of the problem.
NOPcode Posted - Sep 26 2008 : 7:34:48 PM
quote:
Originally posted by feline

If you change the class name in this macro call to some random symbol and give VA a few seconds to catch up with this, does this have any effect on the colouring problem you are seeing?.



Nope.
feline Posted - Sep 26 2008 : 10:02:23 AM
If you change the class name in this macro call to some random symbol and give VA a few seconds to catch up with this, does this have any effect on the colouring problem you are seeing?

I would not expect this to be causing your problem, but perhaps it is.
NOPcode Posted - Sep 25 2008 : 11:15:35 AM
No, it's not being used that way. The only thing that is even close to that is that a class name that is being colored as a macro or define is actually being used as a parameter in a macro. Ex:

DATAMEMBER(TheClass,tableName);

both DATAMEMBER and TheClass will be colored purple (macro/define) and tableName grey (variables). FWIW, DATAMEMBER is:

#define DATAMEMBER(dataType,dataMember) \ dataType dataMember;

(plus some ## concat stuff).


feline Posted - Sep 25 2008 : 11:08:54 AM
VA's colouring code has to run very quickly, to keep up with scrolling. Also it has to work behind the IDE's back, which is hard. The result is that it is possible to confuse our colouring code if the same symbol name is used for two different things.

In this case if you are using the class name for both a class and a parameter name or local variable then this can happen. If you do an IDE find in files for the class name and look at the results are you seeing cases where this name is used for a variable or parameter?

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