Common Editor Issues in VS 2010 Beta1

Thank you to everyone who has downloaded and tried VS 2010 Beta1 so far!  In the two weeks since Beta1 was released, you’ve sent us tons of feedback that has helped us fix some of the most commonly reported bugs.  This post details frequently-encountered bugs and their status, in no particular order:

Background Color of the Editor is always white

Status:  Patch available for download here
The Bug:  Setting a custom background color for the editor works once, but every new editor window opens with a white background.  This can be fixed by going to Tools->Options->Environment->Fonts and Colors and simply clicking OK, but it’s annoying to have to do that every time you open a new tab or restart VS.
The Solution:  This should be fixed for the next release of VS 2010.  For Beta1, there is an extension written by a member of the VS Editor team as a patch that will allow custom background colors to persist. You can find it in VS by going to Tools->Extension Manager and searching for the "BackgroundPatchExtension," or download it from a web browser here. Once you install it, just make sure it is enabled in the Extension Manager, and your background color should be applied correctly.

Outlining Highlight Color flickers or makes text unreadable on dark backgrounds

Status:  Fix in progress
The Bug:  The highlight color when you mouse over an outlining region is not currently configurable, and the default color makes text difficult to read on dark backgrounds.  Some users also notice that the highlight causes a flicker effect when moving the mouse from the editor to the toolbox, line number margin, breakpoint margin, or other margins on the left.
The Solution:  We plan to choose a better default color that should make the highlight better for dark backgrounds.  We also plan to make the highlight color configurable, so you can choose a custom color that works with your preferred color scheme.  This also gives the ability to avoid the flicker by setting the highlight color equal to your editor background color.  You should see these changes in the next release of VS 2010.

Some Fonts do not work, and Text in the Editor may appear blurry

Status:  Fix in progress
The Bug:  Some fonts, custom and available in Tools->Options, will display as Consolas instead of the desired font.  Text in the Editor, tooltips, or IntelliSense may also appear blurry to some users.
The Solution:  Because the new VS 2010 Editor is based on WPF, its font rendering has different advantages and limitations than the editor in previous versions.  WPF supports only TrueType vector-based fonts, so selecting a bitmap or non-TrueType font will cause the editor to revert to the default font, i.e. Consolas.  Some of the fonts in the Beta1 list in Tools->Options->Environment->Fonts and Colors are not TrueType fonts and will also not work, and we have now removed these fonts from the list for future versions of VS 2010.

We are also working with the WPF team to make significant improvements to the Editor's font rendering for the final version of VS 2010, which should reduce the blurriness of text in the Editor, tool windows, IntelliSense, and tooltips.  In the meantime, it may help to run the ClearType tuning tool to improve font clarity in the VS Editor and other applications.  You can also track the WPF team’s work on font rendering.

Mouse-Wheel Scrolling in the Editor is slow

Status:  Fixed
The Bug:  When using the mouse wheel, the editor scrolls very slowly or sometimes not at all.  Other applications scroll as expected.
The Solution:  The editor was not respecting system-wide settings for the mouse wheel as configured in the Control Panel.  This has been fixed and should work correctly in the next release of VS 2010.


Scrolling with a Laptop Touchpad does not work

Status:  Fix in progress by the WPF team
The Bug:  When you try to scroll the editor with a laptop’s touchpad, nothing happens.
The Solution:  None yet, but the WPF team is working on this issue.  You can track its status here.


Editor does not scroll horizontally when selecting text with Ctrl+Shift+arrow keys

Status:  Fixed
The Bug:  When using Ctrl+Shift+arrow to select text, arrowing off the screen does not cause the editor to scroll horizontally.  The caret goes off the screen, but you can’t see where it went.
The Solution:  This has been fixed and should work correctly in the next release of VS 2010.  The workaround for Beta1 is to use Shift+arrow instead of Ctrl+Shift+arrow or to select out-of-view text with the mouse.

Zoom:  Scrollbars should not zoom, and there is no way to quickly return to 100% zoom

Status:  Fix in progress
The Bug:  When using Ctrl+mouse wheel zooming, scrollbars also zoom and quickly become too large or small.  There is also no way to quickly return to 100% zoom.
The Solution:  We are planning significant improvements to the zoom feature that should fix both of these issues for the next release of VS 2010.  You can track these issues here and here.

Mouse Cursor becomes invisible

Status:  Fixed
The Bug:  When using Visual Studio, the mouse cursor sometimes becomes invisible, seemingly at random.
The Solution:  We discovered and fixed a bug in the Regular Expression Editor extension, available on the Visual Studio Gallery or through the Extension Manager in VS.  We believe that this bug is isolated to the RegEx Editor extension and is now fixed.  If you downloaded v1.0 of the RegEx Editor it and are seeing this problem, please uninstall and reinstall it or use the Updates section of the Extension Manager to download the fixed version.

First item in a Smart Tag is not selected by default

Status:  Fixed
The Bug:  Invoking a smart tag by clicking on it or pressing Ctrl+. brings up the tag, but the first item in the correction list is not selected by default.
The Solution:  This has been fixed and should work correctly in the next release of VS 2010.

Arrow keys do not move caret on wrapped lines

Status:  Fixed
The Bug:  When word wrap is enabled, pressing the up and down arrows may not move the caret.
The Solution:  This has been fixed and should work correctly in the next release of VS 2010.  For Beta1, the workaround is to disable word wrap or use the mouse to navigate away from a wrapped line.

Context Menu location is wrong

Status:  Fixed
The Bug:  Right-clicking in the editor causes the context menu to appear at the location of the blinking caret instead of the location of the mouse cursor.
The Solution:  This has been fixed and should work correctly in the next release of VS 2010.

If you’re seeing other issues, please post a comment, check the Beta1 Editor forum, or file a new bug and we’ll investigate.  Your feedback helps us find and fix bugs faster and improve Visual Studio, so keep it coming!

Brittany Behrens
Program Manager, VS Platform Team

Comments (8)

  1. Joku says:

    Or you could make it have some fade or timer so that it wouldn’t flicker if you are moving mouse over it… Isn’t the editor WPF? This kind of thing was supposed to be trivial.

  2. VSEditor says:

    Joku –

    That’s another possibility we’re considering.  It isn’t technically difficult, but there’s a usability tradeoff between:

    1.) The highlight responding immediately (as in Beta1) and causing some flicker when mousing over the outlining margin quickly to move the mouse somewhere else, e.g. the toolbox, and

    2.)  The highlight fading in or waiting for a short time and feeling slow or unresponsive when you hover over the outlining margin intentionally.

    While we don’t have a definitive answer yet, we’re working to find a solution that strikes the right balance.

    – Brittany

  3. adi hodos says:

    Are there any plans to support custom code styles for native code ? For example NetBeans CPP pack and Eclipse CDT allow many customizations ( spaces before parenthesis , after comma , identation of preprocessor directives , every function parameter on a new line to name only a few ). I would very much like to see options like those available in Visual Studio also.

  4. VSEditor says:

    adi hodos –

    Options for formatting code are provided by each language team, so some languages have a richer set of style choices than others.  For example, you’ll see a wide variety of customizations available under Tools->Options->Text Editor-> C#->Formatting, including several of the ones you mention and many more.

    Unfortunately, C/C++ does not offer as many choices for formatting native code.  I agree that this is an area that could be improved, but it falls outside of the Editor team’s control, and I don’t believe the C/C++ team is planning significant changes in formatting options for VS 2010.

    – Brittany

  5. adi hodos says:

    I’m sorry to hear that , because if you’re writing native code and you want to use a different formatting style sometimes it feels like the editor is working against you 🙂

  6. Pete says:

    I’ve had a constand editor problem where the screen takes forever to render.  I’ve been up and down the tree trying to find the answer.  

    Your post spoke of issues with fonts being incorreclty chosen or going back to the wrong ones. I kept noticing drive activity sometime 5 minutes or more.  

    The fix to my problem appears to be simple, I switched to Mariam Fixed from Consolas.  Now it runs like my quad core should run. I actually think that this could be from NOT VS 2005, 2008 or 2010 issue but more likely that my font catalog is quite large since I also run Photoshop.  I suspect that maybe a few of the FreeWare fonts are the culprits.  

    Whats in the Fonts Folder could be why the editor runs slow.  I am installing a font manager but my extremely slow rendering seems. There are days just going from code to HTML to splut could take 20 seconds.  For me this was adding up to hours.  

    Please load fonts in, fill that folder up and you might see the same results. A font Manager should solve this issues.

  7. A visual challenge that would help is as follows:

    Create Editor Feature: Allow for highlighting a region, setting a solid color similar to when you hold the mouse over the regions area.  Make it permanent so that when scrolling through lots of HTML or Code, you can quickly skip to or skip over backgrounds that colored code.  

    The main advantage is you dont have to read everything, this would a great features behind comments, then we create SOLID bars, backgrounds and regions.  You look for the colors not the code.  

    You would amazed on how much effort is spent reading code when drilling down.  Even some symbols, stars, that could be anchored on the left bar, similar to breakpoints but it should traverse from left to right or edge to edge.  

    Just like the box above this comment box would be so helpful and cut down on reading text.  

    Want a sample?  Let me know.  

Skip to main content