More and more often I've been seeing C# code like this:
var Data = GetData();
What on earth does GetData() return? This code is not as maintainable as it could be and is not as maintainable as it should be.
Doesn't explicitly declaring the variable type make the code more readable, understandable and ultimately more maintainable?
DataTable Data = GetData();
Ahhh, GetData() returns a DataTable.
I know that var has uses but I wish it would have been named something much longer because typing 'var' is too easy. Perhaps it should have been named AutomaticTypeVar or even AutoVar to reduce the lazy misuse.
Just my 2 cents.
Steve Wellens
"The SQL command ran, there's no error message but nothing changed! What's going on? Do you think it's a virus? Maybe there's a bug in .NET!"
The junior programmer was almost in tears when he came to me for help. Proud and confident in his abilities and faced with failure on what should have been an easy task, the poor little fellow's puffed up ego collapsed like a house of cards. I patted him gently on the shoulder and said soothingly, "It's because you're an idiot."
OK, I didn't really say that.
Actually, having an SQL update statement not change any records and not produce an error is expected and desirable behavior:
If you run an update to add a late fee to all outstanding accounts over 2 weeks late and there are no late accounts….the update will succeed, no records will be modified and there will be no error message. This is as it should be.
When an update does not produce an error and no records are modified, it's because the WHERE clause did not locate any records to update. Sometimes this is OK, other times it is a mistake.
Here are three ways this can happen by mistake:
Case Sensitivity Misses:
If the collating sequence of the database or column is case sensitive, the text in the column may not match the text in the WHERE clause: Z123 does NOT equal z123. In SQL Server the default is case insensitive.
Space Padded Data:
The field type in the database may space pad the data. In SQL Server, if a column type is char(6) or nchar(6) and 'ABC' is saved, what is actually put in the table is 'ABC ' (note the 3 spaces after ABC). A search for 'ABC' will fail because 'ABC' does not equal 'ABC '.
Dates with Extraneous Times Stamps
DateTime columns have two components (Date and Time…duh). If you are searching a DateTime column either the data or the search criteria may include a timestamp that causes the search to fail:
12-31-2000 12:23:45 AM does not equal 12-31-2000 12:00:00 AM
When storing dates, it is a best practice to truncate the time of DateTime fields so the times are zero (or 12:00:00 AM).
Here is an SQL statement to scrub existing data:
UPDATE MyTable SET MyDate = dateadd(dd, datediff(dd, 0, MyDate), 0)
When searching for records you can set the search criteria to include only the date by using the Date property of the DateTime structure:
DateTime SearchDate = DateTime.Now.Date;
Note: SQL Server 2008 has new data types of just DATE and TIME.
Bonus: Floating Point Numbers:
This is extremely rare but if you have floating point numbers in the data and expect to use an exact WHERE clause to retrieve and update data, good luck. As everyone knows who's taken Numerical Analysis 1001:
1.50000000000 does not equal 1.49999999999
Final:
If you are unsure of what is going to be updated in a statement, it is easy to replace the UPDATE with a SELECT and check what is actually being retrieved.
I hope this helps someone.
The seventh Twin Cities Code Camp will be held Saturday, October 24, 2009 from 8:00 AM to 5:30 PM on the University of Minnesota Campus.
For a list of sessions and a schedule, go here: http://www.twincitiescodecamp.com/TCCC/Fall2009/Schedule.aspx
To sign up, go here: http://www.nhmn.com/Courses/CrsDetail.aspx?C=NHTCCodeCampVII
Hey, what else are you going to do on a Saturday in late October in Minnesota…it'll be too cold to play golf!
Man is small and the .NET environment is vast. After years of working in the .NET environment, you can still find new and amazing features. A user on the Asp.Net forums posted this feature I had never discovered…so I thought I'd pass it along.
The CompareValidator is used to compare the value of data in a textbox but it can also validate the type of data entered into a textbox.
It can validate these types:
- String
- Integer
- Date
- Double
- Currency
You have to set the Operator attribute to DataTypeCheck and the Type attribute to one of the above values.
Here's a link with the details:
http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.basecomparevalidator.type.aspx
Here's an example:
<asp:TextBox ID="TextBoxInteger" runat="server"></asp:TextBox>
<asp:CompareValidator ID="CompareValidator1" runat="server"
ControlToValidate="TextBoxInteger"
Operator="DataTypeCheck"
Type="Integer"
ErrorMessage="Please enter an integer" />
<br />
<asp:TextBox ID="TextBoxDate" runat="server"></asp:TextBox>
<asp:CompareValidator ID="CompareValidator2" runat="server"
ControlToValidate="TextBoxDate"
Operator="DataTypeCheck"
Type="Date"
ErrorMessage="Please enter a valid Date" />
I hope someone finds this useful.
Steve Wellens
XSLT stands for Extensible Stylesheet Language Transformations.
There is so much to learn in our technical world… and so little time….and for some of us, even fewer brain cells. Alas, such is the life of a nerd/dweeb/geek.
The latest technology I spent brain cells on is XML Transforms. You've probably seen those mysterious little files with the XSLT extensions that do magically wondrous things to XML files.
For traditional developers, XSLT is weird because it's not a traditional procedural language: "Do A, if successful then do B". XSLT uses "templates" with XPATH to select a group of nodes and then formats the selected nodes in the template body. To delve deeper into the document, XSLT uses sub-templates in a recursive tree-like fashion. However, these sub-templates are disjointed hunks of text in the XSLT document so it's difficult to visually comprehend what is going on…at least to an untrained eye.
This post isn't going to explain how XSLT transforms work—it's going to explain how to run them under the Visual Studio Debugger and watch them do their magic. FYI: I only tried this with VS 2008.
For more information on XSLT, go to the WC3 website here.
Here is the XML input file we are going to work with:
<?xml version="1.0" standalone="yes"?>
<Golfers>
<Golfer >
<ID>1</ID>
<Name>Bobby Jones</Name>
<Birthday>1902-03-17</Birthday>
</Golfer>
<Golfer>
<ID>2</ID>
<Name>Sam Snead</Name>
<Birthday>1912-05-27</Birthday>
</Golfer>
<Golfer>
<ID>3</ID>
<Name>Tiger Woods</Name>
<Birthday>1975-12-30</Birthday>
</Golfer>
</Golfers>
Here is the XSLT file we are going to transform it with:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/Golfers">
<Golfers>
<xsl:apply-templates select="Golfer"/>
</Golfers>
</xsl:template>
<xsl:template match="Golfer">
<xsl:element name="Golfer">
<xsl:attribute name="ID" >
<xsl:value-of select="ID"/>
</xsl:attribute>
<xsl:attribute name="Name" >
<xsl:value-of select="Name"/>
</xsl:attribute>
<xsl:attribute name="Birthday" >
<xsl:value-of select="Birthday"/>
</xsl:attribute>
</xsl:element>
</xsl:template>
</xsl:stylesheet>
The transform file will turn the XML elements into attributes. Why do this? Because the .Net DataSet and DataTable classes seems to prefer XML attributes when reading XML files. And, because after studying XML for a long time, I've come to prefer sub-elements when there is a one-to-many relationship and to prefer attributes when there one-to-one relationship between the elements.
To start, first open up the XSLT file in Visual Studio:
The XML tool bar should appear:
If it doesn't appear, right click on the toolbar area and turn it on:
Put a breakpoint in the XSLT file (F9 or use the mouse or use the Debug menu):
Click the Debug XSLT button:
The first time you run it, an open file dialog will prompt you: "Choose Input XML Document."
Note: Subsequently when you run it, the input file will open automatically*.
The standard Debug toolbar will appear. With the toolbar you can start stepping through the transform code. Two synchronized windows will be open:
In the image above, I've clicked 'step' several times. You can see in the right window that the second XML node is being processed.
If you go to the Debug menu and select Locals, you can get more information about what is happening:
You can do watches and other debugging things while the code is paused. You can see the output file being built in the window behind the input XML window.
When it's all done the new XML file will look like this:
<?xml version="1.0" encoding="utf-8"?>
<Golfers>
<Golfer ID="1" Name="Bobby Jones" Birthday="1902-03-17" />
<Golfer ID="2" Name="Sam Snead" Birthday="1912-05-27" />
<Golfer ID="3" Name="Tiger Woods" Birthday="1975-12-30" />
</Golfers>
As my Canadian friends would say: "That's pretty cool, eh?"
*To override the automatic opening of the XML input file, right click the XSLT file and select properties. You can edit the input and output file paths and names:
That's it. Who knew the Microsoft boys and girls would go to such depths to provide such a powerful tool. It was a pleasant discovery.
I hope someone finds this useful.
Steve Wellens
There was a question about this on the Asp.Net forums and after a quick search I didn't find a good generic function so I thought I'd supply one.
Note: I wanted this to be as broad and useful as possible, so the second parameter is a ListControl which both the ListBox and DropDownList inherit from.
I also made sure the function would handle enums that had non-contiguous values that didn't necessarily start at zero.
The function:
// ---- EnumToListBox ------------------------------------
//
// Fills List controls (ListBox, DropDownList) with the text
// and value of enums
//
// Usage: EnumToListBox(typeof(MyEnum), ListBox1);
static public void EnumToListBox(Type EnumType, ListControl TheListBox)
{ Array Values = System.Enum.GetValues(EnumType);
foreach (int Value in Values)
{ string Display = Enum.GetName(EnumType, Value);
ListItem Item = new ListItem(Display, Value.ToString());
TheListBox.Items.Add(Item);
}
}
Usage:
I tested with an existing enum and a custom enum:
enum CustomColors
{ BLACK = -1,
RED = 7,
GREEN = 14,
UNKNOWN = -13
}
protected void Button1_Click(object sender, EventArgs e)
{ EnumToListBox(typeof(DayOfWeek), DropDownList1);
EnumToListBox(typeof(CustomColors), ListBox1);
}
Note: I initially tried to get the order of the items in the ListBox to match the order of the items in the enum but both the Enum.GetValues and Enum.GetNames functions return the items sorted by the value of the enum. So if you want the enums sorted a certain way, the values of the enums must be sorted that way. I think this is reasonable; how the enums are physically sorted in the source code shouldn't necessarily have any meaning.
I hope someone finds this useful.
There are plenty of tips out on the web that I see no need to repeat here. But this one made such a remarkable difference on my box that I had to post it….
I use the Auto-Hide property on the Toolbox to preserve screen real-estate. After adding the Ajax control toolkit to my environment, the Visual Studio Toolbox started to really drag. Instead of popping up quickly, the hard disk would churn for several seconds and the Toolbox would struggle, agonizingly and with apparently great reluctance, to appear.
When it did eventually appear, random sections of the Toolbox would be open. It didn't remember which tab was last used. Assuming the logic is in a background thread, I can only assume the thread was poorly written. If it was tested, the test results were ignored.
Thank goodness for the TooboxAutoPopulate setting.
Tools->Options->Windows Forms Designer->General
Setting AutoToolboxPopulate to False brought my machine back from the abyss of lost productivity caused by slow, clunky, energy-sapping GUI delays. Although the setting is under Windows Forms Designer, it is just as effective for ASP.Net developers (it's the same Toolbox).
I hope someone finds this helpful.
Steve Wellens
This post is for beginners.
Many beginners struggle with the concept of an Interface. Over on the Asp.Net forums, where I moderate, the question is asked a surprising number of times. I'm going to try to describe and explain the concept of an Interface…simply and concisely.
Let's say we are going to program a game and the game needs a random number generator.
We want to try different random number generators because all random number generators are not created equal. To make it easy to switch number generators, we will use an Interface.
The Interface:
So, here is the (simple as possible) Interface for our Random Number Generator:
interface IRandomNumberGen
{ int GetNextNumber();
}
Notes:
The public keyword is not needed (or even allowed) on the GetNextNumber() method. An interface declares access methods so by default they must be public. A private method in an interface makes no sense...and causes an error.
An Interface cannot contain fields. Doing so causes an error.
Hmmm, it seems an Interface is a collection of empty functions that are implicitly public.
Derive some Classes from the Interface:
Here are two Random Number Generators each inheriting from our Interface.
class RandomNumberCoinFlip : IRandomNumberGen
{ public int GetNextNumber()
{ // flip a coin for each bit of the number
return 1;
}
private String CoinType; // penny, nickel, dime, etc.
}
class RandomNumberOuija : IRandomNumberGen
{ public int GetNextNumber()
{ // Use a Ouija board to get a number
return 2;
}
}
Notes:
Both classes implement the GetNextNumber() function. One class has an additional field…but that's OK; it doesn't matter:
As long as a class implements the functions in the Interface, it can do anything else it pleases. But a class derived from an Interface must implement the functions in the Interface.
So big deal, what have we accomplished?
Here are the Classes in Use:
protected void Button1_Click(object sender, EventArgs e)
{ IRandomNumberGen Generator;
Generator = new RandomNumberCoinFlip();
Response.Write(Generator.GetNextNumber() + "<br />");
Generator = new RandomNumberOuija();
Response.Write(Generator.GetNextNumber() + "<br />");
}
Notes:
The Generator reference can be assigned to any object created from a class derived from the IRandomNumberGen Interface and it can call the GetNextNumber() method. It doesn't know or care about any part of the class except the methods it expects to be there.
Here’s another usage example:
public void MakeAMove(IRandomNumberGen NumberGenerator)
{ int Number = NumberGenerator.GetNextNumber();
// do something with Random Number
}
protected void Button1_Click(object sender, EventArgs e)
{ MakeAMove(new RandomNumberCoinFlip());
MakeAMove(new RandomNumberOuija());
}
Notes:
This shows a function that takes an Interface as a parameter. Any object derived from the Interface can be passed to the function.
That's cool but the same thing could be accomplished with an abstract base class and virtual functions. So what's the deal with Interfaces?
Multiple-Inheritance is not Supported in .Net….Except for Interfaces!
Here is one more class that implements the Interface. In addition to IRandomNumberGen, it implements IDisposable.
class RandomNumberDeckOfCards : IRandomNumberGen, IDisposable
{ public int GetNextNumber()
{ // Shuffle deck, pick a card
return 3;
}
public void Dispose()
{ // free up deck
}
}
And here it is being used:
protected void Button1_Click(object sender, EventArgs e)
{ IRandomNumberGen Generator;
Generator = new RandomNumberDeckOfCards();
Response.Write(Generator.GetNextNumber() + "<br />");
IDisposable Disposer = Generator as IDisposable;
Disposer.Dispose();
}
Notes:
As before, an IRandomNumberGen reference can be assigned to the object and the GetNextNumber() method called.
In addition, an IDisposable reference can be assigned (with a cast) to the object since it implements IDisposable and the Dispose() method can be called.
In the above code, the two Interface references, Generator and Disposer, both point to the same object. They have different 'views' of the same object. And that, is the deal with interfaces.
Finale:
I know there are thousands of articles around explaining this concept which is odd because once understood, the concept is trivial. But sometimes one explanation "fits the brain" better than another explanation. I hope this explanation fits someone's brain.
Steve Wellens
Over on the Asp.Net forums I recently had the opportunity* to help a few lost souls by showing them how to serialize objects to XML and deserialize the XML back into objects. Since the question has come up more than once, I decided to BLOG it so I could refer similar questions in the future to this post.
*I use the word opportunity because by helping others I am forced to think hard about the technology and to think even harder about how to communicate the technology. It makes me better at what I do. All right then, enough after-school-special-feel-good-about-yourself-I'm-ok-you're-ok fluffy nonsense… on with the code:
Here is a simple class I'm going to work with. It has both properties and fields:
public class MyClass
{ // old school property
private int _Age;
public int Age
{ get { return _Age; } set { _Age = value; } }
// new school property
public bool Citizen { get; set; }
// there's nothing wrong with using fields
public string Name;
}
Here are the two functions to Serialize and Deserialize an object:
/// ---- SerializeAnObject -----------------------------
/// <summary>
/// Serializes an object to an XML string
/// </summary>
/// <param name="AnObject">The Object to serialize</param>
/// <returns>XML string</returns>
public static string SerializeAnObject(object AnObject)
{ XmlDocument XmlDoc = new XmlDocument();
XmlSerializer Xml_Serializer = new XmlSerializer(AnObject.GetType());
MemoryStream MemStream = new MemoryStream();
try
{ Xml_Serializer.Serialize(MemStream, AnObject);
MemStream.Position = 0;
XmlDoc.Load(MemStream);
return XmlDoc.InnerXml;
}
finally
{ MemStream.Close();
}
}
/// ---- DeSerializeAnObject ------------------------------
/// <summary>
/// DeSerialize an object
/// </summary>
/// <param name="XmlOfAnObject">The XML string</param>
/// <param name="ObjectType">The type of object</param>
/// <returns>A deserialized object...must be cast to correct type</returns>
public static Object DeSerializeAnObject(string XmlOfAnObject, Type ObjectType)
{ StringReader StrReader = new StringReader(XmlOfAnObject);
XmlSerializer Xml_Serializer = new XmlSerializer(ObjectType);
XmlTextReader XmlReader = new XmlTextReader(StrReader);
try
{ Object AnObject = Xml_Serializer.Deserialize(XmlReader);
return AnObject;
}
finally
{ XmlReader.Close();
StrReader.Close();
}
}
Here is some sample code showing how to use the functions.
Note: I keep these functions (and other functions) in a class I call MiscUtilities. You will have to modify the code…depending on where you place the functions.
protected void Button1_Click(object sender, EventArgs e)
{ // create and initialize an object
MyClass Test = new MyClass();
Test.Age = 18;
Test.Name = "Rocky Balboa";
Test.Citizen = true;
// Serialize it
String XML;
XML = MiscUtilities.SerializeAnObject(Test);
// Deserialize it
MyClass Test2;
Test2 = MiscUtilities.DeSerializeAnObject(XML, typeof(MyClass)) as MyClass;
// TODO: Get a cup of coffee and bask in the glory of rock solid code.
}
Here is what the XML string looks like (after formatting):
<?xml version="1.0"?>
<MyClass xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Name>Rocky Balboa</Name>
<Age>18</Age>
<Citizen>true</Citizen>
</MyClass>
There are limitations: XmlSerializer does not serialize private fields, methods, indexers or read-only fields.
Once you have the XML string, you can email it, store it in a database, save it to disk, or…print a copy of it and have your mom tape it to the refrigerator next to the turkey picture you made in the second grade by tracing around your hand with a Crayola crayon.
I hope someone finds this useful.
Sometimes you want your web page to 'stay alive'. That is, if a user is filling out a complicated form, you do not want the session to time out before they are finished. The user could get very angry and rightfully so: You might even get yelled at!
It's not simply a matter of increasing the session timeout to a very large value. If you do that, the sessions would be left active in the server memory for hours—long after the visitors have left the site. Increasing the session timeout IS a solution… but not necessarily a good solution.
The goal is that the session should stay active as long as the web page is open on the client machine …even if there are no post backs to reset the session timer. When the web page is closed, the session should time out normally.
I implemented a solution for this: The client will "ping" the server at intervals of less than the session timeout which will reset the session timer. This is known as the Heartbeat design pattern (I couldn't find a decent site/page to link to).
Miscellaneous Setup Stuff:
For testing purposes, I set the Session Timeout to two minutes in web.config:
<system.web>
<sessionState timeout="2">
</sessionState>
To trace what is happening, I used a utility function called ODS (it's in a class called MiscUtilities):
/// ---- ODS ---------------------------------------
/// <summary>
/// Output Debug String with time stamp.
/// </summary>
public static void ODS(string Msg)
{ String Out = String.Format("{0} {1}", DateTime.Now.ToString("hh:mm:ss.ff"), Msg); System.Diagnostics.Debug.WriteLine(Out);
}
To watch the Session State events, I added debugging strings to the global.asax file:
<%@ Application Language="C#" %>
<script RunAt="server">
void Application_Start(object sender, EventArgs e)
{ MiscUtilities.ODS("****ApplicationStart"); }
void Session_Start(object sender, EventArgs e)
{ MiscUtilities.ODS("Session_Start"); }
void Session_End(object sender, EventArgs e)
{ MiscUtilities.ODS("Session_End"); }
Here are the details:
We need a method at the server for the client to call. We use a WebMethod.
- There must be a ScriptManager on the page.
- The ScriptManager must have EnablePageMethods set to true.
- The WebMethod must be public and static.
- The WebMethod must have the EnableSession attribute set to true.
<asp:ScriptManager ID="ScriptManager1" runat="server"
EnablePageMethods="true">
</asp:ScriptManager>
public partial class _Default : System.Web.UI.Page
{ [WebMethod(EnableSession=true ) ]
public static void PokePage()
{ // called by client to refresh session
MiscUtilities.ODS("Server: I am poked"); }
We need JavaScript at the client to call the server function at fixed intervals:
<script type="text/javascript">
var HeartBeatTimer;
function StartHeartBeat()
{ // pulse every 10 seconds
if (HeartBeatTimer == null)
HeartBeatTimer = setInterval("HeartBeat()", 1000 * 10); }
function HeartBeat()
{ // note: ScriptManger must have: EnablePageMethods="true"
Sys.Debug.trace("Client: Poke Server"); PageMethods.PokePage();
}
<body id="MyBody" onload="StartHeartBeat();">
Here is what the output looks like without the heartbeat:
10:22:43.03 ****ApplicationStart
10:22:45.13 Session_Start
10:25:00.00 Session_End
Here is the output with the heartbeat:
10:26:06.10 ****ApplicationStart
10:26:08.05 Session_Start
Client: Poke Server
10:26:18.93 Server: I am poked
Client: Poke Server
10:26:28.95 Server: I am poked
Client: Poke Server
10:26:38.96 Server: I am poked
Client: Poke Server
10:26:48.98 Server: I am poked
. . . (lines deleted)
Client: Poke Server
10:29:59.45 Server: I am poked
Client: Poke Server
10:30:09.47 Server: I am poked
Client: Poke Server
10:30:19.48 Server: I am poked
. . . (lines deleted)
It looks like the session is staying alive while the client is idle: Excellent!
I hope someone finds this useful.
Steve Wellens
More Posts
Next page »