locked
Visual Studio does not display C# events in dropdown like VB.Net. RRS feed

  • Question

  • I'm migrating from VB.Net development to C# development and have a problem in the Visual Studio 2008 Team System Developer Edition.

    When I create a project as a Visual Basic.Net application and open a new .vb code file, at the top of the interface there are two dropdown lists that respectively display objects/events and methods associated with those.  I don't know what those dropdowns are called, but that's what they display.  These are very useful especially when working with new objects or code that may require me to intuit the available events associated with an object.  The VB.Net side of the IDE for 2008 works as expected, and as it has in VS 2005 and before.

    However, in C# the left dropdown list fails to display events, which is quite annoying.  My guess is that there is an Visual Studio option or registry setting that I need to toggle for C# to display those events.

    The current project I'm working on is a VSTO add-in for Outlook.  For comparison I created a C# project and a VB project.
    C# displays only 1 option:
    - OutlookAddIn1.ThisAddIn

    VB.Net displays 5 options.
    - General
    ---- ThisAddIn
    -------- (ThisAddIn Events)
    -------- Application
    -------- CustomTaskPanes


    Again, I'm relatively new to C#, though I've worked with VB.Net for several years now.  Can someone show me how to get the C# side to display those options?  If this is unavailable, what approach do you professional C# developers use to intuit available events?  Thanks.
    Wednesday, June 4, 2008 5:40 PM

Answers

  • As Andy mentioned there is no such option in C#.  The mindset of a C# dev is different than a VB dev IMHO.  Showing the available events (in the context you mention) isn't that useful in C# for a couple of reasons.  Firstly an event is almost always tied to an instance of an object.  In VB each code file generally represents a module or class and, hence, the associated events are pretty easy to pick off.  In C# this is not the case as a single file can house a type along with some delegate definitions or even other types. 

    The toolbar does track the active object but, and this is where things really start to differ, in general you will almost never handle an event from within the raising class itself.  Even in VB this is a really bad idea but it seems to be easier than the "correct" way I guess.  In almost all cases when you are in a derived class and you want to handle an event you will not waste the time to hook into the event as this is slow and limiting.  Instead you'll override the method that raises the event.  All good class designs mandate that an event is raised from a virtual protected method that derived classes can override. This gives ultimate flexibility to derived classes while not limiting what they can do.  Take, for example, a custom button class you wrote.  You want to do some preprocessing before the Click event is sent on to potential handlers.  If you hook the event from within a derived class you are not guaranteed to be called first unless you hook the event in the constructor.  Even worse however is that some code can come along and drop your handler altogether.  Therefore, in C#, you should almost always override the virtual method in lieu of hooking an event.  When you type 'public override' you'll get a list of all overridable methods.  This would be the equivalent of the event dropdown in VB.

    The only issue that remains is getting a list of events when you are not deriving a new class, such as from a button object.  In this case the dropdown lists won't help you at all since they track the active scope and not the object instances.  Intellisense doesn't auto-filter based upon events but events do stand out because they have a lightning bolt next to them. 

    You can also use Object Browser or Class View to get a list of events or other members but these might not be as convenient.

    Michael Taylor - 6/5/08
    http://p3net.mvps.org
    • Proposed as answer by JohnGrove Thursday, June 5, 2008 5:41 PM
    • Marked as answer by KenPalmer Thursday, June 5, 2008 7:13 PM
    Thursday, June 5, 2008 2:19 PM
    Moderator

All replies

  • it seems that C# IDE does not have the same behavior with VB.net on what you mentioned. one alternative way to code for event is to do on *Property window*. firstly you select your expected object and open property window. click event toolstrip button on that window. you will see all the events for specific object you selected. select one, and double click. C# IDE would generate some handler codes for you.

    wish it helpful! keep in touch.
    Thursday, June 5, 2008 12:17 AM
  • As Andy mentioned there is no such option in C#.  The mindset of a C# dev is different than a VB dev IMHO.  Showing the available events (in the context you mention) isn't that useful in C# for a couple of reasons.  Firstly an event is almost always tied to an instance of an object.  In VB each code file generally represents a module or class and, hence, the associated events are pretty easy to pick off.  In C# this is not the case as a single file can house a type along with some delegate definitions or even other types. 

    The toolbar does track the active object but, and this is where things really start to differ, in general you will almost never handle an event from within the raising class itself.  Even in VB this is a really bad idea but it seems to be easier than the "correct" way I guess.  In almost all cases when you are in a derived class and you want to handle an event you will not waste the time to hook into the event as this is slow and limiting.  Instead you'll override the method that raises the event.  All good class designs mandate that an event is raised from a virtual protected method that derived classes can override. This gives ultimate flexibility to derived classes while not limiting what they can do.  Take, for example, a custom button class you wrote.  You want to do some preprocessing before the Click event is sent on to potential handlers.  If you hook the event from within a derived class you are not guaranteed to be called first unless you hook the event in the constructor.  Even worse however is that some code can come along and drop your handler altogether.  Therefore, in C#, you should almost always override the virtual method in lieu of hooking an event.  When you type 'public override' you'll get a list of all overridable methods.  This would be the equivalent of the event dropdown in VB.

    The only issue that remains is getting a list of events when you are not deriving a new class, such as from a button object.  In this case the dropdown lists won't help you at all since they track the active scope and not the object instances.  Intellisense doesn't auto-filter based upon events but events do stand out because they have a lightning bolt next to them. 

    You can also use Object Browser or Class View to get a list of events or other members but these might not be as convenient.

    Michael Taylor - 6/5/08
    http://p3net.mvps.org
    • Proposed as answer by JohnGrove Thursday, June 5, 2008 5:41 PM
    • Marked as answer by KenPalmer Thursday, June 5, 2008 7:13 PM
    Thursday, June 5, 2008 2:19 PM
    Moderator
  • TaylorMichaelL,
    That was an excellent description.
    John Grove - TFD Group, Senior Software Engineer, EI Division, http://www.tfdg.com
    Thursday, June 5, 2008 5:44 PM
  • Michael,
    Thank you for the insight.  Your p3.net site is impressive.

    The mindset of a C# dev is different than a VB dev IMHO.  Showing the available events (in the context you mention) isn't that useful in C# for a couple of reasons.  Firstly an event is almost always tied to an instance of an object.  In VB each code file generally represents a module or class and, hence, the associated events are pretty easy to pick off.  In C# this is not the case as a single file can house a type along with some delegate definitions or even other types. 

    This makes sense. I was unaware of this difference.  Right now I'm about 200 pages into the Wrox Beginning C# 2008 book, which means I've barely scratched the surface.  The different paradigms will admittedly take some adjustment.  But so far learning C# has been very exciting, even at this very low, introductory level.

    I need some help understanding another idea you presented.

    The toolbar does track the active object but, and this is where things really start to differ, in general you will almost never handle an event from within the raising class itself.  Even in VB this is a really bad idea but it seems to be easier than the "correct" way I guess.  In almost all cases when you are in a derived class and you want to handle an event you will not waste the time to hook into the event as this is slow and limiting.  Instead you'll override the method that raises the event.  All good class designs mandate that an event is raised from a virtual protected method that derived classes can override. This gives ultimate flexibility to derived classes while not limiting what they can do. 

    Can you clarify this a bit more, perhaps by pointing me to a code sample?  Thanks.
    Thursday, June 5, 2008 6:33 PM
  • If you were coming from a VB6 background and going into C++ I'd be laughing at you and recommending a course.  However VB.NET and C# are far more similar than they are different.  You should have no problems picking C# up.

    As for an example let's take the code version of the text I mentioned.  You created a new WinForms button class that displays a confirmation message to the user before it allows the click.  If you go the event route you'd do this:

    public class ConfirmationButton : Button  
    {  
        public ConfirmationButton ( )  
        {  
            Click += OnClick;  
         }  
         
        private void OnClick ( )  
        {  
            if (DisplayConfirmationMessage())  
               ...  
            else 
              //Nothing we can do here, the button is already clicked  
        }  

    This code suffers from a few problems.  The biggest issue is that you can't "cancel" the click event if the user says No to the confirmation message.  You, and everybody else, just know the button was clicked.  Furthermore your handler might be called (so the user gets the confirmation message) after somebody else has already done some work in reaction to the event.  Not good.

    The better route is to handle the event through the exposed virtual method when it is available. 

    public class ConfirmButton : Button  
    {  
       protected override void OnClick ( object sender, EventArgs e )  
       {  
          if (DisplayConfirmMessage())  
             base.OnClick(sender, e);   //Raises the event  
          else 
             //Ignore request  
       }  

    Almost all Windows messages go through a virtual method but custom controls or other classes might work different depending upon how they are implemented.  Of course this only works when deriving a new class.  Don't derive a new class just to avoid writing an event handler though. 

    In your custom classes that you write that you want to be extensible you should follow this pattern to make it easier on your derivers.  Here is how you would typically implement an event in a class:

    public class SomeClass  
    {  
       public event EventHandler SomeEvent;  
     
       protected virtual void OnSomeEvent ( <parameters> )  
       {  
           EventHandler hdlr = SomeEvent;  
           if (hdlr != null)  
              hdlr(this, <build event args>);  
       }  

    Michael Taylor - 6/5/08
    http://p3net.mvps.org
    Thursday, June 5, 2008 6:56 PM
    Moderator
  •  Now I see what you're saying.  Thanks so much for that code.  That especially clarifies why it's important to "override the method that raises the event." 

    If you were coming from a VB6 background and going into C++ I'd be laughing at you and recommending a course.  However VB.NET and C# are far more similar than they are different.  You should have no problems picking C# up.

    I'm with you there.  :-)
    I've been programming for over 8 years, but came at web development from the backwards path of learning HTML, then JavaScript, Classic ASP, VB.Net, and now C#.  So I'm gradually working my way UP the programming food chain.
    Thursday, June 5, 2008 7:11 PM
  • thanks guys for this rather shocking information.  I just switch to c# officially and vs2008 about a week or so ago and I thought I was missing an ide option in vs2008.

    not quite the answer i was looking for.  Yet an excellent answer which I doubt would be simple to find in a book.

    I think I understand the big picture of overriding.   Yet not sure how or when to apply it.  Where could I get some help with this?

    I know DotNetNuke uses overrides alot using vb.net and I could tell when running a debugger on the dotnetnuke framework that depending on the scenario (the way the control was used) the code would run to the override version of a sub procedure or it would more often just run what I would call the initial or the main procedure.  Which was ususally a sub procedure with the same name but with out the public overide part and with much less code.

    KenPalmer said:

    "C# the left dropdown list fails to display events, which is quite annoying"







    Saturday, August 9, 2008 5:48 PM
  • In my environment I just have to select the datagrid or control hit (f4) and doulble click the lightning bolt.

    now if I can just get my datagrid to insert!

    I cannot even do if I call a stored procedure. 

    does visual studio have trouble inserting records that use foreign keys? 





    Saturday, August 9, 2008 6:58 PM