Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Feature Requests

Format symbols per type

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

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

Check to include your profile signature.
Check to subscribe to this topic.

T O P I C R E V I E W
TLHobbes	Posted - May 09 2007 : 9:42:08 PM It would be cool if the formatting (color, bold & italic) of sub-types of symbols was exposed in Fonts and Colors. Symbol subtypes may include: globals locals members static globals static members stables parameters etc.. Specifically it would be cool to have settings (color combobox, bold checkbox & italic checkbox) for each symbol subtype. Most people have naming conventions to differentiate some of these so it only seems complimentary to provide optional visual formatting differences as well. It makes sense that these options (if provided) could be available as overrides, so user don't have to use them if they don't want to and those that care can override just the subtypes of interest to them.
5 L A T E S T R E P L I E S (Newest First)
feline	Posted - May 14 2007 : 10:36:26 AM ah now I see. Getting me to understand a bug report, sometimes harder than it should be due to the way I approach things, sorry about that. I would not have expected this to cause a problem. After a bit of testing it turns out to be the keyword "struct" causing the problem. Change the problem code to: struct Foo { int bar; }; /* struct */ Foo foo; for me this fixes the problem. I can sort of see what VA is thinking here. case=6567
sl@sh	Posted - May 14 2007 : 03:52:57 AM You misread my problem (or maybe I just did a bad job of describing it). It's not another class name with case variance, but a variable's name. What I get is this: struct Foo { int bar; }; struct Foo foo; No other code needed to get the effect. I just tried sth. different however: when I use type int for the variable declaration, then the coloring is correct again: struct Foo { int bar; }; int foo; Here's the version info for sake of completeness: VA_X.dll file version 10.3.1543.0 built 2006.12.19 Licensed to: [...] VAOpsWin.dll version 1.3.4.1 VATE.dll version 1.0.5.5 DevEnv.exe version 7.10.3077.0 msenv.dll version 7.10.3077.0 Font: Courier New 13(Pixels) Comctl32.dll version 5.82.2900.2982 Windows XP 5.1 Build 2600 Service Pack 2 2 processors Platform: Win32 Stable Includes: C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include; C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include; C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include\\prerelease; C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include; C:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include; Library Includes: C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\mfc; C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\atl; C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\crt\\src; Other Includes:
feline	Posted - May 11 2007 : 08:36:11 AM I have never seen this Foo and foo problem myself. The following quick test produced: class CTestClassCase { }; static void testCase() { CTestClassCase foo; // type is blue ctestclasscase bar; // type is black and underlined as mistyped symbol } I suspect this was related to VA being confused by your code base, which would make it rather hard to reproduce in a simple test case.
sl@sh	Posted - May 11 2007 : 05:02:41 AM Talking about coloring edge cases: I noticed VA doesn't consider case when determining symbol coloring. If there's a class Foo and a variable named foo, the variable name will be colored blue - as if it were a class symbol. This might be fixed in the newest version however - I'm still using build 1543. As for other edge cases: IME miscoloring sometimes happens on symbols within files with multiple levels of #including and dependencies on a lot of different declarations spread over various files. So far I haven't been able to nail any down to a 'simple' example. On a sidenote, the number of such occurences have been significantly diminished since I did the 'refactoring' I mentioned in another topic, when I resolved several hundred source file dependencies to avoid unneccesary #includes. So, reducing the number of files #included (directly or indirectly) within any implementation file apparently helps a lot.
feline	Posted - May 10 2007 : 07:16:18 AM Part of the answer is here: http://docs.wholetomato.com?W146 Another part of the answer is that our current colouring code has edge cases where it does not work correctly, if you know where to find them. So adding more types to the mix, before we have resolved the edge cases with the current code, is not going to help.

Snitz Forums 2000