On my development machine, I have an external monitor physically set up in vertical / portrait orientation, instead of the “default” horizontal / landscape orientation. My IDE (code editor) window always resides on that monitor. Instead of writing 1000 words to explain why this works great, I’ll let a pair of pictures do most of the explaining for me. Here’s a Visual Studio window (with the code for my open-source “Schneider’s Eleven” minimalist skin for Windows Media Player) open on my horizontal-orientation monitor at 1920x1080 resolution: 
Look at all that wasted whitespace on the right half of the main code pane! (This code was admittedly developed using fairly short line lengths, but the same wasted space effect probably still applies to at least some extent in the majority of projects out there.) Now, here’s the exact same Visual Studio window moved over to my vertical-orientation 1200x1920 monitor: 
Much less wasted whitespace! And almost 100 lines of code are visible on the screen at the same time, making it much easier to visually scan a large chunk of source code without having to scroll around. Having developed code this way in both Windows and Mac OS environments, I’d never go back! Rotating a particular monitor 90 degrees is an easy configuration change in the OS display properties (in Windows, Mac OS, and evidently in Linux as well), so if your physical display stand supports it, I’d encourage giving it a try and seeing how it works for you!
Having used Visual Studio 2013 and 2015 as my primary coding IDE for the past 18 months or so, I haven’t been terribly happy with Visual Studio’s out-of-the-box support for the task of using the keyboard to open a file with a particular name (in a large solution). As detailed in this StackOverflow question, there are a few options, none of which work well for me: Ctrl+[comma], filename, Enter –This is frequently very sluggish on my (modern) PC, with a delay of 5-10 seconds between the search field appearing, and Visual Studio recovering from being unresponsive and actually allowing typing in the field. Worse, occasionally after typing the Ctrl+[comma] hotkey, the search term that I started typing while the application was still unresponsive (but after the search field appeared), the text I entered gets inserted into the active source code document instead of in the search field! Ctrl+[semicolon], filename, Enter, Enter – Aside from the drawback of having to hit Enter twice, this leaves the Solution Explorer window in a state of showing only the matches for the entered search term. To clear the search, either using the mouse or hitting Ctrl+[semicolon], Esc, Esc is needed – obviously not ideal. Ctrl+Alt+a, of, filename – The Ctrl+Alt+a keyboard shortcut to open the Command Window doesn’t work in my Visual Studio, for whatever reason, even though that shortcut is listed in the Edit menu. Additionally, the autocomplete in the Command Window frequently messes up my search term. For example, if I’m trying to search for a file named “property.aspx” in my solution, but my solution also has a file named “property-format.aspx”, as soon as I type “property.”, the autocomplete for some reason assumes I want “property-format” and replaces my typed search term with that. So, no good. Since none of the out-of-the-box solutions work for me, I resorted to trying a Visual Studio extension that provides this functionality, VSFileNav. 
VSFileNav is a Visual Studio extension that binds a customizable hotkey – I’m using Ctrl+[tilde] – to open a custom File Navigation dialog allowing quick search and open of all files in the current solution. Some reasons that VSFileNav is awesome enough that I felt compelled to blog about it: - It’s lightning fast. Opening the File Navigation dialog, typing in the dialog to filter filenames in the solution, seeing search results update in real-time as the search term is being typed, and jumping to the selected file upon a press of the Enter key all happen effectively instantly.
- It supports Pascal-case filename search. Typing “MCC” into the search field matches “MyCustomClass.cs” as a search result, for example.
- It just works. I didn’t have to fight with any bugs or configuration settings (beyond setting my preferred hotkey) to make the extension work; I just installed, and it worked great immediately.
VSFileNav, or something like it, really ought to be out-of-the-box functionality in Visual Studio. But since it isn’t, if you’re a developer using Visual Studio, do yourself a favor and start using VSFileNav.
In the Visual Studio 2005 Watch window (where values of variables or expressions can be monitored during a debugging session), while editing a value in the Name field (where the variable/expression to be monitored is defined), support for the Ctrl+LeftArrow and Ctrl+RightArrow keyboard shortcuts isn't implemented properly.
In text-editing applications, the keyboard shortcuts Ctrl+RightArrow and Ctrl+LeftArrow commonly have the functionality of moving the caret (insertion point) to the beginning of the current word or the end of the next word. In the VS 2005 main code window, there is very good support for these keyboard shortcuts: in an identifier with several parts separated by period characters (such as System.Drawing.Rectangle.Empty), the insertion point is moved to before and after each period character on successive uses of the shortcut, making it easy to quickly navigate to either the beginning or the end of each component of the identifier. The insertion point also stops at other common code "punctuation", such as the [ and ] characters.
However, while editing a value in the Watch window, the Ctrl+LeftArrow and Ctrl+RightArrow shortcut behaviors follow a different set of rules. When these shortcuts are used in the Watch window, the insertion point bypasses most common code punctuation characters, and instead stops only at space characters. (A bit of additional testing I did shows that certain punctuation characters such as ? and ! are also treated as stopping points in the Watch window.)
Interestingly, this behavior appears to be a regression from Visual Studio 2003; in VS 2003, a quick test shows that when doing a Ctrl+LeftArrow / Ctrl+RightArrow in the Watch window, the caret does indeed treat a "." character as a stopping point. Possibly this is a result of a rewrite of the Watch window to implement one of the very nice new features introduced in VS 2005: Intellisense being enabled and usable when editing a value in the Watch window.
While working on a simple Windows Forms control to determine how Windows XP styles are supported in Windows Forms 2.0 controls hosted in Internet Explorer -- more on that later -- I found that Internet Explorer 6 doesn't respect public properties of hosted/embedded controls that define a "set" but not a "get".
I had a property like this in my test control:
public bool UseRedBackgroundColor
{
set
{
if (value == true)
{
this.BackColor = Color.Red;
}
}
}
I had a param set in the object tag in my test HTML page to set the property to true, but the control didn't render with the red background:
<object id="XPTest" name="XPTest"
classid="http:/webtest/XPStylesTest.dll
#XPStylesTest.XPStylesTest"
width="158"
height="250">
<param name="UseRedBackgroundColor" value="True" />
</object>
I changed my public property to have a "get" section, and after a rebuild of the project and a reopen of IE, the control rendered with a red background as expected:
public bool UseRedBackgroundColor
{
get
{
return (this.BackColor == Color.Red);
}
set
{
if (value == true)
{
this.BackColor = Color.Red;
}
}
}
So if a public property of a Windows Forms control hosted in IE isn't being activated as expected, check to make sure that a "get" section has been defined for the property.
A mandate was recently handed down in my development organization at work that all .dll files included in a hotfix should be set with a distinct value in their File Version field, so that the file can easily be identified as a hotfix file when examined (on a customer server machine) in the future.
While preparing a hotfix this afternoon, I decided to take this a step further, and set the defect number as the 4th item in the version tuple (leaving the first three tuple values as the version of the product being hotfixed), instead of just selecting and choosing an arbitrary value for the 4th value.
The defect number in this case was 96375. In Visual C++ 6, in the project with the COM component I was building, I set the FILEVERSION value in the VS_VERSION_INFO section of the project's generated .rc file to 96375.
However, when I built the .dll and looked at the File Version value, it was set to 30839. I guessed that the value I used might have exceeded the maximum allowed value and either been set to a constant max value of 30839 (although that number didn't immediately have any meaning to me), or else "wrapped" after hitting the maximum value.
A Google search didn't reveal any information about a maximum value for FILEVERSION, so I did some brief experimentation. It didn't take long to determine that the field is apparently a 16-bit integer, with a maximum value of 65535. Assigned values of 65536 or greater just "wrap" back around to 0. So a value of 65537 yields 1, a value of 65538 yields 2... and my value of 96375 yielded the value of 96375 - 65536 = 30839.
I settled for assigning a value of 9999 to the 4th item in the FILEVERSION tuple, figuring that would be a suitable "red flag" for anyone inspecting the version number later. I also appended the text "HOTFIX 96375" to the FileDescription field's value, so that the defect number would still appear on the .dll file's Properties dialog.
While working in Visual Studio 2005, I noticed a cool Autoformat-like behavior provided by the IDE.
I was working in a class that had a private class constant declared that I wanted to change to have public instead of private visibility. The original code looked something like:
private const int MaxItems = 5;
I used the ctrl+rightArrow keyboard shortcut to select a nearby instance of the keyword public, and then hit ctrl+c (Clipboard Copy), so I ended up with "public " (including the trailing space) on the clipboard.
I then double-clicked the instance of the "private" keyword that I wanted to replace to select it, and pressed ctrl+v to do the paste.
After the paste, the result was:
public const int MaxItems = 5;
This struck me as odd for some reason. After thinking about it briefly, I realized that I should have been left with an extra space after "public", due to the trailing space that was present on the clipboard:
public const int MaxItems = 5;
However, Visual Studio recognized what I was doing, and automatically removed the extra space for me, saving me a press of the Delete key after the paste. I tried pressing ctrl+z (Undo), and Visual Studio restored the removed space; a second ctrl+z press rolled back the Paste operation.
A very minor feature, but also indicative of the great attention to detail that Microsoft has put into the Visual Studio IDE. Pretty nice!
At the office recently, I was asked to whip up a simple Windows Forms UserControl with a public method and run it embedded in an HTML page in Internet Explorer. "No problem," or so I thought at the time -- I had created similar simple controls in the past, and one of the components that I have primary responsibility for at work is an Excel-like Windows Forms spreadsheet control that is deployed embedded in web pages and run in Internet Explorer. (More information on running Windows Forms controls in IE in this manner is available at GotDotNet .)
I had the control up and running in a web page in just a couple of minutes:
- I opened Visual Studio 2005 and created a new C# Class Library project.
- Added a new User Control to the project, "SimpleUserControl".
- To ensure that the control would stand out on the web page, changed the background color property of the control to Blue, and added a label to the control with the text "SimpleUserControl".
- Added a simple public method to the control:
public string WhatTimeIsIt()
{
return DateTime.Now.ToString();
}
- Compiled the project, and copied the generated SimpleUserControl.dll to a folder under my IIS root directory.
- Quickly typed up a simple HTML page in the same folder to show the control and demonstrate a call to the public method:
<html>
<body>
<object id="SimpleUserControl"
classid="http:SimpleUserControl.dll
#SimpleUserControl.SimpleUserControl"
height="150" width="150" VIEWASTEXT>
</object>
<input type="button" value="What time is it?" onclick="DoWhatTimeIsIt();" />
</body>
<script language="javascript">
function DoWhatTimeIsIt()
{
alert(document.SimpleUserControl.WhatTimeIsIt());
}
</script>
</html>
I brought up the web page in IE and the SimpleUserControl displayed correctly, as expected. Unfortunately, clicking the button on the page, instead of returning a string with the current date and time, generated a Javascript error: "Object doesn't support this property or method".
I double-checked everything I'd done. (No, I hadn't misspelled the method name in the Javascript code... Yes, I really had declared the method to be public in the C# class...) Another one of the senior guys on the team plus my boss (who was the lead developer on the team prior to his promotion) also puzzled over this problem for a while without being able to figure it out.
Finally, my boss came up with the solution: In Visual Studio 2005, in the project properties, on the Application tab, in the Assembly Information dialog, the "Make assembly COM-Visible" checkbox (which was unchecked by default) needed to be checked. After doing this (and rebuilding the project, re-deploying the .dll file, and reopening the IE window), the button could successfully call the public method.
I was pretty surprised by not having run across this issue before. Apparently, though, in Visual Studio 2003 there is either no equivalent checkbox or it is checked by default (and thus similar controls which I had previously created, which worked fine, must have been created using VS 2003). Also, Visual Studio's migration wizard which upgrades VS 2003 projects to VS 2005 projects apparently checks the checkbox by default, which is why we didn't run into this issue after upgrading our product to use VS 2005.
After my development team at work switched to developing using Visual Studio 2005 and the 2.0 .NET Framework, we encountered a problem trying to debug older versions of our Windows Forms controls running embedded in web pages viewed with Internet Explorer with Visual 2003. We would open our project or solution in Visual Studio 2003 and start the debugger to launch Internet Explorer, but shortly after the page with the Windows Forms control would start loading, Internet Explorer would just close with no error message, and the debugging session would end.
Another symptom of the same problem occurred when we instead would try to first open an Internet Explorer window normally and navigate to the web page containing our Windows Forms control, which would load correctly. Then, when trying to attach Visual Studio 2003 to the iexplore.exe process for debugging, Visual Studio would just fail with the error message "Unable to attach to the process."
We eventually determined that the problem was because Visual Studio 2005 along with the 2.0 .NET framework was installed on the development machine, Internet Explorer would load the Windows Forms control using the 2.0 framework (instead of the 1.1 framework as it had previously). Then, when Visual Studio 2003 (which uses the 1.1 .NET framework) tried to attach to the managed code in the iexplore.exe instance for debugging, it would (apparently) get confused and just fail.
The solution we came up with was to use a special iexplore.exe.config file to force IE to load controls using the 1.1 version of the .NET framework. To use this solution, open up a new text editor window and paste in the following text:
<configuration>
<startup>
<requiredRuntime version="v1.1.4322"/>
<supportedRuntime version="v1.1.4322"/>
</startup>
</configuration>
Then, save the file as "iexplore.exe.config" in your Internet Explorer folder (typically C:\Program Files\Internet Explorer). Finally, close and reopen any open Internet Explorer windows.
This will force Internet Explorer to use the version of the .NET framework specified in the file (in this case, 1.1.4322, the version number of the commercial release of the 1.1 framework) for any Windows Forms controls it loads.
To have IE revert to the original behavior of using the default version of the framework to load Windows Forms controls, just delete or rename the iexplore.exe.config file. (On my dev machine, I leave a copy of the file in my IE folder named "iexplore.exe.config_forcev11" for easy access when I need it.)
I was looking for a way to expand and collapse Visual Studio .NET regions, and found one today on Visual Studio Hacks; Ctrl+M, Ctrl+M (chord key combination) expands or collapses the current region. This works on both user-defined regions (from #region and #endregion) and on regions that the IDE itself defines, such as class/method XML comments.
Another Visual Studio .NET keyboard shortcut/feature (also appearing on the linked Visual Studio Hacks page) which I use a lot is Ctrl+Shift+V. Like the standard Ctrl+V supported by most apps, this does a Clipboard Paste, but if you continue to hold down Ctrl+Shift and press V again, the text that was just pasted is replaced with the next-most-recently Copied text. This feature is known as the Clipboard Ring.
In the past, I've run into a problem where when trying to debug a .Net Windows Forms application running embedded in an Internet Explorer window in Visual Studio, breakpoints will not be hit in the debugger. I've seen this issue myself in Visual Studio 2002 and 2003; a colleague just told me that the issue is apparently present in VS 2005 as well.
The solution is in the Project Properties dialog/pane, on the Debug tab, instead of checking the "Start browser with URL" radio button, the "Start external program" radio button needs to be checked instead. In the text field for "Start external program", enter c:\program files\internet Explorer\iexplore.exe (or wherever your local copy of iexplore.exe is located).
Optionally, you can enter the URL of the web page that you want to be initially loaded in the browser in the "Command line arguments" field.
Another thing to verify is that the <object> tab in your web page is pointing to the current debug version of your application's .dll file.
Once that is done, you should be able to successfully hit breakpoints when debugging the application running in the browser.
On my dev team at work, we still use Microsoft Visual C++ 6.0 to build and debug several of our server components. The VC++ debugger does not inclue a mechanism for viewing long strings -- the Watch panel is limited to showing the first 252 characters of a string.
I found a nice VC++ 6 add-on this afternoon that allows an entire string to be viewed and/or copied to the clipboard, called StringWatch. The author's homepage for the add-on appears to be no longer available, but the add-on is available from this page on CodeGuru.
Installing the add-on was a painless process -- I just followed the instructions given in the included index.html file. I didn't need to restart Visual Studio or even end the debugging session that I had in progress.
I'd recommend this add-on to anyone who needs to view long strings (such as SQL or MDX statements) while debugging in Visual C++ 6.
|
|
Posts
