Archive for the 'Programming' Category


DOCTYPE affects iframe scrollbar styles 1

An application I am currently working on has been specifically targeted towards Internet Explorer and a technical design requirement is that the browser window the application is being run in is a fixed size. So inevitably, there will be scrolling.

As part of the design we decided to use a document divided up into sections using DIV tags and absolutely positioning rather than using frames all around. This leaves the primary content area of the application as an iframe taking up the majority of the page.

A week or so ago I put some styles in my CSS which were intended to color the scrollbars on the iframe. Oddly… this didn’t work. I didn’t really attempt to follow up on it until today, at which point I found an interesting solution.

Before, I had the following document definition in my HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">

I changed the definition to:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

And now things work great. I’m not sure why, maybe when I get some time to look it up I’ll modify this post to reflect whatever reasons I find.

However, if you are having problems with your iframe scrollbars not taking your styles, this could help.

Assigning a CSS class to a dynamically created DOM element 0

I recently discovered that Internet Explorer and Firefox don’t agree on the possibilities of assigning a CSS class to a dynamically created DOM element (created via JavaScript) using the “setAttribute” method. It took me a little time to figure out what was going on and how to fix it, so in the hopes that I can save someone else some time I decided to provide this post.

First, I should outline what I was trying to accomplish. I have a need for a web page which has completely dynamic display properties. During the use of the page many of the DOM elements will behave according to the user’s input, so I need to have each of them accessible in JavaScript. The goal is to have a page which can adjust, update and move all of its elements without ever reloading the page or any data which has already been loaded. The page is being written using .NET, JavaScript, (D)HTML and CSS.

Now, for the approach I decided to take. Since JavaScript will need to have access to all the elements anyhow, I decided the better approach would be to have a JavaScript object for each “module” that will exist in the page. This object carries some details about the object as well as a reference to a DOM object that will be associated with each module. The goal here is to keep from duplicating code, so I either write the DOM object in the HTML (and use server side logic to manage it) or I write it in JavaScript (and use the client’s memory to manage it), but not both.

My page is made up of three files, I’ve simplified them for illustrative purposes below…

My JavaScript source file, script.js:

d = new Array();
d[0] = new Display("Header", "Header");

function initializeDisplays() {
  for (var i = 0; i < d.length; i++) {
    container = document.getElementById("FrameworkContainer");
    d[i].dome = document.createElement("div");
    d[i].dome.setAttribute("id", d[i].id);
    d[i].dome.setAttribute("class", "moduleBody");
    d[i].dome.innerHTML = d[i].name;
    container.appendChild(d[i].dome);
  }
}

function Display(name, id) {
  this.name = name;
  this.id = id;
}

My CSS stylesheet, style.css:

.moduleBody {
  color:  Green;
}

And finally, my HTML file, test.html:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhmtl">
<head>
  <title>Test Page</title>
  <script type="text/javascript" src="script.js"></script>
  <link href="style.css" rel="stylesheet" type="text/css" />
</head>
<body onload="initializeDisplays();">
  <div id="FrameworkContainer"></div>
</body>
</html>

Now this code works fine in Firefox, the new div is loaded into the document as expected and the text is green, as expected. However, using the same code in IE provides slightly different results. The div is loaded as expected, but no styles are applied to it. The reason, is that IE doesn’t support the following line of code:

d[i].dome.setAttribute("class", "moduleBody");

Instead, IE demands you use the following syntax:

d[i].dome.className = "moduleBody";

Is it a big deal? No, not really. But it can still be very, very frustrating to find that IE has issues when applying styles to a dynamically created element which uses the consistent approach of setAttribute as a means to set a style class. You will probably find that the className property is the recommended approach in tutorials and will find that it works in most browsers, but being a stickler for consistency I tried a different approach and ended up with this article to show for it!

SQL Management Studio… How NOT to save in Unicode format 10

A project I work on requires that we developers edit stored procedures and store the resulting script in a text file that we put in our source control tool. In our case, we use Microsoft SQL Server Management Studio to do the aforementioned editing and we use CA’s Harvest Change Manager as the corporate mandated code repository and source control tool.

Now if you were using another tool, Notepad or Query Analalyzer, for instance, you probably wouldn’t have the problem I’m going to outline. As a matter of fact, the problem I’m going to outline is probably pretty rare. But it exists and I found a solution, so I’m going to write about it.

As it turns out, whenever you “Save As” in Microsoft SQL Server Management Studio the default encoding for the file is Unicode - Codepage 1200. Yes, this is a new approach to saving your beloved stored procedures and no, it wasn’t done that way in the past. Further, I can’t find any notification that the “standard default” was going to be changing.

Anyway, Harvest doesn’t like Unicode files. So when you go to add the file to your Harvest project it won’t let you. Oh, the humanity! ANSI for everyone!

Now I may be in the minority here, but I originally failed to notice that on the “Save File As” dialog there is a small arrow on the right side of the [Save] button. Once I noticed it, I clicked it… Then I clicked “Save with encoding…” Now I’m happy again! Kind of…

The good thing is that this will let you save your file in whatever encoding you want. The caveat is that it will let you save your file in whatever encoding you want.

So how is the default set? I’ll leave that for another article… Mostly because I don’t know yet.

Update (04.11.2008): Thanks to Chris May for the following step by step instructions on how to overcome this issue (edited for formatting, the original version is comment #8):

I have found some information about this.

Though it is possible at the time a script is saved to change the encoding to ascii it is tedious. Here is the process.

  1. Choose File\Save
  2. Choose the name and folder to save the file then look really closely at the right edge of the “Save” button for a tiny arrow
  3. Click that tiny Arrow and choose “Save with Encoding”
  4. From the Drop list select the encoding you want (the default encoding is “Unicode - Codepage 1200″, which means “UTF-16″). I have been using “US-ASCII - Codepage 20127″
  5. Hit OK and Save. Your files should now work just fine with Perforce, CVS, etc.

Additionally, Chris has voiced his feedback to the SQL team, I encourage everyone to go have a look and hopefully we can get a solution sooner rather than later… although the outlook is bleak.