This is the archived version of Roland Weigelt's weblog that ran from 2003 to 2023 at weblogs.asp.net

Contents tagged with English

  • "Edit in Notepad" Entry in Explorer Context Menu

    No Comments

    Busy preparing version 1.10 of GhostDoc, I'm currently writing the help file (CHM). I haven't spent much time yet on looking for a help authoring tool, so I'm using the HTML Help Workshop which is fully sufficient for the few pages I want to combine in a CHM file. It's one of those "it works, but man who designed the GUI" tools, and some things are done definitely faster when editing the .hhk, .hhp or .hhc file in Notepad (I'm using Florian Balmer's Notepad2 as a replacement).

    I have a shortcut to Notepad in my "Send to" for quite some time now, but recently I got really tired moving my mouse from the top of the explorer context menu to the "Send to" menu over and over again. Fortunately, writing a small registry hack for creating an "Edit in Notepad" entry near the top of the context menu is trivial, here's the .reg file:

    Windows Registry Editor Version 5.00

    [HKEY_CLASSES_ROOT\*\shell\Edit in Notepad]

    [HKEY_CLASSES_ROOT\*\shell\Edit in Notepad\command]
    @="notepad.exe \"%l\""

  • VS2005 Color Scheme / XML Doc Comments : Who's Idea Was That?

    1 Comment

    This is what XML doc comments look like using my current color scheme in Visual Studio 2003:

     

     

    When I took a quick first look into the "Fonts and Colors" options of Visual Studio 2005 I was delighted to see a new setting "XML Doc Attribute", so I was hoping to be able to configure something like this:

     

     

     

    But actually this is what it looks like in Visual Studio 2005 Beta 1 (Express):

     

     

    Umm, this is not what I would call an improvement. I can live with the change of the color of the "///"; personally I like the old version better as I think it's less distracting when reading the doc comment, but I'll get used to the new version.

     

    But what on earth happened to the background color? Visual Studio 2002 and 2003 was perfectly fine. Who came up with the idea to change the behavior behind the last character of the line? Did some customer actually complain about this so it had to be "fixed"? Could somebody please explain the benefits of the new version?

    With the old version, the methods were nicely divided by the doc comments:

     

     

    Why would anybody now choose a different background color for a doc comment at all? This is so frustrating. This is one of those issues that has a low priority compared to the other "really important" ones, so it's likely not to be fixed for the final. And the next chance for a fix is years away. That hurts. Sorry guys, you just broke my heart.

    But anyway, I'll give my feedback, maybe there's still a slight chance...

    Update (2004-07-29): My feedback (FDBK12464) has been declared to be a duplicate of FDBK10617 and thus has been "resolved". These two feedbacks describe related, but different issues, so I can only hope that my feedback has been understood correctly.

  • ReadOnlyRichTextBox

    6 Comments

    Writing texts for dialog boxes can be a pretty time-consuming task. When using only label controls, the constant tweaking of both wording (resulting in longer or shorter sentences, words wrapping in different ways) and overall text layout will drive you mad sooner or later.

    For my Visual Studio add-in GhostDoc I needed a couple of dialogs like this one:

    As the text between the header and the buttons was very likely to be tweaked over and over again, I decided right from the start to use a RichTextBox control (border removed, background color set to the form's background color) and write the text in Wordpad:

    (I chose RTF over HTML because of the speed and ease of use of the RichTextBox on a Winform dialog).

    To make things look a bit more professional it has to be made sure that the content of the RichTextBox can be neither edited (easy, that's what the ReadOnly property is for) nor selected (just a bit more complicated). I wrote a control derived from RichTextBox called ReadOnlyRichTextBox that does a pretty good job at doing just that; the actual code is pretty simple:

    using System;
    using System.Windows.Forms;
    using System.ComponentModel;
    namespace Weigelt.Windows.Forms
    {
        public class ReadOnlyRichTextBox : RichTextBox
        {
            protected override void OnGotFocus(EventArgs e)
            {
                // no call of  base.OnGotFocus(e);
                this.Parent.Focus(); 
            }
            protected override void OnEnter(EventArgs e)
            {
                // no call of base.OnEnter(e);
                this.FindForm().SelectNextControl(this,true,true,true,false);
            }
            [ DefaultValue(true) ]
            public new bool ReadOnly
            {
                get { return true; }
                set { ; }
            }
            [ DefaultValue(false) ]
            public new bool TabStop
            {
                get { return false; }
                set { ; }
            }
            public ReadOnlyRichTextBox()
            {
                base.ReadOnly=true;
                base.TabStop=false;
                this.SetStyle(ControlStyles.Selectable, false);
            }
        }
    }

    This control drives away any attempt to focus or select it. In order for this to work correctly, the ReadOnlyRichTextBox needs at least one other control on the form (for the SelectNextControl). As this is not actually a huge problem, I didn't spend time on finding an alternative solution.

    You can download the code and a small demo here.

  • One Year of Blogging

    No Comments

    I just can't believe that a whole year has passed. I still remember how I gave the whole blogging thing a long thought; I was a bit afraid of ending as one of those "Hi, I'm X and I'm going to write about Y, so stay tuned" bloggers never to be heard of. Well, at least I managed 1 year.

    Looking back, these were my more popular articles, which generate feedback even now, many months later:

    My "Wouldn't it be cool" articles also seem to be pretty popular.

    Ok, the amount of feedback I get (via comments, or via email) may seem laughable compared to what some of the "big guys of blogging" receive, but it's enough to keep me motivated. And that at least a few people have me on their blog roll makes me feel a tiny little bit proud.

    So... let's see whether I can manage another year ;-)

  • GhostDoc is RTM (or is that RTRAC?)

    No Comments

    (RTRAC =  Released to Roy's Addin Contest ;-)

    23:49 the mail with my contest entry GhostDoc left my outbox.

    I'm exhausted. Several nights of only 4 hours sleep are taking their toll. Mostly addin related problems, stuff not working that worked perfectly for weeks. COM registration issues, you name it.

    I had to cut features, there are things that could have been better, but that sucker is out the door.

    I feel satisfied.

  • Crunch Mode

    No Comments

    I'm busy putting the final touches on GhostDoc for entering it here:

    Testing, cutting features, testing, writing release notes, testing, fixing last minute bugs, testing, ...

    Hmm. Some parts of developing software a more fun than others... ;-)

  • Cool Google Search Macro for Visual Studio

    1 Comment

    Marty Garins wrote a really cool macro for performing a Google search from Visual Studio.

     

    See the feedback section of that blog entry for a minor addition I proposed (urlencoding of the search text). By the time you are reading this, it may already be included in the macro code.

    Tip: If you want to limit your search to the MSDN site, add the red text to line building the URL string:

    Dim url As String = String.Format("http://www.google.com/search?hl=en&ie=UTF-8&q=site%3Amsdn.microsoft.com+{0}", selectedText)

  • Strange: GetProcessesByName and Floppy Drive Access

    3 Comments

    Here's something strange: Each time I call the method Process.GetProcessesByName my floppy drive is accessed, which is rather annoying especially if no disk is inserted.

    If you want to try it yourself, here's the code for a minimal command line app:

    using System;
    using System.Diagnostics;
    class GetProcessesByNameDemo
    {
        static void Main(string[] args)
        {
            Process[] arrProcesses=Process.GetProcessesByName("notepad");
        }
    }

    A search on Google Groups for "getprocessesbyname floppy" shows (at least at the moment of writing these lines) that I'm not the only one with this problem; unfortunately I could find neither an explanation nor a solution.

    So.... anybody out there knowing more about this strange behavior?

  • My Transition from Fixed to Proportional Width Fonts for Editing Source Code

    1 Comment

    I always find it interesting to look at source code I wrote years ago. Old dot-matrix printouts (BASIC and Z80 Assembly code from the 80's...) found in a drawer while searching for something else. Or source files in some remote "OldStuff" folder on my storage hard drive.

    These old sources bring back lots of memories and it's nice to see the evolution of my personal style, which shows several cycles of first changing only gradually for some time, then suddenly getting a visible boost after being exposed to new concepts and ideas.

    One thing that really amazes me in my source files back from the 90's is the amount of time wasted on formatting and indentation (sometimes up to the point of thinking "wow, did I do that?"). I'm speaking of things like comment headers for methods:

    /******************************************************
     * Method:    CreateItem
     * Purpose:   Creates a new foobar item using the
     *            specified ID
     * Parameter: id = ID of the item
     * Returns:   created item
     ******************************************************/

    Or end-of-line comments. Often I can literally see code statements and comments fighting for space, with the comments eventually losing and being split to two or more lines:

    splurbyUpdateBits=noobahFlags & pizkwatMask; // a comment explaining what
                                                 // this line is all about,
                                                 // spanning several lines

    And another waste of time: lining up variable names and comments in declarations:

    int      n=0;     // A comment
    SomeType theItem; // Another comment

    A few years ago I started experimenting with proportional fonts for the source code editor, being inspired by screenshots of Smalltalk and Oberon systems I saw in magazines. After finding out that Verdana (unlike Arial) is well-suited as a developer's font, displaying the uppercase I, the lowercase L and the pipe symbol differently, I forced myself to use this font for a while.

    The increase in readability was amazing (especially for long identifiers), but my exisiting source code was a mess when viewed in the editor - all elaborate formatting using tabs and spaces was gone. Not wanting to go back, I had to adjust my commenting and formatting style:

    • I chose a less elaborate design for comments headers (which I won't reproduce here as it was C/C++ specific; now using C# with its XML documentation comments I never felt the need for exactly lining up anything)
    • Wrapping end-of-line comments was no longer an option. Sure, you can line up the comments in your editor using tabs, but in other people's editors (using a different font) the result is unpredictable. So I reduced the need for EOL comments
      • by moving some information to section comments that explain the intention of several code lines, and
      • by writing better code (yeah I know, d'oh!), as long EOL-comments usually are an indicator for bad/complicated parts
      The remaining few EOL comments are short and fit into a single line.
    • I simply stopped formatting variable declarations. Maybe it was a nice thing to do in plain C, but in C++, Java and C# long lists of variable declarations are much less common anyway. What benefited most from lining up were the end-of-line comments behind variable names. But with the switch to a proportional editor font (supported by the Intellisense feature) the length of my variable names grew considerably, and with more expressive names, most comments were no longer required. Now, the few remaining comments don't need to be lined up.

    I'm now using a proportional editor font (Verdana 8pt) for quite some time and I wouldn't voluntarily change back to a fixed-width font. At the same time it must be noted that the transition may not be without problems, depending on your current personal style. But I can definitely recommend giving it a try.