I'm using a shortcut to remind me to use two equal signs to check for equality. heres my AHK code:
::if::
Send, if
MsgBox Use two equal signs to check for equality!
Return
When I type 'if' it will bring up the box and keep the if the first time, after that it eats up the 'if' and doesn't print it. The code works fine for any other application but I can't get it to work in Visual Studio 2013. Also, it seems to work as expected when I try it in a comment. Any help would be appreciated!
Attaching the option B0 to a hotstring prevents it from removing the previously typed phrase, so you don't have to re-send if again:
:B0:if::
MsgBox Use two equal signs to check for equality!
Return
I know you already have your answer, but I personally would hate a MsgBox every time I typed "if". You may want to look into using context sensitive hotkeys. Furthermore, instead of a MsgBox, you could use a less invasive ToolTip. This way, you could keep typing but still get notified.
CoordMode, Caret, Window
:B0:if::
ToolTip, Use two equal signs to check for equality!, % A_CaretX, % A_CaretY+20
Sleep, 3000
ToolTip
return
Related
All right, this is stupid, but I have no clue how people deal with this and I'm hoping I'm missing something...
When I write something like this:
if (n == 0)
...The closing parenthesis gets added as soon as I type the opening one. The only way I know of to get out of them now is to reach over and tap the End key or something, which kind of ... Damages my shui, you know? And yet apparently they thought this feature was a cool idea, so...
What do you normally do to tell the IDE that you're done with this bit and you're ready to move on to the next? Same question applies to automatic quotes and stuff in the XAML editor, I guess.
Just keep typing - if you type your own ) when the cursor is just before the automatic one, it should not create another ), but just move the cursor over it.
(Disclaimer: I'm not certain this works on a vanilla Visual Studio - I have a bunch of extensions installed)
You can press Ctrl + Shift + Enter to open a new line below the current one without moving the cursor to the end of the line.
To add to this, Tab is another option and I find it easier:
In your example, type the logic, press Tab to skip passed the end bracket.
If you are inside auto quotes, type your text, then press Tab twice.
Like the other answer, it only applies when first being typed, so if you go back to edit something, you are left using the End and Arrow keys.
In Visual Studio 2015 with Productivity Power Tools installed (probably works earlier as well), when being inside an auto-complete block (quotes or braces):
end goes to line end ( typically slow to type/find)
"/) typing same key as auto-complete already inserted will simply replace the auto-inserted character
tab jumps over end of auto-complete (e. g. braces or quotes)
shift+enter adds ; at end of line, goes to new line (often what you want)
ctrl+shift+enter goes to new line
There is a short key in VS - "Edit.LineEnd" - pressing "End" you get to the end of the current line. I've re-assigned it (for me the best variant was "Alt-Enter") and use it to get outside of parentheses and quotes.
Hit the enter key when you are done typing.
I know about basic features of visual studio debugging. F10, F11, Shift+F11, Ctrl+F10.
If I am inside a for loop is there a way of stopping right after the loop is completed?
Right now the way I am doing it is to manually go to the location after the loop and press Ctrl+F10. Is there a better way of doing this?
There is no dedicated "Step Out of Loop" command in Visual Studio. "Step Out" (Shift+F11) works only for functions. There are only two options that I can think of:
Like Brian suggests, there is Run to Cursor, which has been there at least since VC++ 6. This is what you're already getting with the Ctrl+F10 keyboard shortcut. I use this literally all the time while debugging; it's an extremely useful tool. I don't really understand why you think this is a lousy way of doing it, or why you think there should be a "better" way.
You could set a simple breakpoint on the line of code immediately following the loop. This is relatively simple if you use the keyboard shortcut F9. But you still have to navigate to the appropriate line of code, so you might as well use Run to Cursor.
If you're working in a C-derived language, your loops probably conclude with a }. So you could use the Ctrl+] keyboard shortcut to move to the matching brace in the source file if your caret is at the loop's opening brace. That might make navigation easier. It certainly can help avoid moving your hands over to the mouse, killing precious seconds.
* Note that keyboard combinations are subject to change, depending on how you have configured your Visual Studio environment.
I just found out that if you hover with your cursor at beginning of the desired line, VS automatically blends in a little play symbol. When you click on it, debugger jumps to this point.
Perhaps you would like to use a breakpoint, which can be used to trigger the debugger once your program has reached a specific line. You can set one by clicking on the left side of the code line, where errors and arrows usually show up during debugging. Hope this helps!
Simple way is to put a break statement in the for loop and add a condition. This will allow you to test the loop while debugging.
I am writing a Visual Studio extension which provides intelliSense for a certain content type.
The problem that I am facing now is the effect of "Auto Indent" that Visual Studio provides on empty lines when user types a character.
Here a completion session started on an empty line (over virtual spaces):
Notice the tab symbols on the other lines and no tab on the line with caret on it.
Now when use starts typing, VS automatically and correctly adds necessary tab characters to the line:
Now the problem is those Added tabs apparently become part of the user input and as a result CurrentSession.SelectedCompletionSet.SelectBestMatch() or Filter() method cannot find the current item which starts with "C" here (thinking user has typed \t\tC instead).
If I start the session on anywhere else which does not require auto indent everything works fine.
Any idea?
Edit (more information): I used a code flow very similar to:
Ook here
vsLua here
vsClojure here
In Lua and Clojure you wouldn't face this problem because they never provide intelliSense on virtual spaces (meaning they always start after a certain set of characters) and if you start after a character virtual spaces are already turned into real spaces.
Ook on the other had has the same problem.
Revised Answer:
Ah, I see. I interpreted your question thinking that you were referring to completion triggering via typing, not from the explicit command. If you enable "show whitespace" for the C# editor, you can see what we do here: when you trigger the "show completion" command, we explicitly realize the whitespace so you're no longer floating around in virtual space. You should probably do this as well. (Alternatively, you could detect the scenario and fix it up on the first typing by adjusting your ApplicableTo span, but that's probably not worth the trouble.)
You can get the whitespace that should be inserted from IEditorOperations. So MEF import an IEditorOperationsFactoryService, and then do:
var editorOperations = editorOperationsFactoryService.GetEditorOperations(textView);
var whitespace = editorOperations.GetWhitespaceForVirtualSpace(textView.Caret.Position.VirtualBufferPosition);
if (whitespace.Length != 0)
{
textView.TextBuffer.Insert(textView.Caret.Position.BufferPosition, whitespace);
}
(Funny aside: as I answered this, I was curious to see how we handled this in the Roslyn C# and VB editors. The answer was "not", but filtering still worked by pure luck later in the code.)
Original Answer:
I suspect by your description of the problem that you are implementing your completion like this: you know a character is about to be typed (either via a keyboard filter or IOleCommandTarget) and you trigger an ICompletionSession, where the tracking span is an empty span on the current caret position.
The best approach to fixing this is to not trigger the session before the key is pressed and goes into the editor, but rather after it. This is what we do in the Roslyn implementation for C# and VB completion. Then, when you are in your AugmentCompletionSession call and creating your CompletionSet, compute the "applicable to" span which consists of the non-whitespace characters around your caret. The easiest way to compute this might just be to call GetWordExtent from the text structure navigator.
This allows for other scenarios to work right. Consider scenarios where the user types C, presses escape, and then continues to type your identifier. If you want to trigger completion again, you'd have to do the math to ensure that the "C" is counted as part of your span anyways.
In Visual Studio 2008 I would regularly record a macro to (for example) take a list of class member declarations and turn it into a list of property definitions.
Using Visual Studio 2010, the macro recorder appears to ignore a 2nd press of the Home key (the 1st should take you to the start of the text on the line, the 2nd should take you to the character position 1 on the line).
Putting the cursor at the end of a tabbed line, starting to record and pressing "Home" twice results in the following (it doesn't matter whether the tabs are actual tabs or spaces)...
Sub TemporaryMacro()
DTE.ActiveDocument.Selection.StartOfLine(VsStartOfLineOptions.VsStartOfLineOptionsFirstText)
End Sub
When what it should really put is...
Sub TemporaryMacro()
DTE.ActiveDocument.Selection.StartOfLine(VsStartOfLineOptions.VsStartOfLineOptionsFirstText)
DTE.ActiveDocument.Selection.StartOfLine(VsStartOfLineOptions.VsStartOfLineOptionsFirstColumn)
End Sub
I know I could just go in and edit it, but as I normally record something and then immediately run it multiple times, that is not appealing. And I'm not aware of any keypress that will take you to the first column.
Can anybody confirm if this is a fault with the macro recorder in VS2010, or am I doing something really stupid?
This does not work for me, either, meaning it does the same thing for me as it does for you, and the macro does not play back correctly.
As a workaround, I use the key combo [end, right, up] to go to the first character position when recording a macro. This translates into:
DTE.ActiveDocument.Selection.EndOfLine()
DTE.ActiveDocument.Selection.CharRight()
DTE.ActiveDocument.Selection.LineUp()
The only time this doesn't work is when you operate on the last line of the file. If you anticipate that happening you could use [up, end, right] instead:
DTE.ActiveDocument.Selection.LineUp()
DTE.ActiveDocument.Selection.EndOfLine()
DTE.ActiveDocument.Selection.CharRight()
Of course, this version would not operate correctly on the first line of the file.
Is there and easy way to remove the IF/End If structured pairing.
Being able to do this in one keystroke would be nice (I also use Refactor! Pro)
Right now this is what I do:
Delete the IF line
Watch Visual Studio reformat the code to line up correctly taking into account that the IF is Missing.
Navigate to the End If
Delete the End If line
i.e. In the following example I want to change the code from
IF Value = True Then
DoSomething()
DoSomething2()
End IF
To
DoSomething()
DoSomething2()
While this is not a literal refactoring in the sense specified by Martin Fowler's book Refactoring, This is how I use resharper to achieve this goal:
Move/click on like with if statement
Press control + delete to delete the line
Press Alt + enter, and the option remove braces will be the first one specified.
Press enter
Done. Not quite simple, but the keystrokes are short, and not too complicated, and I don't have to spend/waste time with dumb arrow keys or the mouse to accomplish this type of code change.
Resharper supports VB.net code as of 4.0, I believe.