The missing OnEnterKeyPress event in ASP.NET
Posted: Wednesday, March 07, 2007 - 2:45:04 PM
There's no OnEnterKeyPress event in ASP.NET by default. One way around this is using JavaScript. Add this code to your markup (I like to put it inside my <head> tag):
<script language="javascript">
function EnterKeyPress(button)
{
if (event.keyCode == 13)
{
event.returnValue = false;
event.cancel = true;
button.click();
}
}
</script>
Assuming your submit button is called btnSubmit, you next add the following item to your textbox tag, e.g.:
<asp:TextBox id="txtSearch" runat="server" MaxLength="50" onKeyDown="EnterKeyPress(btnSubmit)" />
Now when your user hits the enter key after entering their text, the button click event will fire.
-Josh
Comments(0)
Passing events from child controls
Posted: Friday, February 09, 2007 - 3:05:20 PM
One of my developers asked me about using an event to notify the parent (page, user control, etc.) when a child control does something. This is easy with a custom event.
// This is the class for the page
public class Default : System.Web.UI.Page
{
// Let's call our user control ChildControl
protected WebControl ChildControl;
// ...
// When the button on the user control is clicked,
// tell the parent to do something, like print the
// user control's type.
//
// In C# 2.0, you'll want to add this event to the control
// from the page markup (just like any other event, like OnTextChanged or OnClick).
// It will look like this:
// OnChildEvent="ChildControl_ChildEvent"
// It C# 1.1, you'll need to add this to the InitializeComponent method:
// this.ChildControl.ChildEvent +=
// new System.EventHandler(this.ChildControl_ChildEvent);
private void ChildControl_ChildEvent(object sender, EventArgs e)
{
Response.Write("btnSubmit fired from the child control.");
}
}
// This is the class for the user control.
public class ChildControl : System.Web.UI.UserControl
{
// Declare the event
public event EventHandler ChildEvent;
// ...
// Invoke the event
// This is called whenever the button is clicked
protected void OnChildEvent(EventArgs e)
{
if(ChildEvent!=null) ChildEvent(this, e);
}
private void btnSubmit_Click(object sender, EventArgs e)
{
OnChildEvent(e); // Float the event up to the parent
}
}
-Josh
Comments(0)
Interviews, Part 2
Posted: Tuesday, January 02, 2007 - 6:38:47 PM
For my beloved critics:
Maybe I went too far with the Fibonacci thing...nah.
In any event, the point I was trying to make was that it seems I get a lot of people through my office that can't write a simple function in ANY language. If someone walks through my door and is a great problem solver, that's fantastic. My auto mechanic is a great problem solver, too. That doesn't mean he can code well.
You have to be able to do both. I think Joel Spolsky had the best take on this.
-Josh
Comments(0)
My Microsoft Vista Experience
Posted: Tuesday, December 19, 2006 - 1:33:38 PM
A few weeks ago I installed the Microsoft Vista RTM build. So far it's been a fun ride. Here's some of the things I've learned:
- Visual Studio 2003 isn't supported. It works most of the time if you disable UAC (Control Panel > User Accounts > Turn User Account Control on or off). I did notice that none of my .NET 1.1 web projects that used the Microsoft Enterprise Library worked. Hurray for virtual machines!
- Speaking of virtual machines, the Virtual PC 2007 Beta has a ways to go. It didn't play nice with my Vista install. I gave up and used VMware Workstation. Though the current 5.5.3 build isn't officially supported by Vista, I've had no problems with it.
- Visual Studio 2005 requires a beta service pack.
- SQL Server 2005 requires a beta service pack, too...
- Microsoft has tons of free webinars on Vista.
- I won a Microsoft Zune at one of them. Too bad the Zune software doesn't work on Vista...
- Gadgets are easy to create, but I'm still not sure how we can make money off of them.
- I need a new laptop. Maybe Santa will bring me one. Last year this guy stole all my presents.
I'm on vacation for the next couple of weeks. Look for my upcoming article on Vista gadgets. I'll post sample code as well.
Comments(0)
Interviews, Part 1
Posted: Monday, November 27, 2006 - 4:55:56 PM
Maybe it is just me, but I think anyone who applies for a programming job should be able to:
- Write an algorithm to calculate Fibonacci numbers from memory (it's just too classic a question).
- Sort an array...and when I say sort I don't mean array.Sort(). Write the method.
- Write a simple, multi-threaded desktop application. If you don't know what a thread is you're not going to make it in the age of multi-core processors.
- Parse a string.
- Reverse a string.
- Hash a string.
- Tell me why ad-hoc SQL queries are bad.
- Know that // is for comments. Comments? Who writes those?!?!?
I know some of this sounds overly simple. You wouldn't believe how many times I've sat across from someone who just stared at me blankly, shook their head, or simply walked out. If you can't do the basics, don't bother. I want people who challenge
me in an interview, not the other way around.
Which leads me to this: We're hiring. My team is tackling some really large projects in the new year and we need some fresh talent. Check out our
job listings and then give me a call.
-Josh
Comments(5)
Generating a Random Password
Posted: Friday, November 03, 2006 - 10:04:45 AM
This is the first of many useful utilities we include in our applications that just work.
// Creates a randomly-generated, alphanumeric password
public static string GeneratePassword(int passwordLength)
{
string password = String.Empty;
Random random = new Random();
// You can include symbols if you want
string validCharacters = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
char[] c = validCharacters.ToCharArray();
for (int i = 0; i < passwordLength; i++)
password = String.Concat(password, c[Convert.ToInt32((c.Length - 1) * random.NextDouble())].ToString());
return password;
}
-Josh
Comments(1)
Bad Waterfall, Bad
Posted: Friday, November 03, 2006 - 10:01:10 AM
Scenario:
One company you're in talks with says that they can put analysts in your offices for two months. They tell you that they can consolidate all of your business processes into one grand document that they'll pass to their software developers. To you, they'll provide a timeline and a fixed budget. You'll feel like you're mitigating risk by finding a company that agrees to a fixed scope, timeline, and budget. And if you sign off on that contract, you'll find out later that you've just become the victim of a bait and switch.
Why? There are two main reasons. First, most small to medium-sized companies (SMBs) don't have a good portion of their business processes documented. I can understand why. Business is an ever-swirling limbo of chaos. Change occurs daily. Those who are unwilling to make changes and adjust to market whims are taken down. You either evolve or you perish.
Second, your need for adaptability violates the software project trilemma: Flexible scope, fixed budget, fixed timeline.pick two. This is an inviolable law of project management. If you need a fixed budget and a fixed timeline, you can't adjust the scope of the project.
Therein lays the rub. Companies like this tell you that they can deliver what you want in a fixed timeframe and budget. What they don't tell you is that if you want to make a change to the system or find that their interpretation of the system didn't match the vision in your head, it will cost you time and money. Ask this company what happens if they interpret the specs correctly but it doesn't match your vision. Ask this company what happens if you need to make even a small change to the way something works. If they tell you that those changes are included in the price, get it in writing. In blood.
This company is trying to sell you on a waterfall methodology: Do all the analysis up front, set up a fixed timeline and budget, design, design, develop, test and deploy. Where does it mention add a feature? Where does it mention the ability to change your mind mid process? The amount of energy it takes to move up a waterfall is immensely greater than it takes to move down one. The cost of change in a waterfall methodology uses the exact same principle.
Waterfall works well when there's a fixed scope and you can easily identify your requirements accurately at the beginning of the project. The two biggest drawbacks to the waterfall methodology are process paralysis and inflexibility. Process paralysis is characterized by the following:
1. Lengthy meetings where everyone tries to establish unanimity about things they may not yet understand.
2. Inability to proceed until everyone has signed off on a monolithic plan.
3. Rigidity in the face of changing market circumstances.
The inflexibility comes into play when you ask for a change. Since developers on the waterfall methodology don't tend to develop scalability in their designs, any change, however small, requires an immense amount of rework. You tend to get everything you asked for but not exactly what you wanted. And if what you wanted wasn't adequately described in the specification, guess what? You're going to pay for it.
Again, make sure you read the fine print.
-Josh
Comments(0)
1st Post!
Posted: Friday, November 03, 2006 - 10:00:00 AM
Hello readers and welcome to my new blog!
My plan is to share with you my thoughts on software development and data modeling along with some useful code snippets and examples. I'm also an avid follower of technology news, so when I find an interesting piece of information I'll share it with you here. I want this to be an open forum, so feel free to post comments and ask questions.
Today I want to talk about what I call the Software Project Trilemma. When a customer comes to me wanting a new application, they aren't sure what exactly they want us to build. They do know, however, that they need it done cheap and they want it yesterday. You may look at this and go, "Josh, that's the fast, cheap, good principle." I look at it like this:
Flexible Scope, Fixed Timeline, Fixed Budget. Pick Two.
What does this mean for software projects? Well, if a customer wants something done within a set timeframe and for a set amount of money, I have to be the bad guy when they come back to me and say "I want to change the way this works (and I don't want to pay for it or put my end date in jeopardy)." Can't do it...out of scope...wasn't agreed upon in the spec...does this sound familiar?
If the Software Project Trilemma is universal, how do you mitigate the customer's desires in an agile shop? I'm working on an answer, but please feel free to share your thoughts.
-Josh
Comments(0)