September 2003 - Posts

• Weekend Coding Work Stuff [or] Still Inheriting

  I'm going through the Rocky and Bullwinkle complete first season on DVD so I'm thinking every title needs to have two options... As I mentioned a couple of times, I've been a full-time teleworker for over 3 years now.  One of the affects of being a telecoder is that the line between coding work stuff and coding personally gratifying stuff is blurred and dang near non-existent.  That's not a problem if the work stuff is gratifying and an ongoing learning process.  But I learned a long time ago that no matter how much “work stuff” you do after-hours that there is always more of it to do and that you need an acknowledged differentiation between work and personal coding time.  One way to do that is to spend after-hours on non-work projects, like for non-profits or something.  I did that for a while, but am back to focusing on work projects after hours.  Another way to acheive that differentiation when the focus is on work projects is to move into new .NET territory which, while it may add time to the app's completion, the differentiation is achieved because of the newness of the territory explored during those after-hour sessions.  Plus, the company benefits from the expanded skillset for future projects, so everybody wins. Last weekend was more “differentiated” than this weekend now past, as I was spending time in getting a handle on and applying inheritance to a base set of existing app classes for a modified version of the app.  This weekend was more output-focused, which is never a good starting point for differentiated after-hours coding.  But I was able to build on my past week's foray into inheritance.  In so doing, I recognized the need to employ inheritance in an initial (i.e. base) object rather than after-the-fact for a modified version later.  With this in mind a control which used a commonly used dropdownlist with an OnSelectedIndexChanged to do something (with that something being different based on its context), became a base control class.  An inherited class essentially started where the base control left off, with the method called from the OnSelectedIndexChanged (not the OnSelectedIndexChanged method itself.)  Any future controls using this common dropdownlist and OnSelectedIndexChanged approach will get a similarly inherited boost. So the output-focused weekend of work stuff turned out alright because I knew I was moving forward, doing it better than last weekend.   Posted Sep 29 2003, 12:15 AM by daveburke with no comments Filed under: .Net General

• Determining order of intellisense overloaded methods

  I decided a few days ago I was going to streamline my DropDownList code, so I created a class to hold DoDropDown method variants.  Essentially its gives me a one-line call to handle the complete dropdown setup and binding process.  It uses SqlHelper and other classes unique to my app, and I find it a big timesaver.  In using it over there weekend I realized I didn't like the order of the intellisense list, since the first options were not my most used method choices.  I changed the order of the overloaded methods in the class by my use preference and sure enough they appeared in intellisense that way. Sweet.   Posted Sep 28 2003, 11:27 PM by daveburke with 2 comment(s) Filed under: .Net General

• Coding With a With in C# (sounds like I'm lithping, doesn't it?)

  I've been coding in C# for, oh, a good year now, but I started my .NET journey in VB.  There are things I miss from VB, but one thing I definitely miss is the WITH statement, as in with DropDown  .DataSource = dt.defaultview  .DataValueField = "id"  .DataTextField = "desc"  .DataBind() end with “And that's all I've got to say about that.” -- Forest Gump Posted Sep 26 2003, 09:57 PM by daveburke with 5 comment(s) Filed under: .Net General

• To W2K3 : Sites starting to move

  My network admin and I made the final switch-over of two production sites and backend SQL databases to our new W2K3 server yesterday.  There were scheduled jobs and other sites on the network which talked to either the IIS sites or to the SQL databases or to both, so it wasn't a completely simple affair.  I tested and documented and was ready for any contingency.   Within 30 minutes we were rockin' on the new server and all users were being routed to the new server by a change on the SonicWall firewall.   I repeated all of my tests and everything was looking pretty.  My network admin was happy and went to Blimpies to enjoy the Thursday $4.95 special.  I stayed to keep testing just to be sure, cause I'm like that.  After about an hour I got a call from my net admin saying that users were getting .NET runtime errors which listed a database login error.  That couldn't be!  There was no reason for it!  There were also incidents of 404s on pages I had successfully tested both prior and after the migration.  Fortunately this state of panic lasted only a few minutes, because Mr. ISA, the butt blaster he is, stopped by to say, "Remember me??????"  My [sent-directly-from-heaven] network admin quickly deduced that ISA Server was hanging on to the old IPs which he had updated on the SonicWall.  Why both he and I didn't encounter any errors in our testing and others did continues to baffle me.  It was agonizing though, since its the job of every developer to peform his or her work invisible to the user.   This time is was almost, but no cigar.  So when we move the next site, we add a reboot of ISA Server to the procedure.   Posted Sep 26 2003, 09:52 PM by daveburke with no comments Filed under: .Net General

• Hit delete key if the KISS principle is not evident

  I'm continuously impressed by how the decisions we make in the course of building an application are so permanent.  They seem so permanent because they're so dang hard to change once put into play.  Whether its the naming of variables, files or components, field names in a table, SQL schema, or--heaven help us--the consequences of flawed or needlessly complex logic.  A couple of nights ago I wanted to move ahead with an asp.net app I'm working on, but instead knew that I had to deal with a SQL logic design flaw I put into play early in the day and had been coding against throughout that day.   I came to the conclusion that I had no choice but to delete and re-write a bunch of code because the SQL logic I came up with was unnecessarily complex.  I have a crazy scientist, ex-Marine neighbor with several U.S. patents to his name in engineering who often likes to say, "The first rule in engineering is: Keep it SIMPLE."  He is soooo right.  When I have to think too much to adhere to some logic I've come up and trying to code against, then maybe that logic is flawed.  And before its too late and I have to live with it forever, I do not fear the delete key.  Posted Sep 26 2003, 09:46 PM by daveburke with no comments Filed under: .Net General

• Keeping an eye on the Output Build window

  Whenever I compile my ASP.NET apps I watch the output window very closely, and whenever I see a line that seems longer than the others, even if its a successful compile, I go back and check it out, usually making changes to get rid of it.  Those "longer lines" are always of benefit to me.  Usually they'll mention "unreachable code" or "variable declared but not used" or something, but in my move into inheritance this week I found the most excellent "long line" listed below.  Wow!  Talk about instructive!  Seriously. \\cutter\vsnet\proj\proj.WebUI\Controls\ClientReqsHeading.cs(25): 'proj.WebUI.Controls.ClientReqsHeading.Page_Load(object, System.EventArgs)' hides inherited member 'proj.WebUI.Controls.TextLinksHeading.Page_Load(object, System.EventArgs)'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword. Posted Sep 26 2003, 09:38 PM by daveburke with 2 comment(s) Filed under: .Net General

• Inherisense

  When Sam Gentile spoke at last month's VTDotNet Users Group meeting he used TextPad as his editor and made a great joke about people in the room suffering from “intellisense withdrawal.”  I have to admit that I am an Intellisense JUNKIE and can't get enough of it.  It is part of my thinking process when naming variables, trying to avoid duplication to avoid less typing before my selection appears in the intellisense popup. I was so impressed to see intellisense spring into action even when I was declaring a base class as shown in the pic below.  Intellisense everywhere! (including .ascx and .aspx files please....) Posted Sep 26 2003, 09:32 PM by daveburke with no comments Filed under: .Net General

• First inheritance-based app online

  This has been a great week with great latenight coding sessions, which began with last Friday's session where I began working with System.Reflection and inheritance.  The app resulting from those latenight sessions (and some bonafide daytime work hours as well) is online and swingin'. What brought me to inheritance was an asp.net app consisting of 5 rather detailed usercontrols which needed to be duplicated to support a different backend and slightly different functionality.  The page controls consisted of a heading title bar with 5 menu options displaying administrative forms on the page to manipulate data in other page controls.  I swore to myself I was not going to go the straight cut-n-paste route when I had seen too many great sessions on inheritance in Julie's Vermont DotNet Users Group by guys like Chris Kinsman and Carl Franklin. Now I'm coco for cocoa puffs and hooked on inheritance!  The original app and its 5 usercontrols all served as base classes to those of the modified, inherited app.  I've got specific observations and a number of questions, but here I simply wanted to post an image of two classes side by side.  At left is the inherited class where the only code requiring modification was the Page_Load method.  At right is the class from the original application serving as the base class.  To me this is an effective depiction of the benefits of inheritance, for sure.   Posted Sep 26 2003, 08:50 PM by daveburke with no comments Filed under: .Net General

• Cooktop XML Editor Solicitation

  I played with the Cooktop XML Editor for a bit last and I applaud the author or authors, but I just didn't get it.  I didn't find it intuitive or easy to get my head around at all.  After 30 minutes of trying to open an XML file and its associated schema I gave up.  Control Panel-->Settings-->Add/Remove programs.  See ya!  I don't know why I went out cruising for a quick XML Editor romp last night anyway.  It was late, I was listening to a Smooth Jazz stream at the time, was feeling a bit vulnerable...oh, I had a hundred good reasons at the time.  But I remain of the opinion that to learn XML that you should roll your own test, validate, transform and query environment. You build it, live with it, grow with it.  Yes, life is a-okay! Posted Sep 24 2003, 08:23 PM by daveburke with 2 comment(s) Filed under: .Net General

• Multiline Textboxes make for happy XmlTextWriter results

  This is not what I wanted to be spending the majority of my late-night coding session on tonight, but here we are:  Tonight's lesson:  If you want to display the results of an XML file straight-up with indentations and format you are accustomed to simply and quickly, do NOT display it in a label control.  Send it instead to a multi-line Textbox. I got sidetracked into updating an XPath test page I use in the course of coding, based on one of many good code examples in Wrox's Professional ASP.NET XML with C#.  I last wrote on this in a June post. At bottom is the comparison between displaying the XML file in a textbox (at left in white) and a label (in pink).  I anticipate someone telling me I missed some label attribute or perhaps should have used encoding of some kind, which I would of course welcome.  Here's the code for a quick display of the XML file. string _XmlDocPath =Server.MapPath(Request.ApplicationPath + "/xml/" + txtFilename.Text); StringWriter sw = new StringWriter(); XmlTextWriter writer = new XmlTextWriter(sw); writer.Formatting = Formatting.Indented; writer.Indentation = 4; XmlDocument doc = new XmlDocument(); doc.Load(_XmlDocPath); doc.WriteTo(writer); txtResults.Text = sw.ToString();  SubSelectLabel.Text = sw.ToString();     Posted Sep 24 2003, 01:25 AM by daveburke with 3 comment(s) Filed under: .Net General