Who wants a WinForms trick?! If you're not running around, screaming at the top of your lungs "I DO! I DO!", then I don't know if I want you on this website.
Anyway, this one is an oldie but a goodie. How do you validate a Windows Form on the fly in C# (or VB.NET, for that matter)? Let's say you have a form with one text field and an OK button. When the user clicks the OK button, you want to validate that text field to see that it's at least 5 characters in length. How would you handle that validation?
For slightly complicated validations, you can use the Validating events for your controls, along with the ErrorProvider on your form. There are lots of places that tell you how to do that. However, if you just want a quick and dirty validation, you can do it simply by manipulating your OK button's DialogResult setting.
Here's what the event handler for your OK button would look like:
Simple, and definitely not something you'd want for anything but a trivial example.
I hope to post something really cool a little later this week. I've been working on a personal app in my spare time and I've got to think I'm close to my first release. I've GOT to think that, or else I'm setting fire to my computer desk. More details as they emerge.
Recently, I got into a conversation with a colleague at work about the benefits of designing in UML. I was in favor of using the modelling language, to the point where I thought all we needed in our design documents was a couple of UML diagrams (class and sequence). He took the other extreme, saying that UML was unnecessary complexity and that we'd all be better served by simply describing our design in paragraphs of text or flowcharts. The debate raged on for days, and to make sure I actually knew what I was talking about (a rare occurrence), I made a list of pro's and con's for extensive use of UML.
PRO
1. There's no room for interpretation on a diagram. Five people could write five different textual descriptions or draw five different flowcharts of a class, but with a diagramming standard, all of their diagrams will be consistent.
2. It's the industry-standard method of describing a design. If a company were to bring in a consultant or experienced employee to implement a design later on, it'd be much easier for this individual to process standard UML than several pages worth of text/inconsistent charts.
3. The diagram minimizes complexity. It may take several hundred words to fully describe a class in text, but all of that can be summarized with a single picture. A picture is worth a thousand words, as the kids say.
4. It's a lot easier to see and apply design patterns through UML. I'm a big fan of design patterns, largely because whenever I try to design something, it takes me several tries to get it right. With patterns, I can start much closer to that right position than I normally do. It's much easier to see where these patterns apply when you can easily view the structure of an object or object relationship.
CON
1. UML is daunting at first glance. If you're handed a class diagram without any knowledge of UML, it'll take a long time to parse the diamonds and arrows.
2. UML is expensive. It takes both time and money to learn it. For me, it wasn't a whole lot of either, but that may not be the case for everyone.
3. It's easy to go UML overboard, and find yourself creating dozens of diagrams.
Having created that list, I don't really think that con's #1 and #2 are true disadvantages; after all, it's our job to learn what's new and apply it accordingly. If you operate like that, those two disappear faster than an unguarded cheesecake at Bruce Vilanch's house. That leaves numero tres, which to me, isn't as much a disadvantage as it is a potential pitfall. That is to say, there's nothing about UML that forces you to use it all over the place; that's just one way people can apply it. If you know that, you can apply your modelling with some discipline so that you only diagram exactly what's needed.
Of course, I've consumed the UML kool-aid, so this list may not apply for everyone. Maybe it's a good starting point for discussion, however. And if it's not even that, well, I offer no apologies.
I spent some time this weekend using Python's DB API. Boy, have I ever been spoiled. Using Python's DB API is kind of like going into a restaurant and ordering a cherry pie, only for the waitress to return to your table with a barrel of cherries and some frozen pie crust. It's a little rough around the edges, that's all I'm saying. I first realized this after I successfully ran my first query and tried to view a few columns. I learned then that it's impossible to refer to the fields in your result by field name. Instead, you have to refer to the field column order in the query (ie, field[5]). Clearly, that ain't gonna cut the mustard.
So, since I had nothing better to do, I put together a simple way of allowing the user to access these fields. I did it by making the result a list of dictionaries instead of a tuple.
Here's the code!
def SelectQuery(queryStr):
if (queryStr.find("*") > -1):
print "Error: you cannot select *, you must specify the field names."
exit(1)
try:
#we make the string lower case, in order to make our string comparsion easier.
queryStr = queryStr.lower()
#connect to db and run query
db = MySQLdb.connect(host="localhost",user="user",passwd="pass",db="db")
cursor=db.cursor()
cursor.execute(queryStr)
#return all rows.
allRows = cursor.fetchall()
cursor.close()
db.close()
#call our helper functions
return ResultsIntoDictList(allRows, queryStr)
except MySQLdb.Error, e:
print "Error: %s" % e
exit(1)
def FieldsFromQuery(queryStr):
selectLoc = queryStr.find("select ")
fromLoc = queryStr.find(" from ")
#if we didn't find one of those terms, it's a problem
if (selectLoc < 0 or fromLoc < 0):
print "Error: didn't find select or from in the query."
exit(1)
#our fields are strung together by commas, so we split that into a list
fieldList = queryStr[selectLoc + len("select "):fromLoc].split(",")
for i in range(len(fieldList)):
fieldList[i] = fieldList[i].strip()
return fieldList
def ResultsIntoDictList(allRows, queryStr):
rowList = []
fieldList = FieldsFromQuery(queryStr)
#iterate through all the rows
for row in allRows:
#create a new dictionary
rowDict = {}
#populate that dictionary according to field names
for i in range(len(row)):
rowDict[fieldList[i]] = row[i]
#append dictionary to list
rowList.append(rowDict)
return rowList
(Partway through doing this, I learned such information could be gleaned easily from cursor.description. I share this code in case it ever comes in handy for anyone ever.)
Recently, I've been going through a transition at work, as I go from a pure development role to a project manager/development role. When I was first presented with the opportunity, I was gung ho. "Hell yeah, I'll do it," I said, "software is software, and the more I'm involved, the better the end product will be." I say a lot of idiotic things in the course of a day. They range from the mildly moronic (I wish someone made chocolate toothpaste) to the nearly braindead (I'm going to put a leash on the cat and walk her around the neighborhood). I think I may need a new classification for my initial statements about project management. Perhaps there's some level of stupidity somewhere, maybe a "Paris Hilton discussing quantum mechanics" level, that could house my comments because they were that absurd. Allow me to explain why.
I have an analogy. Assume you're a great cook, and that people come from miles around to indulge in your mango chutney. Now assume that your superiors discover this, and they come to you and say, "Listen, you've proven yourself to be competent when it comes to making food and you seem to have a pretty good head on your shoulders; we'd like you to consider being a farmer. If you can make the food, you can make the ingredients." Now that'd be a strange conversation. However, moving from development to project management is very similar. In development, your focus is on the final product; in project management, your focus is on the ingredients that go into the final product. It's a completely different mind-set.
Back to the farmer thing. If you're a farmer, you hold very little influence over your crops. There's nothing you can do directly to make a carrot grow faster or more enjoyable to eat; you personally can't improve the process of photosynthesis. All you can control is the surroundings: give it good soil and plenty of water, and keep the insects away. Once that's been set, hopefully the carrot can grow.
I've only been doing this for a few weeks now, but I've come to discover that's the way project management works. If you're unhappy with the code or documentation coming from the developer, you can't just throw yourself in there and say, "Let me fix that for you!" Coming from development, that's a huge temptation. Instead, you have to tweak the surroundings, like your design process or the amount of training that developer's received in that area.
Development is hands-on; the most important phrase is, "I can do that." Project management is hands-off; the most important phrase is "How can I get you to do that?" It's not solving problems as much as it is getting people into positition to solve problems. It's taken me a while to grasp this, but I think I'm beginning to come around.