The Repository Pattern is very popular these days. In some environments you will be shredded as a know-nothing if you don't use it for every possible project that involves data storage. And not to knock it, when it was first described, it solved a lot of problems with keeping the code involved with database communication organized and maintainable.
When using the code first option for Entity Framework, in order to control the length of varchar and nvarchar fields on the actual generated database, you can use one of the two approaches:
....you think a SOAP message is a nice way to tell someone he needs to take a shower.
Found a excellent set of examples of the basic techniques of LINQ to SQL. Very helpful on those days when you just can't remember those tricky incantations.
While you'd think something like the following code would work, it doesn't and fails with a frustrating "No constructor defined" error:
Quite a few times, I've needed to create a new row in a table obtained from a web service.
Not really sure why'd you'd do such a thing these days, but C# does support GOTO, so this guy used it to do a line-by-line conversion of an ancient Star Trek written in BASIC in 1972.
Finally found out how to do it! Have been searching (for months) for a way to handle events from buttons dynamically created by code inside a table in ASP.NET. Couldn't find anyone that knew how to do it, couldn't find any web pages with what I was looking for. Got a lot of answers back from posts on other C# message boards, but none of them were correct. I even had several people say that the ability to do so was not present in ASP.NET 1.1 and I'd have to wait and hope it showed up in ASP.NET 2.0. I had actually given up and believed them for a few months. But decided to jump back into it today and found the correct way of doing so after piecing together clues from all over the web. :)
So now, I'm going to try and explain it the best I can, in my own words so that anyone out there chasing down the same concept doesn't get stuck spinning their wheels like I did.
First of all, it's actually embarrassingly simple in retrospect, but getting there was the real trick. I feel kind of stupid admitting it took me so long to figure it out, but I know I'm not alone - I talked with a lot of people on the net and everyone seemed lost as I was so...
The big trick is to use delegates. That's what slowed me down so much, as most explanations of delegates rely on referencing function pointers in C++, which I've never done a whole lot of C++ and never anything using function pointers, so the explanations did nothing for me.
Even worse, the explanations about delegates always involve declaring a delegate and the example code to do so. Normally declaring a delegate is a GOOD thing. However, in the case what I was trying to do (Deal with the click event from the System.Web.UI.WebControls.Button object) there were two things wrong!!
1. The delegate for handling the click event for a Button, LinkButton, or ImageButton (And only these) is ALREADY DEFINED BY THE SYSTEM. That means that you don't have to create the definition, nor can you look at the code for the definition (Other than in the MSDN documentation), and if you try to create your own, you get all kinds of problems. The pre-defined delegate is called CommandEventHandler. More on that after point 2.
2. I said I was trying to work with the Click event. (Oops) With a Button, LinkButton, or ImageButton you don't want to mess with the Click event (although it is there just like it is for all the other GUI objects, so finding out there's something better to use is even better) - You want to use a different event that only exists for the (you guessed it) Button, LinkButton, and ImageButton objects. This event is called Command. It fires the same as the Click event, but allows you to pass additional data via the Button.CommandArgument property. (The normal Click event does not support sending this additional data, thus why you should use the Command event instead of the Click event, unless you just need to see if a button was clicked and do not need any additional data about the click.)
OK, with those two misconceptions out of the way, let's actually get into how to do this:
All you really need to do is create a method that requires two objects sent to it when invoked. The first is the 'sender' object, which identifies which object is calling it (The button itself) and another object called 'CommandEventArgs'. So create a method such as:
ButtonHandler(object sender, CommandEventArgs e)
// Do something
Now, the next thing to do is register the method with the Button.Command event via the pre-defined delegate CommandEventHandler. Say we have a button called newButton. We attach the ButtonHandler method to the Command event of newButton with the following code:
newButton.Command += new CommandEventHandler(ButtonHandler);
Then, with any additional data you need to send to the ButtonHandler method, you add it to the Button.CommandArgument property and it will be sent as part of the CommandEventArgs object that is passed via the delegate. CommandArgument only accepts a string value, so any numerical data to be sent needs to be converted to a string first. In the code example at the end of this article, I am sending both the X and Y position of the table separated by a colon. Since it's a single string, formatting of that string is up to you.
Hopefully this account of my misadventures helps you out!
To try the following example, simply create a new web form, then drag an empty Table from underneath Web Forms in the toolbox to the new form (Leave it named the default name of Table1). Next, drag a label to the same webform, and set its name (ID under properties) to lblInfo.
Here's the example code, enjoy: