| T O P I C R E V I E W |
| Uniwares |
Posted - Mar 09 2006 : 2:29:21 PM
The class (Uniwares::Net::DNS::DNSBasedList) is listed twice in the member list. The first entry points to the line where the class is declared, the second to the line at the opening bracket of the class declaration.
Another question here: why is the ordering of the classes wrong? the Uniwares namespace is last, while Uniwares::Net is first.
The class definition is like
namespace Uniwares
{
namespace Net
{
namespace DNS
{
class DNSBasedList : public Uniwares::Diagnostics::LogProducer, Uniwares::Diagnostics::PerformanceInformationProducer
{
// lots of declarations here ...
};
} // namespace DNS
} // namespace Net
} // namespace Uniwares
Hmm, now, looking at the member list, I cant help wondering why the notation is Uniwares.Net.DNS. instead of Uniwares::Net::DNS:: since this is C++ code. Seems questionable to me.
Something more:
When I use the up/down arrows of the member list (how are they called? Prev/Next scope? Context? Well, you know, the ones besides the drop down button) it shows a bit of a strange information.
Positioning the cursor in the line before the first name space and clicking down, the following is shown in the drop list edit while clicking through:
DNSBasedList.h
Uniwares
Uniwares.Net
Uniwares.Net.DNS
Uniwares.Diagnostics.PerformanceInformationProducer
Uniwares.Net.DNS.DNSBasedList
Uniwares.Net.DNS
Uniwares
Eh? Where does it find the ...Diagnostics... ? and why does it skip the Uniwares.Net entry at the end? And doing the same upwards, brings a different result again:
Uniwares
Uniwares.Net.DNS.DNSBasedList
Uniwares.Diagnostics.PerformanceInformationProducer
Uniwares.Net.DNS
Uniwares.Net
Uniwares
DNSBasedList.h
Ah, yeah, the DNSBasedList.h entry is wrongly colored - the .h is black while the name is blue.
|
| 8 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Apr 14 2007 : 12:04:26 AM
Fixed 1027 in build 1553. |
| support |
Posted - Jun 19 2006 : 4:47:24 PM
Fixed 1028 in build 1524. |
| feline |
Posted - Mar 12 2006 : 3:04:40 PM
i have received the file, thank you. i have now been able to reproduce the mixed colouring of the file name in the context field, so that is something.
case=1031
it seems to be triggered by having a filename (minus the extension) that is the same as a type in that file. odd that i have never noticed this before, i would expect to run into this in my own code.
as for the positioning in the file and context field display, i have tried opening this file in a C++ project in both VS2003 and VS2005 with VA 1442 installed in both.
using keyboard shortcuts or the wizard bar buttons for next and previous context produces the same results in all cases. specifically:
starting at line 1 and going down the file:
line 1 = DNSBasedListEntry.h
line 19 = Uniwares
line 21 = Uniwares.Net
line 23 = Uniwares.Net.DNS
line 25 = Uniwares.Net.DNS.DNSBasedListEntry
thats it, it will not jump any lower.
now starting at the bottom of the file and going upwards i get:
line 25 = Uniwares.Net.DNS.DNSBasedListEntry
line 23 = Uniwares.Net.DNS
line 21 = Uniwares.Net
line 19 = Uniwares
line 1 = DNSBasedListEntry.h
grasping at straws time, are UNIX (or some other OS) servers involved? i am just wondering if the files were stored on a UNIX box and read via some form of share, or anything like that.
i have just remembered you run GC across your files, does this seem to be a factor? if you open the file you emailed me does next and previous context behave normally? i am assuming that i have a "perfect" copy of the file, which may not be true.
i am not even close to what you are seeing. |
| feline |
Posted - Mar 11 2006 : 11:53:20 AM
odd. please, it would be helpful if you can send me the file. i should be seeing the same things you are, but clearly i am not. |
| Uniwares |
Posted - Mar 10 2006 : 3:47:22 PM
Thats pretty much all that is to the .h file. Nothing more complicated than your sample (I can send you the file if that helps).
The Uniwares.Diagnostics.PerformanceInformationProducer jumps to the opening bracket of the class x)
and that base class is actually just a dummy (yet) - ctor/dtor only. |
| feline |
Posted - Mar 10 2006 : 3:05:16 PM
there is obviously something i have not replicated here. using the test class:
namespace Uniwares
{
namespace Net
{
namespace DNS
{
class DNSBasedList : public Uniwares::Diagnostics::LogProducer, Uniwares::Diagnostics::PerformanceInformationProducer
{
public:
enum DNS_TYPE
{ BLUE, PINK, // lowest point i can jump to with next / previous context
ORANGE, RED };
public:
DNSBasedList();
void setCOlour(int a);
int getColour() const;
};
} // namespace DNS
} // namespace Net
} // namespace Uniwares
moving through the header with next and previous the lowest point i can get to is the open curly bracket on the enum. as such i cannot get the second half of the set of locations, which you do seem to be getting.
as for the item:
Uniwares.Diagnostics.PerformanceInformationProducer
its a complete mystery to me. what line of code does this relate to? VA must be picking up something, but that something does not seem to be in your sample.
i will ask support about :: vs dot, since your point about mixing C++ and C# is very good. i just tend to accept this, because i am used to it, and make very little use of namespaces. but that does not mean that it is right  |
| Uniwares |
Posted - Mar 09 2006 : 6:15:45 PM
At least the standard scope list of VS shows the notation correctly. Dot for C# and :: for C++. Although its readable with the dot, its confusing, even more when you have both C# and C++ code in your project.
There are no inline functions in the class. Actually its a very straight class, nothing special, some public, some private and some protected members, but neither inline nor templates. It contains one enum definition. |
| feline |
Posted - Mar 09 2006 : 5:56:14 PM
thank you for the code snippet, i probably would not have got the double entry without it. removing either base class from DNSBasedList removes the double entry, so it seems that VA's parser is confused by multiple inheritance.
case=1027
i get the namespace at the end when this list is sorted into alphabetical order. obviously a bug in the comparison function
case=1028
the notation of dot rather than :: seems to be standard, you get the same thing in the context and definition fields. i suspect this is done to cut down on space, so you can get more text into the area, and to make it more readable. it is odd, but it does seem quite readable, at least to me.
i am not getting anywhere with the odd information displayed in the context field when using next and previous context. do you have inline functions in this header file?
also i cannot reproduce the odd colouring of the file name, although support were able to reproduce this on tooltips when i could not. |
|
|
