I'm trying to get up to speed with C# after years of writing VB code.
I'm trying to add new events in my code. In VB the list of available events is easily accessible but that's not the case in C# and I don't understand the reason for the difference.
I've looked in several books trying to find an explanation for this to no avail.
Can someone please tell me the reason for the difference and/or is there an easy way to add new events to my C# code?
In VB the list of available events is easily accessible but that's not the case in C# and I don't understand the reason for the difference.
Yes, this is a very well known difference between the two languages, which makes working with events much easier in VB than C#.
Can someone please tell me the reason for the difference and/or is there an easy way to add new events to my C# code?
There is no logical reason except that the two languages are done by two different teams who didn't really communicate much and made different decisions. VB has been always making things as easy as possible and doable in GUI. C# on the other hand, targeted more experienced developers who usually favored typing and shortcuts over using GUI.
If you prefer GUI over typing, the easiest way to do it in C# is to select the form or control, open its properties, switch to the list of events, and then double click on the event that you want. This will automatically switch to the code and insert the event boilerplate for you similar to VB.
For the default events (e.g. OnClick), you can simply double click on the form or control in the design mode which will do the above.
Alternatively, switch your Design view to Source view, go to the form or control tag and type the event that you want, it will automatically add ="" for you. Click between the double-quotes, and select the default event name and it will do the above.
Related
In VB, we have the Handles clause, that allows add a Handler to an event of a control without putting it into the xaml file (directly into the VB file).
xaml:
<Button x:Name="myButton" />
VB:
Private Sub Button_Click() Handles myButton.Click
End Sub
One good thing that can be done using this is the possibility to use the Visual Studio dropdowns to add events automatically without the need to go to the xaml file and change it. Read this question (and the answer) to better understand what I'm talking about:
Visual studio 2010 showing available events from code behind
The answer of that question doesn't specify why C# does not have this feature inside Visual Studio, but it's clear for me: C# does not have this feature because it uses the Handles clause to add the event on CodeBehind.
I know that we can make use of the += and add the event manually on the constructor, below InitializeComponent (that is almost the same thing), but VB also have the AddHandler that can add events on the constructor (and in other places), and it's not automatic and less reliable (for me) than the Handles clause.
My question is:
Why it's never implemented? It's non-reliable? Non-secure? There's any workaround?
It was never implemented because no one at Microsoft thought it was useful enough to justify the effort. The exact reasons why can only be answered by someone on the C# team. And while it's true that C# and VB have made an effort to synchronize their features, that doesn't mean they're going to retroactively introduce all VB-specific features in C# or vice versa. (Note that the Handles clause has always existed in VB.NET)
However, one can speculate based on VB's history as a language why it might have been introduced. Namely, that's how VB events pre-NET always worked, so VB developers would probably be used to it.
In traditional VB, events were wired up to objects by name. If you have a Form and you define a subroutine named Form_Load, it will run as your form's Load event. This tradition carried over into ASP, and still lingers as the AutoEventWireup configuration option. VB developers were used to the language knowing what method to run for which events without having to "explain it" to the compiler.
In .NET languages, events are just a particular kind of property with a special type (a delegate type) that have to be assigned like any other property. In order to allow VB developers to transition easily into VB.NET, though, you would ideally give them an easy way to do so without having to learn about events and delegates and handlers (at least not immediately). The Handles keyword accomplishes this -- you just tack on Handles Load onto your Form_Load sub and it becomes an event handler.
C#, on the other hand, has no legacy behavior that it needed to maintain. The target audience for C# consisted of people from many languages, most of which had no built-in concept of events and certainly did not have the auto-wireup behavior of VB. So there was no need to introduce this behavior into the language, but instead, new C# developers would just learn the "right way" of doing things from the start.
With the introduction of WPF and MVVM view/model separation and the push for minimal code-behind, a handles keyword becomes a bit more attractive, but it still seems to go against the general principles of how C# handles events. I suspect it would take a very, very strong argument to convince the C# team that it was worth implementing.
I have an extension idea, but I don't know where the first step is. I know that using design view, in conjunction with properties, I can get an event list for a control.
I want to write something that would show me a context menu in source view on something like OnClick="Button1_Click" and generate an empty event method in code behind complete with args.
(the equivalant of double clicking a button in design view)
I've never coded against the IDE itself, and I'm not having any luck finding a jumping off point, but I relly want some info that relates to that 'events' section of the properties box.
EDIT: why am I getting negative numbers for asking a question, am I asking it wrong?
MSDN will help :) See these pages on how to provide a custom properties window.
However, it won't be just as easy as your example, unfortunately. There's quite a bit of infrastructure to deal with when programming VS extensions. I'd recommend reading up on VS Integration on MSDN.
Ok, so admittedly, I did not ever figure out how to do this. However, I've just read the VS11 will be doing this. I am happy to see that M$ has added this functionality going forward. They've also added smart tags to the html view, which means maybe never having to go to design view again!
More Details Here:
http://weblogs.asp.net/scottgu/archive/2011/08/31/html-editor-smart-tasks-and-event-handler-generation-asp-net-vnext-series.aspx
I have a C# WPF application. It is designed to work on any and all files. Right now, it accepts 'input' by means of commandline arguments as well as drag and drop to a control in its main window. However, ideally I want people to rightclick any file/multiple files and have them be able to simply click 'Awesomify this'. (That's not the real name. :P)
I've got some experience with context menus from years ago, so all in all, it isn't too current. As such, I am looking for advice on the best way to implement this feature. All examples following are based on what I see using W7.
Generally, I understand there's basically two ways: pure registry, and registry + COM object.
The former has a certain elegance to it, since I don't want anything special; however, from what I can tell by documentation, these menu items always clump up at the same place as the primary file actions (Open, Preview, Print). However, I'd like my item to appear lower on the totem pole. If I look at my personal contextmenu for a random file, I'd want it to be at the 'spot' UltraEdit and Malwarebytes Anti-Malware stick themselves. Sticking my entry under HKCR\*\shell\AwesomeTest gets me my item, but no matter what I pick for the Position, I get two different extremes I don't like: Top puts it above the default item, Bottom puts it right above Properties. I want it inbetween Share with and Restore previous versions, which where most general-purpose tools seem to find a home.
Some more registry digging seems to point out the apps I wish to mimic use the COM object route. And that would bring me (I believe) back to native code. Which would then bring with it all the hells of 32-bit and 64-bit development I am trying to avoid.
Is there anything I am missing? Likewise, other than the MSDN page regarding context menu handlers which I have looked through and found to be rather unhelpful (as it seems to skim a lot without diving into the more precise details regarding placement and such), are there any good sources regarding this problem?
Another thing I've not been able to figure out just yet is how I can properly add IDropTarget support to my .NET WPF application yet, so information on that would also be welcome.
If anyone has an instant answer, well that would be nice, but I am mainly trying to find the right path to take without wasting several days on the paths that are dead-ends. Which there seem to be a lot of. :(
IContextMenu::QueryContextMenu(). Shell extensions are in the domain of C++, very unpleasant in C#, .NET 4.0 required. A sample project that uses it is here.
Is there an easy way (or perhaps a third-party implementation) to programmatically create a MessageBox with various types of controls on it? Ideally, with some sort of scripting language (ie. XML).
I would prefer not to code this myself from scratch.
There are two ways to do this. One is called WinForms, the other WPF. The latter even uses an XML language (called XAML). Since you didn’t specify what kinds of controls you need, this is the best answer I can offer to your question because it covers the widest available range of controls.
Could you not create a form and customise it as a compromise?
I had a similar question.
Custom MessageBoxes are much simpler to create than what I thought.
How to create a custom MessageBox
Visual Studio is kind enough to generate a lot of code for us when we create and design Windows.Forms controls. It also surrounds most of it with a #region statement.
In newer versions it also uses a partial class to separate generated from manually created code.
Developers are supposed to edit code only in certain areas.
But nothing prevents us from violating this in whatever way we please.
I'm fine with manual edits that could just as well have been made from the designer, or manual edits in areas the designer doesn't touch. But I'd like to flag any other kind of edit.
Does anyone know a utility that can do this? StyleCop rules perhaps?
I mostly need it for the combination of C#, Windows.Forms, and Visual Studio 2003, 2005, and 2008.
These days, designer code should end up in a .Designer.cs file. It should be very rare that developers need to touch that. Unfortunately, I don't know any way of verifying that the code was genuinely generated by the designer. It would be handy if it included some sort of hash, but it doesn't as far as I'm aware...
Given how easy it is now to just say "don't edit designer files" do you really need another system though? It's not like you need to stay away from specific regions - it's the whole file which is out of bounds.
Why should developers not be allowed to change this code? If they are able to write code that works, they should be allowed to do it. If they are not able to write code that works, lets say they should be trained or fired.
You just have to extend the meaning of "it works" to "it works at runtime as well as in the designer". So what's wrong about that?
Todays gui designers are not very restrictive and are doing a good job in "understanding" code that had been written by a human.
There is also real generated code around, for instance code generated by some xml specification, resources etc. This code is generated when building, so when it had been changed, these changes are undone whenever the application is built.
Designers are not real code generators of this kind. They are a kind of "coding helpers", helping the developer to write code faster then by typing it in. But it should actually be possible to write the same kind of code manually although limiting one self to the designers capabilities is a reasonable maintainability decision.