A while ago I was watching a video where the presenter cleaned up his code by highlighting already written code, and choosing some option that converted the code into a method. It also automatically recognized what parameters needed to be passed, and all he needed to do was name the method.
Does anyone know what this option is called? I have looked all over and cannot find it. I can't remember the video either.
It was probably refactoring. Highlight your code, right click and select "Quick Actions and Refactorings", then select "Extract Method". (Or choose Edit Menu > Refactor > Extract Method.)
You'll be able to change the name of the new method. Visual Studio does its best to figure out what types are needed as parameters, what should be returned, what visibility for the method is needed, etc. You'll still want to double check the result and make sure it does what you want.
Yes, it's called refactoring your code. You can extract a method by right clicking on the highlighted method and choosing Extract Method from context menu. VS will extract the method and set the parameters for you.
Related
I am doing reverse engineering of code that someone else wrote. When I search for all references of a variable or method and click on one of the results it beams my cursor right away on the line of code where it is used (which is a brilliant feature). Visual Studio shows me the class where this variable or method is used but not the method. The problem is that sometimes I end up in a huge method deep within, and the only thing I really need is the name of this cursed method.
Question: Is there a simple way to jump to the signature of the method in which the cursor is situated? Or any other way to find it out? (Besides scrolling dozens of pages of code upwards and likely missing it)
In Visual Studio 2015 on the top right of the code editing window there's a drop-down list that contains all the method in the current file:
When you move from one method to another inside a file, the selected item in this drop-down list is updated accordingly.
Therefore if you put the cursor in the middle of a method the drop-down list should automatically change the selected item matching the method you're in.
Now if you open the drop-down list and select the current method it should take you to the method's signature.
Following the advice by Andrea I did a little research. Combined with this answer the outcome is this shortcut series:
Press Cntrl + F2 this will shift the focus to the dropdown menues above the code.
press 2 times Tab which will navigate to the dropdown menue for class elements as #Andrea suggested,
and hit ENTER to confirm the selection, which will automatically jump with the cursor to the signature of the method!
Does Xcode have a way to show the caller function of a method? I want to know all of the calling functions of a method in a class. A solution would be to find the method in the project, but sometimes different classes have methods with the same name - That could find us a method we're not looking for..
Many other IDEs have this capability, such as Visual C++ 2003/2005/2008,Eclipse ...
Can you do this in XCode?
Xcode 4.4 intrudced this functionality:
New Features in Xcode 4.4 (Scroll down to 'Find and Search Additions')
Move your cursor on top of the function you are interested in
Open the Assistant editor(⌃ +⌘+Enter)
On the top of the assistant editor, Select 'Callers'
You will see a list of all the function that's calling your function
Not the as effective as other IDEs, but does the job.
Yes. Set a breakpoint inside your method, then when it breaks, there are two spots to see a stack. First is in Xcode's "console" area (usually the bottom middle), there is a top-bar which may not immediately appear to be navigable, but it is a select-style UI control which has the entire stack in it. Selecting a different level shows you that scope's variables, etc. and pops your editor to that exact file (where you can mouse-over variables to see their in-memory real-time values). Second is in the left-hand area (where you normally browse files). There is another tab there (besides the file browser) for exactly this purpose. There is a slider at the bottom which controls how many "steps" in the stack you see; clicking on one has a similar affect.
For simple refactoring such as method re-naming, you can use the contextual-menu when you right-click a selected method-name, and Xcode will replace all identical selectors in your project. However, this does not address what you mentioned about different classes having methods with the same signature. It does, however, give you a very nice interface for reviewing the changes in-context and easily accepting or rejecting them one at a time.
It might be noted, however, that changing method signatures often may be a sign of poor design, and particularly if you have to do it with methods which have the same signature on different classes (which are not "siblings" and therefore should both get the rename)
I'm implementing a Visual Studio Language Service for a custom scripting language used internally at my company, and I've run into an issue with the navigation bar implemented as a subclass of TypeAndMemberDropdownBars. The subclass is created by my LanguageService subclass' LanguageService.CreateDropDownHelper method.
In the OnSynchronizeDropdowns method I'm iterating through the types defined in the file and adding DropDownMembers to the passed-in array to fill out the navigation bar. The issue I'm seeing is that the first item in the array is being duplicated and placed at the end of the listing by code that I don't have access to. This extra item does not behave correctly when selected (nothing happens), but doesn't seem to cause any other issues; the rest of the items in the list work fine. Additionally, this only seems to happen for the type dropdown box - the members dropdown box does not display this behavior.
I'm hoping someone else has seen and resolved this issue and could provide some assistance. Thanks!
Turns out this was caused by me calling LanguageService.SynchronizeDropdowns from my LanguageService.ParseSource method, which was being called on a background thread. I've fixed the problem by setting a flag when ParseSource does a Check parse, and then implementing a check for that flag in my LanguageService.OnIdle function that will call SynchronizeDropdowns. It's now working as expected!
A better solution is to implement the LanguageService.OnParseComplete callback, and call SynchronizeDropdowns from there. OnParseComplete is always called from the main thread, so this prevents any synchronization issues from coming up, and also keeps you from having to keep track of whether or not you need to call SynchronizeDropdowns().
We have lot of code like:
IPerson
{
Eat();
}
Persion : IPerson
{
}
IPerson p;
p.Eat();
As most of our interfaces only have 1 or 2 classes that implement them, there should be a way for me to right click on the “p.Eat()” and be taken to the code the in person class. When there is more than one implementer, I wish to be shown a list to choose from.
There is a new feature in Visual Studio 2010, called View Call Hierarchy (Ctrl+K, Ctrl+T).
Right-click on a symbol in code (method name or properties are good) and select View Call Hierarchy, and you will get a new window with various options. On interface members, you will see an 'Implements [member]' option, dropping this down will show you all instances where the interface member has been implemented.
Similar options appear for virtual / abstract members, showing you where they are overridden or implemented.
As an extra bonus, this window also shows 'Calls To [member]' and 'Calls From [member]'.
Resharper is an extremely valuable refactoring tool which provides the behaviour you describe.
I currently right click on the method name in the interface file and select the option 'Go To Implementation'.
I'm assuming this is a Resharper feature and not just Visual Studio 2010 purely because you aren't aware of it. Try right-clicking and seeing if you have the option. If not - I highly recommend getting a refactoring tool with this kind of functionality.
Edit | Find and Replace | Find Symbol will find definitions and references.
Right click on p.Eat() and choose "Find all references". In the Find Symbol Results windows, you may find all of the implementations of that interface method. Double-clicking each item will show up the reference in code editor.
I would like to find a way to see what happens while my XAML is being loaded. What classes are being instantiated, and in what order? Which properties are being set, to what values, and in what order? Which methods are being called (e.g. BeginInit, EndInit, etc.), in what order, and with what parameters? That sort of thing.
(If anyone's curious as to why, it's because the XAML loader is doing something magic that I can't duplicate in code, and I'm trying to figure out what it is.)
My first idea: Configure VS to debug into the .NET source code, and single-step through the XAML-loading code to see what happens. Unfortunately, source stepping has been busted for months, and there's no sign of that changing.
My second idea: Make my own classes that descend from WPF classes, override OnPropertyChanged, and do a Debug.WriteLine. Unfortunately, one of the classes I want to know about (BitmapImage) is sealed, so I can't descend from it.
Anyone have other ideas on how I could get some visibility into what the XAML loader is doing? Are there any tools (profiler, maybe?) that could give me a call graph? Is there a way to turn on some kind of logging in the XAML loader? Thoughts / suggestions?
Edit: The article Steve linked to does have the answer, though their sample code makes every event get displayed twice. For reference, here's how to make this work in code (no app.config changes required). Add these lines before the InitializeComponent() call (or type both lines into the Immediate window in the debugger):
PresentationTraceSources.Refresh();
PresentationTraceSources.MarkupSource.Switch.Level = SourceLevels.All;
This will cause detailed output to show up in VS's Output window, including the properties that get set magically behind the scenes.
You can trace a lot of the binding and loading with system.diagnostics. I've found a number of problems using this namespace. Its unwieldy like everything else in WPF, but it works. You can see what's getting set and where.