Mike Christensen: Web Dev Guy : Internet Explorer

Writing a simple managed control under IE

mikechr — Tue, 28 Nov 2006 13:12:00 GMT

Most web developers are aware of various "controls" and "applets" that can be "hosted" by "Internet Explorer" (hmm, not sure why I quoted that last thing, I guess I was on a "roll".) This code is compiled code that runs within the IE process and draws itself within the boundaries of the document. The control even has access to the outside container. This is useful for doing all sorts of nifty stuff that might be hard to do using pure script or HTML, such as drawing graphs, animation, creating an interactive grid, creating a chat room, etc. Most of these controls are written in Java or COM (ActiveX). Java requires a special runtime that you have to download, and ActiveX requires your users to be running one of the many ActiveX compatible web browsers (There's tons! IE3.. Umm, IE4.. IE5.. Oh yea, IE5.5.. IE6, just to name a few).. However, what if you really want to keep users away from your site and write a control that requires them to download a special runtime ANNNNND only be able to use one browser. Well, then my friend you definitely need to write your own managed controls.

Only a hand full of web developers are aware that IE (recent versions, not sure which ones) can run managed code. Even less than a hand full (maybe a paw of a very small cat?) can actually tell you how to do this. Provided your users have the .NET framework installed (who doesn't?) there's a special syntax of the <object> tag that can instantiate a managed Winforms control. I found information on the Internet a little sparse on this subject so I decided to write a post describing exactly how to do this. Not that you should, as I'm sure I'll get 32,768 comments telling me that my apps are crap, proprietary and how that mentality somehow mirrors the exact attitude of Microsoft as a whole. Well, let me tell you something. This blog is dedicated to building web based applications, not web pages. Applications run on a certain platform. That platform might be Windows, that platform might be Mac, that platform might be the Java runtime. It might be a Commodore PET, a cell phone, a Zune, one of those old TI-85 graphing calculators, whatever. This platform can also be Internet Explorer. In fact, one of the reasons IE became so much more popular (especially within corporate networks) over say, Netscape, is it's an actual web application platform - not just a browser. Authors of applications can write applications for whatever platform they choose, based on its requirements as well as the users of said application. I might write an IE specific application for setting up direct deposit because my IT department has rolled out IE to everyone in my company. It's cost effective to target a single platform. There exists a certain spectrum; on one side you can scale to many different types of users but your development/test costs go way up and/or your feature set goes way down. On the other side, you can write a program once for a certain platform and target a very specific set of users. It's up to developers to figure out the best spot in that spectrum for their specific application. So enough of my rant, let's get back to the subject.

First, let's create a managed DLL with a single class in it. Since I don't feel like writing a full fledged control, all this thing will do is pop up a message box. Or maybe I don't actually know how to program and this whole blog's a lie. However, you'll get the point - you can add more controls to the child controls collection, override all sorts of events, etc.

[assembly:System.Security.AllowPartiallyTrustedCallersAttribute]
namespace HostedControlTest {
   public class TestControl : Control
   {
      public TestControl()
      {
         MessageBox.Show("Hello World!");
      }
   }
}

Compile the DLL, upload it to your web server in a location that clients have access to reach. You can test this by typing in the URL for the DLL and make sure the IE "Save" dialog comes up and you can download your own DLL. You might have certain web server security restrictions (especially if it's a Sharepoint server) that prevent users from downloading DLL files. It doesn't matter what web server you're using, it doesn't matter if the web server knows anything about .NET. It's simply a binary file sitting up on a server somewhere and it's downloaded exactly how, say, a JPG file is downloaded. Also, I'm pretty sure you can even use another extension other than DLL.

Once you have this working, create a new web page. On the page, place an object tag that looks something like:

You can replace HostedControlTest.dll with any valid relative path to your DLL. After the pound sign (or, octothorpe as I like to say) is the class within the DLL to load. Note I fully qualify the path with the namespace as well.

Load up your page through your web browser and the control should run and you should get a popup on your screen. No need to sign anything, no need to click "Yes" to any security warnings, etc. In fact, all security is taken care of for you by Code Access Security and is enforced by the runtime's security policy on your machine. Your control can request permissions (such as local file access) and it's up to the client's machine what it trusts the control to do. If a control all of a sudden tries to do something evil, the runtime will throw an exception.

That's all there is to it. Don't ask me any questions because this is all I know! Seriously. Actually, feel free to ask me questions and I'm sure I can find out the answers for you. Thanks!

Mike (Web Dev Guy)

JScript Functions

mikechr — Sat, 29 Jul 2006 00:42:00 GMT

My favorite IE tip/trick of the day has to do with function pointers and anonymous functions.

In Jscript, there are two keywords for creating functions. One is “function” with a lower case “f”, and one is “Function” with an upper case “F”. “function” is a keyword that allows you to describe a function in-line. The “function” keyword creates a named function (even if you don’t specify a name) and returns a pointer to that function. In most cases, you simply ignore the return value:

function Foo()

{

window.alert(“Hi!”);

}

is an example of this usage. However, I can also say:

var myFuncPtr = Foo;

myFuncPtr();

To call my function as well. Or, I can do:

var myFunc = function test(s)

{

window.alert(s);

}

To create a named function called “test” and create a variable called myFunc which holds a pointer to that function. I can then say:

myFunc(‘Hello’);

To print ‘Hello’ out to the screen.

I can also say:

var x = function()

{

window.alert('hello');

}

And have a pointer to a function with no name. In similar pointlessness, I can do:

function()

{

window.alert('hello');

}

Which is perfectly valid but it does absolutely nothing!

There’s also “Function” with a capitol F which is basically a built-in Jscript function that returns a reference to a new anonymous function. An anonymous function is simply a function that does not have a name and walks the lands doing good deeds for strangers in need, while searching for its true identity. Since it has no name, it must be called through a function pointer.

For example:

var items = {};

items[0] = new Function("window.alert('A');");

items[1] = new Function("window.alert('B');");

items[2] = new Function("window.alert('C');");

items[1]();

This allows me to create an array of anonymous functions that do different things, then call one of them through a pointer to that function.

In Jscript, functions are objects just like any object object. These objects can have names, can be part of arrays, can be passed to other functions, etc. The only difference is there’s special syntax (the parenthesis at the end) which directs the runtime to call the function rather than return a pointer to it.

So how about IE event handlers? Many people take IE’s eventing model for granted, it just works. But taking it apart is somewhat of an educational experience.

Let’s take this simple chunk of HTML for example:

<div id="myDiv" onclick="window.alert('foo');">Click Here</div>

It’s simple enough, but what is IE building in memory? There’s a <div> object with an ID property which is a string, and there’s an onclick property with some script. How does this script get compiled? It’s an anonymous function, right?. No! It’s a function that’s called “anonymous” (how @#!$’ing confusing is that?!?!). IE news up the function in its own compilation scope and returns it through a dispatch pointer.

The onclick property of our div object above is a pointer to a function (If you’re a COM guy I believe it’s technically an IConnectionPoint but who cares?)

You don’t believe me? Let’s run this little piece of code:

window.alert(myDiv.onclick);

Which will print out:

function anonymous()

{

window.alert(‘foo’);

}

Interesting, eh? If we want to call our function through our function pointer, we can simply do:

myDiv.onclick();

Which will run the code and display “foo”.

Ok so this is all silly and confusing, and for the people who actually understand all this, they are 1) the people who read this whole article and learned nothing they didn’t already know or 2) the people who are gonna leave me comments saying how something I said wasn’t quite accurate. Well, sorry I’m an Office developer and knowing how the scripting engines work is just a part time hobby. Thanks for reading, and hopefully you can use function pointers and anonymous functions to change the world for the better (the cure cancer anonymous function maybe?)

Mike

IE Tips and Tricks - Part 1

mikechr — Wed, 28 Jun 2006 09:03:00 GMT

It has occurred to me that I haven’t written much about client-side development and all that fun web browsery stuff. Before I get branded a server only guy, I’ve decided to write an n part series (where n is the number of articles I can write before getting bored of the subject) about my favorite HTML/CSS/Script tips and tricks.

The first is none other than DHTML expressions. DHTML expressions were a new feature in Internet Explorer 5 (back when the IE team was still attempting to innovate), however are still not used very often because of bugginess and performance issues. I’ve also seen several IE bugs that cause the IE window to crash if an expression exists against an object that’s since been removed from the DOM. I maintain that DHTML expressions (also called CSS expressions and “dynamic properties”) are quite helpful if used in very simple solutions, where the expression is something that can be resolved quickly as the IE DOM changes.

Expressions can be declared inline using a style attribute, within a CSS selector, or using script. I prefer the latter two since it keeps things simple. One of my favorite uses of expressions is to show and hide various UI depending on the state of a check box, radio button, or dropdown value. It allows UI to be hidden if certain options are not selected, or allows for an easy implementation of a “Show Advanced” checkbox.

In my example, I’m creating a simple time sheet that shows hours worked per pay period, and allows the user to show various classifications of work (Actual hours worked, Planned hours, and Overtime hours.) None of this uses script and it’s easy to see how it works, and doesn’t require logic complicated enough to warrant the use of a debugger (good luck debugging problems caused by expressions.)

Here’s my web page for you to copy into notepad and save locally:

<style>

BODY {font-family: Arial; font-size: 11px;}

TABLE {width: 75%; border: 1px solid grey;}

TH {background: #BBBBBB;}

.Total TD {text-align: right; border-top: 2px solid #999999;}

.Planned {display: expression(cbPlanned.checked ? '' : 'none'); background: #BBBBFF; text-align: right;}

.Actual {display: expression(cbActual.checked ? '' : 'none'); background: #BBFFBB; text-align: right;}

.Overtime {display: expression(cbOvertime.checked ? '' : 'none'); background: #FFBBBB; text-align: right;}

</style>

<input type="checkbox" id="cbPlanned"><label for="cbPlanned" style="background: #BBBBFF;">Show Planned</label>

<input type="checkbox" id="cbActual"><label for="cbActual" style="background: #BBFFBB;">Show Actual</label>

<input type="checkbox" id="cbOvertime"><label for="cbOvertime" style="background: #FFBBBB;">Show Overtime</label>

<tr><th>Period</th><th>Date</th><th>Work</th></tr>

</table>

As you can see, most of the logic is within the <style> block. Each planned work row has a class of “Planned”. In the CSS definition for the Planned class, the “display” property has an expression of whether or not the cbPlanned checkbox is checked. When the checkbox is un-checked, the display property of the CSS class becomes ‘none’.

Click Here to load this file in your web browser.

That’s it!

Mike – Web Dev Guy

Case-sensitivity with IE getAttribute

mikechr — Fri, 23 Jun 2006 08:50:00 GMT

I ran across an interesting behavior in IE the other day. Some of my script code was misbehaving, and it took me a while to track down the exact problem. In one part of my code I had an onfocusout event that would update an expando property to a certain value. However, when the object got focus again, I’d read the value and would find it was still set to the original value. When I moved focus away, I’d update the value again and same thing.

After much debugging, I stepped into the code that set the original value. It looked something like:

item.setAttribute("index", 0);

When I lost focus, I would update the value like so:

item.setAttribute("Index", 5);

Then, when I read the value back, I’d do:

value = item.getAttribute("Index");

However, the last line of code would return “0”, the original value I had set. So, why wasn’t my value being updated? Those of you intricately familiar with the IE DOM will already have seen the answer, it took me quite a while (mostly because of the thousands of lines of script code involved and the fact that in this modern era of technology, we still have yet to have a script debugger that really works well.)

So, let’s simplify the code down so you can run it in your own test web page:

Upon first glance, you would expect to see a value of “5” on the screen. However, upon running the code we see 0. Why?

Well, this has to do with the default behavior of setAttribute and getAttribute. When setAttribute is called, the <div> will look something like:

This is because setAttribute is case-sensitive and creates an expando property of the exact name specified. The second setAttribute will do the same, and the <div> will look like:

Since “index” and “Index” are different, two keys are created. Now, when the value is read, IE looks for the first attribute matching the name “Index”. Since getAttribute is not case-sensitive by default, it finds “index” with a lower case “i”.

The best way to fix this behavior is to use the same casing for expando attributes, my original code was simply due to a typo on my part years ago that didn’t surface until now. The other way around is to call getAttribute as such:

window.alert(foo.getAttribute("Index", true));

This will cause IE to be case-sensitive when searching for the value. I’d disagree with the IE team (though it was probably some ECMA decision) on this point, I think names of expando properties should be case-sensitive like most syntax in Jscript. Interesting lesson though, I learned to check with MSDN before assuming something was the case.

Mike - Web Dev Guy