My Life and Code

Here's another example of behavioral differences between IE and Firefox. I ran into this one about a month ago and then again this morning. I currently have some webpages where I'm dynamically displaying and hiding controls. This is done via JavaScript/DOM by setting the style.display property of the control I wish to hide or display. To hide a control, setting this property to none does the trick, but to display it, there's a way that works only in IE, and a way that works for both IE and Firefox -- which would be the correct way of doing it. In IE, setting the style.display property to block will re-display the control after it has been hidden, and will display it correctly. But in Firefox, doing this will display the control again but in a different way -- for example, the height of the control as it was before it was hidden is no longer maintained. The correct way of doing this is to set the style.display property to an empty string. Apparently, this is the ...

Even though I've been using Firefox a lot more than IE lately (especially with the speediness of Firefox 3.5), I finally made Firefox my default browser today to assist in doing more proper (i.e. standards-friendly) web development. Firefox is stricter when it comes to standards, whereas IE is more like the parent that lets you stay up past your bedtime or eat junk food after brushing your teeth -- it's lenient and more flexible -- but this isn't a good thing. Anyway, my decision to make Firefox the default browser was justified today when I encountered an issue with z-indexes: certain elements were appearing underneath others, and even though I set the z-index of these elements, there was no change. Then I realized that it worked in IE -- because IE is lenient. According to the CSS spec, z-index only applies to positioned elements (i.e. those whose position property has a value other than static). IE was lenient with this, but Firefox was not -- it was requiring the positi...

Here's a quick fix to a problem I ran into today: I have a UserControl in .NET which includes a HiddenField control. I use a JavaScript function to modify the value of the control (getting the control with document.getElementById() and passing in the ClientID of the HiddenField control), and then make use of the value later in my server side code during postbacks. The problem I ran into was that the value wasn't being persisted -- however, it used to work. I realized that because I had moved the code that made use of this value into the Page_Init event handler a short time earlier, this had broken the functionality. I moved it to Page_Init because I'm doing dynamic control creation, and I've read in countless places that the preferred location for this is Page_Init. Moving this code back to Page_Load corrected the issue -- in the ASP.NET Page Lifecycle, the controls values have not been restored from ViewState during Page_Init.

Hopefully this will save someone a lot of time. Today I was working on a webpage in ASP.NET and made use of the LinkButton control. But when I applied a CSS class using the CssClass property, it just wouldn't take. After much searching, I found the solution. First off, this is a bug -- you can't spin it any other way. Fortunately, there IS a way to get it to work: you need to specify one of the following qualifiers on your CSS class: visited, link, or active . For example, when I tried to apply the following class, it wasn't reflected in the control: .Pager { font-family:Verdana; font-size:8pt; font-weight:bold; color:Orange; } However, when I added the link qualifier (":link" added to the class name), it worked like a charm: .Pager:link { font-family:Verdana; font-size:8pt; font-weight:bold; color:Orange; } When you apply the class name to the CssClass property of the control, leave out the qualifier . For example, using my class above, I set the valu...

The .NET Framework includes some convenient ways for tracing and debugging. In this post, I'll discuss how to easily add tracing functionality to your apps to output data to a text file. First, define a trace switch in your App.config file. This should be placed in the system.diagnostics node, and the point of the switch is to specify the level at which to output data with the switch. Here's an example: <system.diagnostics>   <!--   TRACE SWITCH VALUES   0 = Off   1 = Error   2 = Warning   3 = Info   4 = Verbose   -->   <switches>     <add name="MainTraceSwitch" value="4"/>   </switches> </system.diagnostics> There are five possible values: 0 = Off 1 = Error 2 = Warning 3 = Info 4 = Verbose So, if you set the value of your switch to 1, you're telling it that you only want to trace on errors. If you set it to 4, you're telling it to ...

I recently had to make some additions to a website I was working on which involved the addition of an AJAX UpdatePanel which would contain a GridView. The GridView would contain rows with information related to submissions we received by the user. A timer would ensure that the GridView would be updated in a timely fashion and reflect any updates in our database, but we also wanted to instantaneously update the GridView as soon as a new submission was received. Updating an UpdatePanel from JavaScript wasn't a problem, but the source of new submissions to the site was located within an IFRAME hosted on the page, not on the page itself. How could I update the UpdatePanel on the main page when the page inside the IFRAME was submitted? Turns out, it's no big deal. All you need to do is add code to the onload event of the IFRAME. This code will call the __doPostBack() JavaScript function that ASP.NET renders when you use the AJAX components. This function takes two parameter...

Yesterday I had written some code in C# to call a stored procedure in an Oracle database, and when I began testing this code today, I was surprised to get the following error whenever the code would attempt to execute the OracleCommand: ORA-01036: illegal variable name/number I was scratching my head. Why wasn't this working? I've done this before! From previous experience, I knew that the names of the procedure parameters must match exactly when you add them to the OracleCommand object . In other words, if your stored procedure is expecting two parameters, named email and phonenumber , your code should look something like this: cmd.Parameters.Add("email", OracleType.VarChar); cmd.Parameters.Add("phonenumber", OracleType.VarChar); cmd.Parameters["email"].Value = psEmail; cmd.Parameters["phonenumber"].Value = psPhone; I checked the parameter names and I was already using the correct ones. What else was I missing? Then it dawned on me...