Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 massively incorrect coloring of C++/CLI code

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
bvoigt Posted - Jul 07 2006 : 11:27:42 AM
Just installed the 30-day trial of Visual Assist X while my supervisor prepares the purchase order. It looks very nice, highlighting types vs. methods. Problem is, nearly every construct contains something colored wrong.

Here's the code I'm in the midst of writing that exhibits the bad highlighting behavior. Can anyone else confirm they get the same horrible results?

#pragma once

using namespace System;
using namespace System::Collections::Generic;

namespace LTM
{
ref class PrioritizedWorkScheduler
{
public:
enum class ScheduledTaskKey : long
{
};

private:
ref class ScheduledTask sealed : IKeyed<ScheduledTaskKey>
{
static ScheduledTaskKey nextKey = (ScheduledTaskKey)0;

initonly ScheduledTaskKey me;

public:
enum class Status
{
Waiting,
Cancelled,
Expired
};

ScheduledTask( void )
{
me = nextKey++;
}

Status state;
EventHandler^ callback;
DateTime alarmTime;
property ScheduledTaskKey Key
{
virtual ScheduledTaskKey get() { return me; }
}
};

List<LinkedListNode<ScheduledTask^>^> taskLookup;
LinkedList<ScheduledTask^> upcomingTasks;
LinkedList<ScheduledTask^> taskPool;

void Schedule( LinkedListNode<ScheduledTask^>^ scheduleTask, DateTime alarmTime )
{
ScheduledTask^ task = scheduleTask->Value;
task->alarmTime = alarmTime;

LinkedListNode<ScheduledTask^>^ iter = upcomingTasks.First;
while (iter != nullptr && iter->Value->alarmTime < alarmTime)
iter = iter->Next;

upcomingTasks.AddBefore(iter, scheduleTask);
task->state = ScheduledTask::Status::Waiting;
}
public:
PrioritizedWorkScheduler(void)
{
}

ScheduledTaskKey Add( EventHandler^ handler, DateTime alarmTime )
{
LinkedListNode<ScheduledTask^>^ addTask;
if (taskPool.Count == 0) {
addTask = gcnew LinkedListNode<ScheduledTask^>(gcnew ScheduledTask());
taskLookup.Add(addTask);
}
else {
addTask = taskPool.First;
taskPool.RemoveFirst();
}

Schedule(addTask, alarmTime);

ScheduledTask^ task = addTask->Value;
task->callback = handler;
return task->Key;
}

void Cancel( ScheduledTaskKey key )
{
}

void Reschedule( ScheduledTaskKey key, DateTime nextAlarmTime )
{
LinkedListNode<ScheduledTask^>^ rerunTask = taskLookup[(int)key];
Schedule(rerunTask, nextAlarmTime);
}
public:

virtual ~PrioritizedWorkScheduler(void)
{
}
};
}
14   L A T E S T    R E P L I E S    (Newest First)
support Posted - Feb 29 2012 : 1:24:02 PM
case=3293 is fixed in build 1901
air2 Posted - Dec 24 2008 : 05:50:16 AM
Well thats half of the solution.
Now the class memebers do not get underlined (unregonized) anymore as misspelled symbols. But the syntax colouring is still incorrect.
I added also:

ref class MyClass;
ref class MyClass sealed
{

};

Now the syntax colouring is correct and the misspelled symbols are gone (because of the #define sealed) So thankx for the help.
feline Posted - Dec 23 2008 : 4:40:56 PM
This is a known problem:

case=3293

For now the work around is to edit VA's "StdAfx.h" file as explained in this FAQ entry:

http://docs.wholetomato.com?W302

and add the entry:

#define sealed

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
air2 Posted - Dec 23 2008 : 09:59:33 AM
It looks like sealed classes are not recognized.

for example:
public ref class GlobalLog sealed
{

}

Does not get recognized.
I am using:

VA_X.dll file version 10.5.1711.0 built 2008.12.11
Licensed to:
VA X: [email protected] (6-user license) Support ends 2009.09.16
DevEnv.exe version 9.0.30729.1
msenv.dll version 9.0.30729.1
Font: Consolas 13(Pixels)
Comctl32.dll version 6.0.3790.3959
Windows Server 2003 5.2 Build 3790 Service Pack 2
4 processors

Platform: Win32
Stable Includes:
D:\\SDK\\lotus\\notesc\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.1\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.1\\common\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.1\\include;
D:\\SDK\\novell\\ndk\\novell-w32sdkc-devel-2006.06.16-1netware_windows\\clib\\include;
D:\\SDK\\novell\\ndk\\novell-gwadmin-devel-2007.04.26-1windows\\include;
D:\\SDK\\novell\\ndk\\novell-nmas-devel-2006.10.23-1cross_platform\\nmas_mgmt_sdk\\ldap\\c_mgmt_sdk\\sdkinc;
D:\\SDK\\novell\\ndk\\novell-nmas-devel-2006.10.23-1cross_platform\\nmas_client_sdk\\sdkinc;

Other Includes:

Stable Source Directories:
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfc;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\atl;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\crt\\src;


hotzenplotz Posted - Sep 24 2008 : 2:18:58 PM
feline,
I'm sorry to have caused confusion. I meant references to member-variables inside finalizers (i.e. the "code" in the finalizer-function), but it seems like that's already fixed. I'm sure there was a problem not all that long ago, but I don't see the problem with either 1647 or 1649...
Sorry again.
feline Posted - Sep 17 2008 : 6:35:02 PM
There are some known problems with C++ CLI but we are working on these. So far I cannot reproduce this finaliser problem, using VS2005 and VA 1649. I have added this code to a header file:

ref class testFontColourClrFinaliser
{
!testFontColourClrFinaliser();

void memberAfterFinaliser();
int nSize;
};


and this code to the matching cpp file:

testFontColourClrFinaliser::!testFontColourClrFinaliser() { }

void testFontColourClrFinaliser::memberAfterFinaliser() { }


The code compiles quite happily, but I am not seeing any underlining in either block. Other things in the two files are underlined, proving that underlining is active.

Do you see the underlining problem with this code on your system?
hotzenplotz Posted - Sep 16 2008 : 12:47:45 PM
My personal expirience is that syntax coloring in C++/CLI works far worse compared to native C++.
BTW: VAX doesn't understand finalizers (Foo::!Foo), so all members will be underlined as mis-spelled.
(I'm still using Build 1647 - have to renew for build 1649, so I don't know if that's fixed in 1649)
support Posted - Sep 13 2008 : 01:22:54 AM
case=935 is fixed in build 1649
feline Posted - Jul 16 2006 : 1:12:00 PM
you make an interesting argument about the colouring of properties. i have put in a feature request for the developers to look at and consider.

case=1705

C++/CLI should be supported, but please note we are still getting regular reports of strange or invalid colouring in pure C++, so do not be to surprised if you get odd colouring bugs when using C++/CLI syntax.

the basic problem is that the colouring code only gets to see a very small amount of context when it runs, since it has to run very fast, and has to work around the IDE. the result is that it can get confused in various situations. we try to fix all of the bugs, but some are easier than others.

for posting screen shots i personally have an account at www.photobucket.com, but other people use other hosts. if you can post the code as well as the screen shot that always helps, otherwise i have to consider typing it in from the screen shot, which is not all that helpful.
bvoigt Posted - Jul 09 2006 : 8:22:51 PM
C++/CLI isn't the same as Managed C++, although it serves the same purpose. Microsoft's first attempt at CLR-targeted C++ was a flop, since any C++ assembly had a small chance of locking up during load, initialization order problems, lack of static constructors, poor support for finalization, etc.

C++/CLI, introduced with Visual Studio 2005, is the second attempt, and it is a lot better. Is it not a supported language for VA X? I noted that VA X was correctly handling tracking pointers so I assumed that it was, for example:

System::String^ str = "This is a string";
if (str.Contains("ring")) return 1;
       ^

VA X correctly changes the indicated . to a ->


Since C++/CLI is built on Common Language Infrastructure, the types are architected the same way (except for having indexed properties instead of indexers).

I continued working on the code after I posted it.... so I have a different file that I'm testing the beta builds on. I'll post it next time I'm at work. I'll also try to find a place to quickly post a screenshot showing the highlighting. But here's the sort of code that confuses VA X:

bool isListed(LinkedListNode<ScheduledTask^>^ task)
{
return (task->List != nullptr);
}

Here List is a property of LinkedListNode, not a type (actually it has type LinkedList<ScheduledTask^>^). Also ScheduledTask is highlighted like a method in the argument list, although it is used as a type.

Also, properties are different from fields. I think it would be far better to colorize properties as methods than use the same color as fields, because:
(1) The distinction is important, even though the syntax tries to hide it. Fields have an address, properties don't.
(2) I can tell a method vs. a property because a method is followed by parentheses. Coloring is the only way to tell field vs property at a glance.
(3) Although a property is not a method (it's defined by a collection of accessor methods), every access to a property is a function call. For example, these two lines are the same:

Textbox1->Font = this->Font;
Textbox1->set_Font(this->get_Font());


It would be handy to see properties as method calls because it tells me that (1) the principle of least surprise could be violated, (2) an exception can be thrown, and (3) it might take significantly longer than it looks if either Remoting or COM is involved, maybe just a context switch to native code, or maybe a inter-process or even networked RPC.

Just as an example, the following blocks look like they should end up at the same state:

{
for( int i = 0; i < 100; i++ ) Height++;
}
{
Height += 100;
}

If Height is a local or member variable, this is undoubtedly true. If Height is a property, it's probably still true. But if I'm dealing with a listbox with "integral number of items" set, then the first loop will likely not change the height at all.
Perhaps the best thing would be to make property coloring user-configurable. Then you can take a poll where we all fight out whether the installer ships with it set to the same color as fields, or same as methods, but at least we can each configure it to our liking.
feline Posted - Jul 08 2006 : 4:42:31 PM
i think the enum problem is covered by

case=935

the italics will be because VA is confused by the syntax, so does not realise you are defining something rather than referencing something that is a static symbol.


quote:
Originally posted by bvoigt

Many uses of LinkedListNode<T>::List (such as task->List), List is colored as a type, although it is a property get accessor and should therefore be colored as a function.


i am not seeing "task->List" in the code you posted.

i know basically nothing about Managed C++, but in C# (which i know a bit about) properties are not coloured as functions because they are not functions. they allow you to access or modify a member of a class, but that is not quite the same thing.
bvoigt Posted - Jul 07 2006 : 5:22:12 PM
Found the beta versions, installed the latest of those (see below).

Still troubled. Specifically, now ScheduledTask in ref class ScheduledTask correctly appears colored as a type (it did not in the stable build). The constructor ScheduledTask correctly appears colored as a function/method. However, in every tracking reference to ScheduledTask, ScheduledTask is incorrectly colored as a function. However in ScheduledTask::Status::Waiting, the coloring is correct.

Also, in enum class Status, in the stable build, the three members were colored differently. Now they are all colored as variables, but Cancelled and Expired appear in italics... how a declaration can be part of a class library I don't know.

Many uses of LinkedListNode<T>::List (such as task->List), List is colored as a type, although it is a property get accessor and should therefore be colored as a function.

VA_X.dll file version 10.3.1528.0 built 2006.06.30
VAOpsWin.dll version 1.3.3.3
VATE.dll version 1.0.5.7
DevEnv.exe version 8.0.50727.42
msenv.dll version 8.0.50727.42
Font: Courier New 18(Pixels)
Comctl32.dll version 6.0.2900.2180
Windows XP 5.1 Build 2600 Service Pack 2
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;
C:\\Program Files\\FTDISPI;

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:

bvoigt Posted - Jul 07 2006 : 4:37:11 PM
The latest version of VAX from the website, and Visual Studio 2005 (think C++/CLI and System.Collections.Generic aren't available in any other version).

Here's the info from the About screen:

VA_X.dll file version 10.2.1446.0 built 2006.05.31
Licensed to:
VA X:
VA.NET 7.1:
VAOpsWin.dll version 1.3.2.4
VATE.dll version 1.0.4.14
DevEnv.exe version 8.0.50727.42
msenv.dll version 8.0.50727.42
Font: Courier New 18(Pixels)
Comctl32.dll version 6.0.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
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;
C:\\Program Files\\FTDISPI;

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:

rhummer Posted - Jul 07 2006 : 11:48:14 AM
What version of VA X did you happen to install? and what IDE?

It's best to paste the infomation found at the following location:

VA X Options Dialog -> About ( and press the copy info button, it will put that information on your clipboard which you can paste into the forum )

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