I have assigned the keyboard shortcut Ctrl+E to a command. But when I click Ctrl+E, the status bar says Ctrl+E was pressed. Waiting for the second key of the chord...".
If I hit the Esc key, I get "The key combination (Ctrl+E, Esc) is not a command."
How do I activate the command that has been assigned to Ctrl+E?
I know that this is the same as the question How do you stop Visual Studio from waiting for the second part of a shortcut-combination? . But the answer given there (hit Esc) does not work for me.
The selected answer is wrong in stating you cannot use Ctrl+E by itself (at least for Visual Studio 2013).
For those who come from a Mac or other OS background where Ctrl+E takes you to the end of the current line (the End key shortcut by default in VS), this is a really frustrating limitation when switching environments.
I found that in Visual Studio 2013 at least, you can remove all the shortcuts that use the Ctrl+E chord (none of which I will ever use) and set the Edit.LineEnd command to Ctrl+E. It just takes a few minutes tracking down the chords to remove (most of them are under the workspace designer).
To see which commands are using your keyboard shortcut at the moment, enter it
in the "Press shortcut keys:" edit box. Make sure you don't accidentally click "Assign".
In the dropdown box "Shortcut currently used by:" you can browse
through and manually remove all commands that
currently occupy your desired shortcut combination.
Key chords are a keyboard shortcut feature of Visual Studio. They consist of a sequence of key presses like (Ctrl+K, Ctrl+C) for comment code or (Ctrl+K, Ctrl+U) for uncomment code.
They are activated by the user pressing one Ctrl+key combination, then another Ctrl+key combo. For example Ctrl+K, Ctrl+C on my install of Visual Studio is used for commenting selected text.
In your case, Ctrl+E is a common chord starter and is used by many chords. For example Ctrl+E, Ctrl+W = Toggle Word Wrap and Ctrl+E, Ctrl+X = Workspace Designer.ExpandAll.
Depending on which developer setting you've chosen for the IDE, Visual Studio might have Ctrl+E mapped to other chords. In that situation, you cannot use Ctrl+E by itself for a keyboard shortcut
If this is the case, you can create your own chord, Ctrl+E, Ctrl+D is not in use on my install of Visual Studio 2012.
Edit:
Also if you remove all key chords that start with (Ctrl+E) then it can work as a non-chord shortcut.
And your question is not the same as the other question. In that question, the OP has started the chord process (Ctrl+E) and wants to cancel Visual Studio from waiting for the 2nd chord key.
I came to this question because I had the same problem as the OP, but in the Integrated Terminal of Visual Studio Code (not Visual Studio).
My problem:
I couldn't stop the node server by doing Ctrl+C, because my VS Code was waiting for the "second key of chord"...
I fixed it in the user settings, by unchecking the Allow Chords checkbox.
I answered the more suitable question for me here.
I have had the same issue with my "<" [backquote] key and wasn't able to find the right keybinding in the normal settings. Allow chords wouldn't do anything either.
This is for anyone, who isn't able to reasign the key in the default keybindings:
Find the User settings in your terminal.
Windows %APPDATA%\Code\User\
macOS $HOME/Library/Application Support/Code/User/
Linux $HOME/.config/Code/User/
Open the keybindings.json file
look for all chords that you would like gone.
(Obviously) remove/alter them
I hope I could help some of you!
You can disable it only for the integrated VSCode terminal by adding the following to your setttings.json file:
{
...
// Disable chords for terminal usage
"terminal.integrated.allowChords": false
...
}
Go to Tools -> Options.
A window will open up, In that Environment -> Keyboard -> Keyboard
And Just Press the Reset button on the right.
Screenshot
Do
ctrl+ E
then
ctrl + V
More info here:
Is there a way to prevent Visual studio to start the debugger when pressing F11? I often press it by mistake when I want to actually press F12.
I do not want to loose the functionality of Step-into which F11 provides but it is annoying when it starts the application.
This is for VS 2010, but it should be similar for others.
In Tools->Options, open Keyboard under Environment. Look up the command Debug.StepInfo. You can remove the default shortcut (F11 (Global)) and then just use the toolbar button to step into, or right click and "Step into specific"--which is what I do since it keeps the debugger from diving into STL functions if they're part of a line of code (as an example).
A hack-around that I use is to use the cancel build command after I accidentally hit F11. The default shortcut is ctrl+pause/break.
This doesn't stop F11 starting a build, but should stop it from running your program.
This is the suggestion on Microsoft's VS Community forum. Currently there is a suggestion from MSFT (I assume official MS dev?) that points to this free extension Tweaks:
Don't start debug on F10/F11 Inspired by the suggestion Please provide
a way to disable F10/F11 until debug mode is entered.
F10 (Step Over) and F11 (Step Into) are two commands people often hit
by accident. That starts a new debugging session and that can be
annoying if you didn't mean for that to happen. They should only take
effect during a debug session.
Install Resharper and Change the Key Short Settings
I don't know what key combination I did, but now each time I click somewhere in the page, Visual Studio selects the text between first and second mouse click.
I tried to escape from this "selection mode", but nothing helps, nor Escape, nor left clicks, nor Ctrl+Up/Down.
I opened another VS window and there is all right - normal selection.
What is it, how to cancel it, what is it for?
I should probably restart Visual Studio. I remember that that happened some times ago in VS 2005. Very annoying VS "feature".
P.S. It disappeared as suddenly as it appeared, but I found similar problem described here. The guy says that "The only way to stop is to press escape or shift and an arrow key."
I have very often the same issue, just after stopping the debugger. No idea how it starts... But I found the key combination to stop it: Press "Alt Gr"+"Ctrl(right)"+"Shift(right)"
I figured out how to turn this issue on and off:
Just press the ins (Insert) key; If you're using a full sized keyboard it will be to the right of backspace and above delete or if you're using a smaller keyboard it'll be the second option of zero key on the number pad to the right of the right arrow key.
Click on tools and then options. Under environment select keyboard. Then there will be a window open up with options. The first drop down says something about mapping. Set that to default.
Brief, if this was previously selected, is an old DOS format and the key bindings will cause similar actions.
I have experienced the same problem (VS 2010). Here is what happens:
I start the debugger on a project whith Unmanaged debugging enabled. When I try use the key combination Ctrl+Shift+L to delete a line I get a dialog saying 'Changes are not allowed when unmanaged debugging is enabled'. The title of the dialog is 'Edit and Continue'. When the dialog is closed the editor gets stuck with this behavior:
Shift+Right-Click behavior: It selects the text between the cursor and the position of the mouse-click
Ctrl+Scroll behavior: If I try to scroll using the mouse wheel it will zoom in or out instead.
It behaves like the Shift and Ctrl keys are being held down.
I have found these key combinations that will get me out of this situation:
Shift + Arrow down
Ctrl + Arrow down
Until I discovered this I had to restart Visual Studio.
Use the (insert) Key in the Key board.
I have this issue when I VPN to a machine running VS. Here is the key combination I have found to get me out of this state. I do a ctrl-f to open the find window. I type some characters in the find textbox and I notice that the letters are all capital (even though I did not set the caps lock). I hit the caps lock key and test using the find text box to make sure my caps lock is not set (lowercase). Once the lowercase is set, the selecting text between mouse clicks behavior goes away. Don't know why, but this works for me.
Somehow Visual Studio search has stopped working for me. Anytime I search "Entire Solution" for some text I get this result:
Find all "[Whatever I was searching for]", Subfolders, Find Results
1, "Entire Solution" No matching text found to look in. Find was
stopped in progress.
Why does it suddenly say "No files were found to look in"?
I've found a number of links on Google that say to press Ctrl + Break or Ctrl + Scroll Lock, but none of them seem to work for me.
I get that problem once in a while. One seemingly nonsensical solution I've found is to click inside the Find Results window (not the Output window). Once the blinking text cursor is visible, hit Ctrl+Break four or five times. This seems to "unblock" whatever causes the problem.
There are reports Ctrl + ScrLk may need to be used instead of Ctrl+Break . If these doesn't work then try Break alone.
Note from Codeguard: I have found an explanation and deterministic solution to this problem
Windows 7 Pro SP1 64-bit, Visual Studio 9.0.30729.1
Didn't Work:
Ctrl + Break
Ctrl + Scroll Lock
Restart of Visual Studio
Worked:
Break (in Find Result 1 & 2) (only pressed once)
Source: Comments in Gordon's link...
Bug source
This is neither Visual Studio nor Windows related bug. In fact, the bug is in your keyboard! Many keyboards from different vendors have been reported to be buggy.
Problem
If you press Ctrl+Break and release Ctrl first, then Break gets stuck on a buggy keyboard. If you ever pressed Ctrl+Break the "wrong" way, you will have this problem with search being interrupted.
Details
According to scan code specifications, Break and Ctrl+Break are special. They send "make" (press) AND "break" (release) scan codes the moment you press Break. They send nothing when you release Break. The buggy keyboard will send the following sequence:
Ctrl "make" scan code
Ctrl+Break "make" scan code
Ctrl "break" scan code
Pause "break" scan code
That is, Ctrl+Break is never released, but instead Pause is released.
Reproduction
You could for example use old good Spy++ from Visual Studio tools. Attach it to anything, for example Windows notepad, and monitor messages (I suggest that you select only keyboard messages). Press Ctrl+Break, releasing Ctrl first. Check the output from Spy++. You will see the sequence I shown in Details section.
I have tried two different keyboards on the same computer. Logitech K120 has the bug while some other Mitsumi keyboard behaves according to specifications and does not have the bug.
If you think about it, it's easy to understand that correct behavior needs special case handling, while buggy behavior is naive. This is why many different keyboards can be buggy.
Solution
Replace your keyboard :)
Workaround
You simply need to press Ctrl+Break, paying attention to releasing Break first. It doesn't matter which application is active.
This bug has been in Visual Studio a long time and it never seems to get fixed.
See this MS Connect item from 2004: http://connect.microsoft.com/VisualStudio/feedback/details/105511/find-in-files-says-no-files-were-found-to-look-in-find-was-stopped
I couldn't believe they still hadn't fixed it in VS2010 - but it's still there :(
The Connect item has been marked as Closed - Won't Fix: https://connect.microsoft.com/VisualStudio/feedback/details/718217/find-was-stopped-in-progress-while-performing-search-in-visual-studio
Ctrl+Break or Ctrl+ScrLk cancel a find operation. Try it. What has happened is that some software layer (presumably Windows) thinks those keys are still being pressed even though they are not. Pressing and releasing them clears the flag.
It could be any of these combinations:
Ctrl+Break
Alt+Break
Break
Ctrl+ScrLk
Remember that you have multiple control and alt keys on your keyboard -- try it with each of them. If it's the right Ctrl key + ScrLk, pressing the left Ctrl is not going to resolve the issue.
Here is the Connect issue which Microsoft closed as "Won't Fix".
If this is a recurring problem for you, there is a Visual Studio extension that suppresses the virtual key that causes the problem.
Ctrl + F and Ctrl + Shift + F have stopped working on Visual Studio 2015 Community Edition.
My friend told me going to:
Tools → Import and Export Settings:
Choose: Reset all settings → Next
Choose: No, just reset settings, overwriting my current settings → Next
Choose: General → Finish
In my case I had a bogus character in the "Look at these file types:" field in the search window.
Removing the character solved the problem.
Visual Studio 2017
Search solution in Visual Studio 2012 is broke. I tested this on three machines, did not work on two. What I found which does work is click on drop down arrow next to search field and select Find all. This is a bit of pain because you have to select drop down every time you search in solution.
I tried all the previous options. They didn't work for me, but reading them made me sure that this is a bug, and I will have to try some unknown ways to get it working. So, I tried a simple file search in Visual Studio 2010 in:
The current document
All the open documents
Both of which worked.
Then I tried Find in Files and woah! It started working.
Unfortunately none of these special key strokes work for me. Only restarting Visual Studio 2010 seems to work for me.
I had the same problem in Visual Studio 2013 (Update 3). None of the key combinations listed previously worked for me. I had *.cs selected in the FileTypes.
To get it working, I changed it to *.*, and then back again to *.cs - now it works.
I have been using Visual Studio 13 without this problem for couple of years now and I started having this issue after applying Update 5 or it could be a weird keys combo pressed by me unknowingly which triggered it, I don't know for sure.
Echelon_Force's solution worked for me. Thanks!
Didn't Work:
Ctrl + Break
Ctrl + Scroll Lock
Worked:
Break (in Find Result 1 & 2 window - Only pressed once)
Happy finding in files!
All of the combinations of Scroll Lock and Break didn't do anything for me. As a workaround, I added the solution directory to the Search Folders (the second ellipsis button), then changed the Look In field to the solution directory. The root problem still exists, but for me, this is functionally the same thing.
(Visual Studio 2013, Windows 8.1, x64)
I was using Visual Studio 2022 (tried with both professional and community, V 17.2.5), my search function was not working in Find in All Files, so I browsed to my solution folder, under .vs\{ProjectName} folder, there is another folder with name FileContentIndex. After closing visual studio and deleting this folder, and restarting vs, seemed to solve my problems, and my Find in All Files started functioning correctly.
I had the same problem as glenneroo today, after updating Visual Studio 2019 to 16.4.3. Found a solution that worked for me here.
Open Find Options and check if there is a (special) character in the Look at these file types text field. If so, remove it.
In Visual Studio 2013 after Update 3, I had the same problem. Before, I could just put ".cs" or ".cshtml" in the Look at these file types: and it would work. But after Update 3 I now have to put ".cs" or ".cshtml" (or whatever file types I want to search in) and it works fine.
This works for me after everything else didn't or worked only sometimes:
Do the search, and while searching, hold CRTL all the time and keep pressing Break.
If you are searching for multiple file types, they must be separated with a ; character, not a space.
This returns the correct results:
*.cs;*.vb;*.js;*.aspx
This returns nothing at all:
*.cs *.vb *.js *.aspx
This isn't the problem the original poster, but for other people who can't figure out why their search isn't working, this could be the reason.
Another late-to-the-party answer, but I found yet another "solution" for this problem.
When it looks as if the Visual Studio app has frozen on search...leave it alone. Don't close it. Don't restart it. Just let it go for about 10-15 minutes and the problem may correct itself, as it did in my specific case. I'm not sure as to why leaving it alone solved the problem, although my wholly uneducated guess is that Visual Studio is building some sort of an index to be able to search files and running into a snag. Once the 10-15 minutes are up and VS completes its search, it seems fine after that.
Probably won't apply to most situations, but what fixed it for me was turning off 'Use Regular Expressions' in the search window. I had previously been using Regular Expressions for some tricky replacements and didn't turn off when finished. I think perhaps it was interpreting part of simple replace text (see below - had some special characters) as the start of an incomplete or malformed regular expression, and so couldn't actually do any matching. Would be nice if it told you!
It only seems to lock-up if I use Ctrl + F (Find in Entire Solution) and never if I use Ctrl + Shift + F (Find in Files).
That Ctrl+Break trick worked for me for years, it's really interesting to finally understand why this happens. With VS2015 I have somewhat related problem with search: my Ctrl+Shift+F simply does not work, this key combination seems to be ignored when I press it. I tried to reinstall even VS 2015 and I still got that same broken behavior.
In case somebody has identical problem, here's what was the reason:
I turns out that for whatever random reason VS2015 shows that "find in files" dialog on another monitor that's attached to my PC. That other monitor is 4K Samsung TV that normally stays "Off" and I have no clue why VS 2015 sends that search dialog box to that monitor. Surprisingly, when I turn on my TV the search dialog moves to the primary monitor on its own!
Ctrl + Break works for Visual Studio 2008
Nothing worked for me. I use also Resharper. So I had to reset my VS key bindings and reapply Resharper shortcuts. Only this got me it working.
Reset current keyboard configuration (Tools | Options | Environment | Keyboard | Reset).
Go to ReSharper | Options | Environment | Keyboard & Menus | "Visual Studio" | Apply Scheme.
I am running Visual Studio 2012 Professional in a Virtual Machine, connecting using rdesktop from a Linux machine.
None of the other suggestions worked, but solved the problem was:
Go to the 'Find and Replace' screen. (ctrl-shift-f in my case)
Enter a search text and choose 'Entire Solution'
Hit 'Find Next', it should find a result.
Hit 'Find All', now works without aborting. (Note, i hit my Mouse really hard and some swearing was involved, too, but I don't think that has any relevance apart from a psychological one :D )
Tried all the solution, but the fixed of mine was I accidently change to another language keyboard on my windows, after I change back to English keyboard, it work, finally I can ctrl + shirt + f
I'm currently using VS2019 16.7.7, and, if I try to find something in the whole solution, VS never finds all the occurrences, sometimes only one, or none.
In some recent release of VS2019 (perhaps 16.5 or 16.6) the old "Find and replace" dialog was replaced by a new "Find in files" dialog, and this new one is failing for me. One solution that worked for me was to disable the new "Find in files" and keep using the old "Find and replace" dialog by checking Use previous Find In Files in Tools > Options > Environment > Preview features.
However, I observed that this was only failing in one of my open Visual Studio instances, so I tried the simple "close VS and open it again", enabled the new "Find in files" functionality, and it started working.
Two possible solutions, in case the simple "close and open again" fails.
The following worked for me. Visual Studio → menu Windows → Reset Window Panel. The resizing of Visual Studio made it to hide the option.
This was one of my biggest problems with Visual Studio. For me (Windows 10, Visual Studio 2015) the find in all files window got locked with a white-out, and guess what, hitting print screen solves it.
This has begun occurring for me with the update to Version 15.8.8 of Visual Studio. None of the above steps worked. There is no error. Just what appears to be a 'stuck' search.
I had recently installed ApexSQL Refactor 2018.03.0331. Uninstalling this did not resolve the issue and does not seems to be the cause. It seems to be related to Version 15.8.8 of Visual Studio update.
I completely uninstalled Visual Studio and reinstalled Version 15.8.8 again. The issue with Ctrl-Shift-F searching the Entire Solution is no longer an issue. Whatever caused the problem does resolve after uninstalling and installing.
I once again installed ApexSQL Refactor 2018.03.0331 and everything still works well.