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

Contents tagged with Future

  • 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.

  • XML Documentation Comment Tooltips (Wouldn't it be cool, part 5)

    No Comments

    While I do write XML documentation comments for all my code (except throwaway stuff), I rarely actually read e.g. the CHM file generated by NDoc. But as we all know, a cool feature of VS.Net is that the content of XML documentation comments is used in various situations to display tooltips, which may look something like this:

    Unfortunately, if users of my code (i.e. either other developers, or me after a couple of weeks) read only the tooltips, they may miss valuable information, e.g. descriptions of return values or remarks. The problem is that there's no way to tell whether additional information is available, so one usually assumes that it is not -- especially if you have looked a couple of times into a CHM documentation file for a specific topic only to be disappointed.

    So I think it would be a cool feature if tooltips could display more information, maybe like this:

    Of course the texts should be truncated to a reasonable maximum size (in order to avoid something like the sometimes screen-filling tooltips of the NUnit GUI ;-).

    Other "Wouldn't it be cool" posts:

  • XML Documentation Comments (Wouldn't it be cool, part 4)

    1 Comment

    Each time I implement an interface or override methods in a derived class, I have to copy XML documentation comments for methods and properties manually. This is quite annoying - especially for interfaces, considering the fact that VS.Net 2003 has this cool feature of creating the outline of an interface implementation automatically. So why not create the documentation comments as well?

    Note that I don't want the original documentation referenced using some sort of complicated mechanism. Just Copy and Paste - in many cases the documentation should be tweaked anyway (at least if you want to write readable documentation; who doesn't hate those generic sentences describing "actions" that are "performed" on "items")

    Man, this is something I really would like to see in a future version of VS.Net.

  • Avalon/XAML: Cool, but...

    3 Comments

    I spent most of the past evening (European Time) reading blogs, soaking every little bit of information about the things to come and I must say that I was as excited as I am when following my favorite basketball team's away games reading text messages on the their home page.

    Avalon/XAML sounds like a really good idea to me, but I'm a bit dissappointed that we still seem to be stuck with the same old VB model of "here's the control, it's got an event, there's the event handler". In all the years I have programmed desktop-style applications, it never has been a problem to get a function called when the user clicks on something. What I have been struggling with is the visible/invisible, enabled/disabled logic.

    At some point in a developer's life, most either have written or had to maintain a monster application where adding one additional button would mean changing code in many different places just to make sure the view state of the button is correct. Of the different approaches how to solve this problem, I currently favor the use of the command pattern, which I have used successfully in several applications.

    The command pattern is only one approach, I'm pretty open for other solutions if they're getting the job done. If Microsoft is all about creating next-gen stuff, I definitely expect an improvement in this area. Because that's where a lot of development and testing time is spent ("if I click here, that button is disabled until you select a list item here, which causes this icon to disappear...")

    To those who are at the PDC:

    • In the demos, are there examples of handling the view state (visible/enabled) logic? I suspect that demo code is usually limited to "hey, look how I call this method my clicking that button".
    • Could somebody please ask about plans for solving this problem?

    [For those interested in the command pattern]

    In the C#/.NET world, I've seen the use of the command pattern in different variations. There was an article in MSDN magazine 10/2002 (which explained the basic ideas well, but I think the actual library sucked in many ways), and SharpDevelop does use the command pattern, too. (Regarding SharpDevelop, I must admit that I didn't look beyond the public interface of a command, as I wanted the library I was writing at that time to be as clean as possible from other peoples ideas/code. Right now I'm working on the third version of that library; I will release it under a BSD-style license in the coming weeks).

  • Intellisense (Wouldn't it be cool, part 2)

    4 Comments

    Everytime I use intellisense on a class with a lot of members (e.g. a class derived from System.Windows.Forms.Form) I get overwhelmed by the huge dropdown list if I'm looking for a member I don't know the exact name of.

    So wouldn't it be cool if instead of this...

    ... VS.Net 200x would offer something like this:

    Hiding inherited members...

    ...or showing only certain kinds of members (e.g. only events)...

    ...would be really nice features (and of course something like this is still on my wish list).

  • Getting rid of the 'File' Concept for Source Code?

    No Comments

    Frans writes: After the recent sourcecode control debate I started thinking: why on earth are we still using the 'file' as the base unit to store sourcecode in? The whole 'file' concept is pretty bad and limiting when it comes to sourcecode control, code reuse and overall code management. Much better would it be if we could work with a code repository as the container for our sourcecode which would work with sourcecode elements like we know, e.g.: namespaces, classes, assemblies, resource objects etc. etc.

    Well, I must admit that I'm torn back and forth.

    • I agree that moving away from files could lead to interesting developments, maybe even getting rid of the text-only nature of source code. I'm not only speaking about (gimmicky?) features like photos and drawings inside source code. It's also about getting rid of the need to "serialize" every bit of meta information into stone age raw text.
    • On the other hand, it's just too easy to write or at least use lots of nice little tools outside the IDE that work exactly because of the concept of source code being a bunch of files. And then there's the fear to lose the many workarounds possible with files if things don't work like they should. In case your IDE just won't let you do anything after installing some other software, at least you can copy your source files to some other place and continue your work.

    I honestly don't know. I just can't decide what is better. Maybe it's just the fear to put source "into something I cannot look into using Notepad". Maybe I'm already too traditional. But then I remember the first time I had to trust a new thing called clipboard that text I would "cut" would re-appear using "paste"... so maybe it's time for a different approach.

  • Wouldn't it be cool...?

    6 Comments

    This is what XML comments look like on my computer today:

    Wouldn't it be cool if someday (in VS.Net 200x?) we could have something like this:

    It's kind of frustrating to see computers rendering 3D worlds with 100s of frames/sec, but source code editors advancing only in very small steps...