Is there a way to search for methods / functions in Visual Studio by their signature? For example, if I wanted to find the methods (on one or more classes) that return 'string' and take an 'int' or other parameters.
If it isn't build into VS, is there an extension that anyone may know of? Should I just bite the bullet and write my own?
You can use VisualStudio's search with Regular Expressions:
(String|string) :w(.*(int|Int32).*)
Should find any method that returns a string and has an integer in the signature. Though the caveat is that the signature can only take up one line, and it's by no means bullet-proof to only find methods (anything that matches that pattern will ultimately be returned). But, with a little finesse you could come pretty close.
Related
I'm looking at a piece of very old VB6, and have come across usages such as
Form5!ProgressBar.Max = time_max
and
Form5!ProgressBar.Value = current_time
Perusing the answer to this question here and reading this page here, I deduce that these things mean the same as
Form5.ProgressBar.Max = time_max
Form5.ProgressBar.Value = current_time
but it isn't at all clear that this is the case. Can anyone confirm or deny this, and/or point me at an explanation in words of one syllable?
Yes, Form5!ProgressBar is almost exactly equivalent to Form5.ProgressBar
As far as I can remember there is one difference: the behaviour if the Form5 object does not have a ProgressBar member (i.e. the form does not have a control called ProgressBar). The dot-notation is checked at compile time but the exclamation-mark notation is checked at run time.
Form5.ProgressBar will not compile.
Form5!ProgressBar will compile but will give an error at runtime.
IMHO the dot notation is preferred in VB6, especially when accessing controls. The exclamation mark is only supported for backward-compatibility with very old versions of VB.
The default member of a Form is (indirectly) the Controls collection.
The bang (!) syntax is used for collection access in VB, and in many cases the compiler makes use of it to early bind things that otherwise would be accessed more slowly through late binding.
Far from deprecated, it is often preferable.
However in this case since the default member of Form objects is [_Default] As Object containing a reference to a Controls As Object instance, there is no particular advantage or disadvantage to this syntax over:
Form5("ProgressBar").Value
I agree that in this case however it is better to more directly access the control as a member of the Form as in:
Form5.ProgressBar.Value
Knowing the difference between these is a matter of actually knowing VB. It isn't simply syntactic though, the two "paths" do different things that get to the same result.
Hopefully this answer offers an explanation rather merely invoking voodoo.
Having used optional parameters in a few classes here and there, I'm starting to dislike them immensely for the trouble they cause in certain cases with overload resolution, i.e. difficulties in binding delegates to them due to signature conflicts, as well as dynamic invocation problems with regard to method argument count.
How can I search in all files in my Visual Studio IDE (2010) project and locate all optional parameter usage? Would there be a clever regex I could use perhaps? Or perhaps using an older version of Visual Studio where optional parameters are not supported? I'm trying to avoid the hassle of manually scanning files in the project as it can be tiresome and error-prone. Thanks!
Your best bet may be reflection - it should be easy enough to loop through all members of all types where they are methods and they have at least one optional parameter.
That wouldn't do the substitution for you, but could give you a list of all offending members.
Something like:
foreach (Type tp in currentAssembly.GetTypes())
foreach (MethodInfo func in tp.GetMethods())
if(func.GetParameters().Any(p=>p.IsOptional))
Console.WriteLine(func.ToString());
Whilst this isn't probably the best way I tend to look at the Class View in visual studio. The types that are shown in square brackets are the optional parameters
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.
Is it possible to search or filter intellisense in visual studio?
Basically i know there is an enum in the project that contains 'column', but the enum doesnt begin with 'c'.
There has been lots of times where id rather not scroll through the hundreds (if not thousands) of valid objects it gives me.
I wonder if the real answer here is (and I won't be surprised to be voted down for this) that your enum isn't properly named. If it was then I'd expect the name to be obvious in the use context, may be consider renaming the enum?
You can search in Class View. Type "column" and hit enter.
Visual Studio 2010 changes all of this, giving you multiple very easy ways to do this type of search quickly.
If you're using ReSharper, you can use "Go To Symbol..." and type "column", and it will give you all symbols (types, properties, fields, methods, etc) that match.
Otherwise your best bet is to use the Object Browser and search.
I really don't know about doing that in intellisense itself, but assuming the objective is to actually find a member whose name you don't remember, you can write a small utility for that purpose using the underlying mechanism intellisense uses, reflection.
Open the Object Browser under View menu. From there, you can search within all the language constructs available to you.
Are there any tools that augment/replace intellisense with a search of for expressions that will result in a given type?
I'm thinking of the case where I need to get some particular object and I known the type and will recognize the name but don't know what sequence of objects to jump thought to get to it. Such a tool would do a breadth first search of all options and list anything that has the correct type.
This is an old question, I know, but I'm giving it a shot in case you didn't find anything. Intellisense has the Resolve option (from at least Visual Studio 2005), with which you type your particular object straight, and then with right-clicking you can choose Resolve, which will add the library required to the list at the top of your class.
Similarly, ReSharper might have something fancier for you.