Autocompletion in c# / asp.net

[Christopher Duncan]

Hey, guys.

I currently have v.11 and still haven't managed to switch myself over from my ancient CodeWright, which my fingers know quite well. The main reason I bought it was thinking that I could get Visual Studio style autocompletion for the .NET framework as well as for the <asp:YadaYada tags in the .aspx files. At this point I'm still not entirely sure if there's full support for this or not.

Tagging works fine on .cs files containing classes I write, but I can get no autocomplete for the actual .NET framework classes. Curiously, when I try to manually generate the C# tag files, it scans the VC++ headers - I did it twice to make sure I didn't just get happy with the mouse. Additionally, the only autocomplete I get in .aspx files is some general html stuff.

Consequently, I find myself toggling back & forth between my editor and Visual Studio, as autocomplete is typically more useful than MS documentation these days. I would love to stay in my editor, but in the c# / asp.net world I just can't seem to get this one critical feature working.

So, I thought I'd poke my head in and ask the most fundamental of questions. Is autocomplete for .aspx files (<asp:Table, etc.) and the .NET 2.0 namespace in C# supported? If so, can anyone tell me which switch to flip?

Many thanks,

Christopher

[jbhurst]

Hi Christopher,

I don't do much .NET, but it just happens I have inherited a VB.NET app for maintenance. I have SE 12, but .NET support was included prior to this.

In the Context Tagging window (Tools > Tag Files) you should see a dotnet.vtg tag file in one of the groups. The right-hand pane for this tag file should show a bunch of DLLs and XML files for your framework SDK. That's how you get support for auto complete on C# (and VB.NET).

If the framework SDK is not tagged, you should be able to tag it using Auto-Tag. I can't remember for sure whether SE 11 had .NET in the Auto Tag setup, but I think it did (along with C++ and Java).

With my current config SE doesn't seem to know about <asp:Blah>, so I'll need to look into that.

Regards

John Hurst
Wellington, New Zealand

[Christopher Duncan]

Hey, John.

Thanks for the help. I'd poked around in the tools / tag files area before, but I went back and kicked the tires again after your post and was able to get it wired up with the .net libs.

That's half the battle. However, in looking at the languages supported for tagging, I see C#, HTML, but no ASP.NET. Given the tremendous market presence of the MS ASP.NET stuff, I'm really surprised that I don't see any support for it, and it's kind of a showstopper for me.

I've paid for a couple of SE versions and yet still haven't moved over to it because it never seems to get me all the way there. I still have to keep toggling back and forth between my editor and Visual Studio, and since it doesn't solve that problem my motivation to learn yet another editor suffers. Since there doesn't appear to be support for the ASPX extensions of HTML, looks like that's still the case.

I do appreciate  your help though, thanks!

Christopher

[Matthew]

The short answer is no, we do not have auto-completion support for ASP.net tags. We haven't had a flood of feature requests for this, and I suspect that is because most folks doing ASP.net are relying heavily on the visual designer support found in Visual Studio.

After reading your post and taking a closer look at what it would take to implement it, ASP.net really is a pretty strange bird. You've got the <asp:yyy> tags, which look a lot like an XML tag with a namespace declaration. But of course the file isn't well formed XML by any stretch. And the declarations of the elements don't live in any sort of XSD schema, but rather the System.Web.UI.Control .NET namespace. So now we've got an HTML file, with some elements having valid declarations and context dictated with XML-schema-like rules, and said classes for those elements and their properties coming from a subset of the .NET framework. Oh, and it's "anything goes" inside the <ItemTemplate> tags...

Ok, please excuse the rant. I guess that's just the roundabout way of saying that there isn't any quick switch to flip to turn this feature on, and it's not a quick-turnaround feature.

However, there is something that can be done to give you a little help. If you examine the autocompletion file for HTML (the builtins\html.tagdoc file), you'll see that the declaration syntax for tags is pretty simple. It might be a lot of work as most of the ASP.net controls have a ton of attributes. But this simple sample shows you how you can add declarations of the tags.

Code: [Select]

private enum RUNAT_LOCATIONS{
   server
}

tag "asp:content"{
   attr ID;
   attr ContentPlaceHolderID;
   attr EnableViewState{
      true false
   }
   attr RUNAT_LOCATIONS runat;
   attr Visible{
      true false
   }
}
I would create this as a separate file named aspdotnet.tagdoc. Once you've added the declarations, go to Tools > Tag Files... , and highlight the child entry for the .vtg file under the "HTML" Tag Files entry in the tree. Then click the "Add Files..." button, change the file type filter to *.*, and locate your aspdotnet.tagdoc. After you've added your custom tagdoc, you'll need to click the "Rebuild Tag File" button to incorporate the new declarations. (Screen shot attached)

[Christopher Duncan]

Hi, Matthew.

Thanks for the in depth reply and the tips on hacking the html tags myself. I suspect I can do that in Codewright as well, so I may give that a go.

...most folks doing ASP.net are relying heavily on the visual designer support found in Visual Studio.

If you want to add to your rant of awful things, the clumsy and poorly implemented "visual designer" should definitely be on the list, which is why I write code and depend on a programmer's editor.

Have a good week,

Chris

[Phileosophos]

However, there is something that can be done to give you a little help...

This thread was brought to my attention when I submitted a similar question. I'm having pretty good success with the suggested approach, Matthew, but I have a question: is there any reason to prefer creating enumerated types to listing the values? For example, the AutoCompleteType property of the asp:TextBox can have quite a few different values, among which are enumerated None, Disabled, Cellular, etc. So there are two ways to do this in a tag doc.

Code: [Select]


/* Method #1: */

private enum AUTO_COMPLETE_TYPE {
    None
    Disabled
    Cellular
    /* and so forth... */
}

tag "asp:TextBox"
{
    attr AccessKey;
    attr AUTO_COMPLETE_TYPE AutoCompleteType;
    /* and so forth... */
}

/* Or Method #2: */

tag "asp:TextBox"
{
    attr AccessKey;
    attr AutoCompleteType {
        None Disabled Cellular /* and so forth... */
    }
    /* and so forth... */
}


Which of these two methods is preferred? Is there any difference? If so, what? I see both seem to work, but they provide different little icons, and I'm not sure what those mean.

[Matthew]

There's no real  "preferred" way, which is why I showed both in the sample. If you find that you're typing the same enums over and over again, using an enum def might be the way to go. But my guess is that tagdoc is gonna get pretty big really quick, so having the definitions inline may make it easier to author and navigate (yet a bit more verbose). As far as the tag recogition/completion goes, it's all the same.

[Phileosophos]

Additional, follow-up silly questions. First, if there's really no difference, why do the two methods produce different graphics in the lists that pop up? And second, because I didn't feel like typing all this stuff in by hand, I wrote an AWK script that processes the text as copied from the Microsoft help system. Once I have it working better, I'd be happy to contribute if there's any interest.

[Phileosophos]

I'm uploading the ASP.NET tag document I've been using for the last few days. It should be considered a "first draft". It borrows the HTML color codes from the SlickEdit HTML tag document, but it's otherwise the output of an AWK script I wrote to process the Microsoft help entries on the relevant controls. I'm pretty confident it has errors and omissions, but it should serve as a good starting point for others if nothing else.