A quick web search on calculating browser window height reveals that different browsers have different ways to find the browser’s window client height.  In Netscape / Mozilla browsers, you can use window.innerHeight.  For IE, some sources suggest using document.body.offsetHeight, but I’ve found this falls short when the HTML content does not completely fill the browser window.  document.documentElement.clientHeight returns the actual window client height in IE.

The jQuery JavaScript library has some handy functions for calculating an element’s pixel location and pixel width and height, with or without consideration for borders, padding and margin.  $(“.myclass”).outerHeight() will give you the pixel height of the first element with a CSS class of “myclass”, including borders and margins.

$(“body”).outerHeight() returns the same value as document.body.offsetHeight, which will be less than the window height in a short HTML document and could be much larger than client height in a scrolling window.

Share/Bookmark

• Novel: multiple independent story lines that you hope will eventually converge to make a point.
• Short story: a limited number of characters with only one point to make
• Essay: tell ‘em what you’re going to say, say it, then tell ‘em what you said
• Tragedy: everything that can go wrong usually does
• Sonnet: ornately crafted for no particular reason
• Ode: behold my skillz, and despair!
• Thriller: I’ve got a  bad feeling about this…
• Murder Mystery: when things go wrong, top priority is on placing blame
• Self-Help: You can do it!  Please do.
• Epic Saga: “Help! I can’t stop writing!”
• Technical Documentation: Useful bits hidden in a sea of jargon, surrounded by a narcoleptic field
• Government Bulletin: Technical docs sans useful bits
• Billboard: all flash, no substance

Since I come from the school of “simple elegance”, I’d have to say that my ideal software’s literary equivalent would be

Comedy: If you have to explain it, it’s not very good.

Share/Bookmark

You could create an event handler method to catch each of the old style events fired by the old code and turn around and fire the corresponding new style event in your API, but who wants to write all that mind numbingly repetitive code?

There is a simpler way.  The two incompatible event patterns do have one thing in common:  the Invoke method.

But first, some background.

Custom EventHandler Types, 1.0 Style

In .NET 1.0 the pattern to define an event property was to define an EventArgs class to carry the arguments of your event and define an EventHandler delegate type which uses that EventArgs class as its args parameter.  Like this:

    public class ActivityCompletedEventArgs : EventArgs
    {
        public ActivityCompletedEventArgs(int resultCode, string result)
        {
            ResultCode = resultCode;
            Result = result;
        }

        public int ResultCode { get; private set; }
        public string Result { get; private set; }
    }

    public delegate void ActivityCompletedEventHandler(object sender,
                                                       ActivityCompletedEventArgs e);

    class Bar
    {
        public event ActivityCompletedEventHandler Completed;
    }

Generic EventHandler<> Types, 2.0 Style

With the advent of generic types in .NET 2.0, the generic EventHandler<> parameterized type was born.  This parameterized EventHandler<> delegate type simplifies how you declare and use event handlers – you don’t have to declare a custom event handler delegate type to match your event args class every time you create a new kind of event.  This is exactly the kind of thing that parameterized types (aka generics) were created to solve. Like this:

    public class ActivityCompletedEventArgs : EventArgs
    {
        public ActivityCompletedEventArgs(int resultCode, string result)
        {
            ResultCode = resultCode;
            Result = result;
        }

        public int ResultCode { get; private set; }
        public string Result { get; private set; }
    }

    class Bar
    {
        public event EventHandler<ActivityCompletedEventArgs> Completed;
    }

However, the downside is that EventHandler<> delegates are not assignment compatible with the old style non-generic EventHandler style delegates.

The Invoke Bridge

Both styles of event delegate have an Invoke method with a signature of (Object sender, EventArgs args), where EventArgs is the arguments class specific to this particular event.  You can use this point of commonality to convert between event styles without too much trouble.  The trick is to use the .Invoke method in one style of event as the callback method registered in the other style of event:

    class OldStyleClass
    {
        public event ActivityCompletedEventHandler OldStyleEvent;
    }

    class NewStyleClass
    {
        public event EventHandler<ActivityCompletedEventArgs> Completed;

        public void blah()
        {
            var obj = new OldStyleClass();
            obj.OldStyleEvent += new ActivityCompletedEventHandler(Completed.Invoke);
        }
    }

The code above hooks up the events so that when OldStyleClass.OldStyleEvent fires, it will fire the NewStyleClass.Completed event.

The main catch to this technique (in C#) is that the reference to the event’s .Invoke method must be made from within the context of the class that defines the event. C# doesn’t allow access to the members of an event delegate outside of the class that defines the event. The rules may be different in other .NET languages.

If you want to use this technique in the opposite direction (to have a new style event fire an old style event), you will need to be able to modify the source code of the old style class that defines the old style event. This is much less common than making old style code to fire new style events.

Share/Bookmark

This will be a great opportunity to listen in on technical topics on developing applications with Live Frameworks, both standalone desktop apps as well as mesh-enabled web apps. A large chunk of the webcast time has been set aside for Q&A, but the best way to get your specific questions answered is to send them to us prior to the event so they can be worked into the presentation schedule.  Post your questions to this thread in the Live Framework discussion forum.

To join the webcast, visit this link:  https://www.livemeeting.com/cc/microsoft/join?id=LiveFx_Dec8&role=attend

For more information and agenda, see the announcement on the Live Frameworks forum.

See you there!

Share/Bookmark

In the “Dependencies” section of the article, Stefanov describes using the onLoad or onReadyStateChange events of the dynamically generated script tag to receive notification when that script has been loaded by the browser.  Once you know it’s loaded, then you know it’s safe to begin using the code it contains.

This works great for Firefox and IE, but fails completely in the Safari browser.  Safari doesn’t implement onLoad notifications for script tags.  This forces you to abandon the onLoad technique and instead use the technique of embedding something at the end of each script file to signal when the file has been loaded. 

The script libraries for the Windows Live sites use this technique – every source file contains a function call at the bottom that tells a central notifier that it has been loaded.  Other code can ask the notifier to signal them when a file or set of files have been loaded.  This works in all browsers without relying on diverging browser idiosyncracies. 

Unfortunately, this also requires that all the JavaScript you want to load dynamically (using this technique) knows about your particular load notification pattern.  If you want to dynamically load JavaScript from multiple libraries or authors, you will either end up with multiple notification systems (which should coexist peacefully) or you’ll have to modify those files to use your load notifier.  This is bad from a design standpoint because it requires that all your code modules have carnal knowledge of your application - erodes the modularity of the source files – or require that all your code modules follow the design patterns of a particular JavaScript toolkit, like DoJo or Prototype or YUI.  The latter isn’t a terrible tradeoff except that it limits your options.

 Discovered via a note by Steve Trefethen on FriendFeed.

Share/Bookmark