Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 Interfaces and alt-g
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

clintsinger
New Member

8 Posts

Posted - Aug 14 2006 :  2:44:19 PM  Show Profile  Reply with Quote
Hi,

First of all this post is about c++.

I have a frustrating problem with regards to alt-g and interfaces. When I have a class that implements an interface and I create a pointer to that class onto a variable of the interface, when I alt-g on it takes me to the Interface class where the Method is defined. While I realize this is the behaviour that should be expected, it isn't what I want.

What I really want is a pop-up that lists the classes in my project that implement the interface. More specifically, the method which I am activating Alt-G. Rarely do I need to go to the interface itself when using Alt-G, rather I want to one of the classes that implement the interface. (Although, I would still like the actual interface to be in the list too.)

Cheers,
Clint

feline
Whole Tomato Software

United Kingdom
19021 Posts

Posted - Aug 14 2006 :  6:18:21 PM  Show Profile  Reply with Quote
have you tried the latest beta build? there is a new feature "find references", which you may find helps if you run this on the interface type.

when you say interface are you talking about some specific keyword? or are you talking about a common (and probably abstract) base class? i believe interfaces exist as a specific type of class in C#.

however if this is simply a base class, then this could cause problems if you ever derive a class from a common framework class, since suddenly you may find yourself with hundreds of references on alt-g.

zen is the art of being at one with the two'ness
Go to Top of Page

clintsinger
New Member

8 Posts

Posted - Apr 21 2007 :  1:17:59 PM  Show Profile  Reply with Quote
What if the alt-g could trace back to where the class is being instansiated?

For example

class IFoo
{
public:
  virtual void MethodA() = 0;
}

class CFoo : public IFoo
{
public:
  virtual void MethodA();
}

class CAnotherFoo : public IFoo
{
public:
  virtual void MethodA();   
}
void SomeOtherClass::CreatingFoo()
{
  IFoo* pFoo = new CFoo();
  IFoo* pAnotherFoo = new CAnotherFoo();

  UsingFoo1(pFoo);
  UsingFoo2(pAnotherFoo);
}

void SomeOtherClass::UsingFoo1(IFoo* pFoo)
{
    pFoo->MethodA();
         ^- alt-g here would know that CFoo() is where I want to be and gives me it as the option in the popup list.
}

void SomeOtherClass::UsingFoo2(IFoo* pFoo)
{
    pFoo->MethodA();
         ^- alt-g here would know that CAnotherFoo() is where I want to be and gives me it as the option in the popup list.
}


So, VisualAssist would have to know where the variable was instansiated and that would take a bit of tracing back in the code.

But I would love this feature!

Edited by - clintsinger on Apr 21 2007 1:19:56 PM
Go to Top of Page

sl@sh
Tomato Guru

Switzerland
204 Posts

Posted - Apr 23 2007 :  03:47:32 AM  Show Profile  Reply with Quote
Not sure what you mean by tracing back, and why you think this would be unambiguous? For all I know, the methods SomeOtherClass::UsingFooX() might be called from within a library that is linked to your code, and that you don't even have the source code of. So you wouldn't know what pFoo is instantiated with.

Or even more likely - if you already use inheritance, it will be likely that either function is called by a pFoo that is instantiated by objects of different classes.

Anyway, I don't see how this would be relevant, since as long as you are using your interface class IFoo, it doesn't matter what class pFoo is instantiated with - so why would you want to know?

P.S.:
to be more to the point: you have one of two possible scenarios:
1. if you *know* your pFoo is going to be a pointer to CFoo, why do you call it an IFoo* on your method interface? You should make your pFoo a CFoo* then.
2. if you *don't know* what class your pFoo is actually instantiated with, then - before you could use any of the features of the actual class - you should first cast it to the appropriate class, after somehow testing what class it actually is. A much easier way however would be to just use virtual functions and implement whatever you want to do within your methods UsingFooX() right within your instantiated classes, not within IFoo!

Edited by - sl@sh on Apr 23 2007 04:06:54 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19021 Posts

Posted - Apr 23 2007 :  08:01:11 AM  Show Profile  Reply with Quote
In addition to sl@sh's very good points, what happens when pFoo points at CFoo for the first 3 lines of a function, and CAnotherFoo for the next 3 lines of the same function?

Ultimately the compiler always resolves what pFoo is pointing at, but since the whole point of this sort of code is that you can, and do, change the nature of the class at run time this becomes rather complicated for VA to try and pin down.

Here you know the name of the function, and if you use a consistent naming convention that it is a member of a class "*foo*", so why not use FSIW? You can filter it on "methoda foo", which will give you all items containing these two strings.

zen is the art of being at one with the two'ness
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000