Contents tagged with JavaScript

  • Code Builder for jQuery AJAX (Calling Web Services)

    Getting stuck in the cycle of code-build-test, code-build-test… can drain you physically, mentally, emotionally and spiritually. In the back of your mind you know the clock is ticking and you are not making headway. Of course the boss keeps sticking his sweaty head into your tiny cube and asking, "Any progress?" What a jerk. The intern who is supposed to be helping you keeps asking stupid questions he could find on Google: the lazy meathead. The department secretary just told you they lost your time sheet so you'll have to fill out another one: Too bad you didn't make a copy. Your waist is getting thicker and your hair is getting thinner.

  • Log4net: Log to a JavaScript Console

    While lurking and skulking in the shadows of various technical .Net sites, I've noticed many developers discussing log4net in their blogs and posts; log4net is an extremely popular tool for logging .Net Applications. So, I decided to try it out. After the initial complexities of getting it up and running, I was suitably impressed. Could it be…logging is fun? Well, I don't know if I'd go that far…at least I'd never admit it.

  • AH, Ah, ah, ah…Staying Alive…Staying Alive

    Sometimes you want your web page to 'stay alive'. That is, if a user is filling out a complicated form, you do not want the session to time out before they are finished. The user could get very angry and rightfully so: You might even get yelled at!

    It's not simply a matter of increasing the session timeout to a very large value. If you do that, the sessions would be left active in the server memory for hours—long after the visitors have left the site. Increasing the session timeout IS a solution… but not necessarily a good solution.

    The goal is that the session should stay active as long as the web page is open on the client machine …even if there are no post backs to reset the session timer. When the web page is closed, the session should time out normally.

    I implemented a solution for this: The client will "ping" the server at intervals of less than the session timeout which will reset the session timer. This is known as the Heartbeat design pattern (I couldn't find a decent site/page to link to).

    Miscellaneous Setup Stuff:

    For testing purposes, I set the Session Timeout to two minutes in web.config:

      <sessionState timeout="2">


    To trace what is happening, I used a utility function called ODS (it's in a class called MiscUtilities): 
    /// ---- ODS ---------------------------------------
    /// <summary>
    /// Output Debug String with time stamp.
    /// </summary>
    public static void ODS(string Msg)
        String Out = String.Format("{0}  {1}", 
                           DateTime.Now.ToString("hh:mm:ss.ff"), Msg);


    To watch the Session State events, I added debugging strings to the global.asax file:

    <%@ Application Language="C#" %>
    <script RunAt="server">
        void Application_Start(object sender, EventArgs e)
        void Session_Start(object sender, EventArgs e)
        void Session_End(object sender, EventArgs e)

    Here are the details:

    We need a method at the server for the client to call. We use a WebMethod.

    1. There must be a ScriptManager on the page.
    2. The ScriptManager must have EnablePageMethods set to true.
    3. The WebMethod must be public and static.
    4. The WebMethod must have the EnableSession attribute set to true.
    <asp:ScriptManager ID="ScriptManager1" runat="server" 
    public partial class _Default : System.Web.UI.Page
        [WebMethod(EnableSession=true ) ]
        public static void PokePage()
            // called by client to refresh session
            MiscUtilities.ODS("Server: I am poked");       


    We need JavaScript at the client to call the server function at fixed intervals:

    <script type="text/javascript">
        var HeartBeatTimer;
        function StartHeartBeat()
            // pulse every 10 seconds
            if (HeartBeatTimer == null)
                HeartBeatTimer = setInterval("HeartBeat()", 1000 * 10);
        function HeartBeat()
            // note: ScriptManger must have: EnablePageMethods="true"
            Sys.Debug.trace("Client: Poke Server");
    <body id="MyBody"  onload="StartHeartBeat();">


    Here is what the output looks like without the heartbeat:

    10:22:43.03  ****ApplicationStart
    10:22:45.13  Session_Start
    10:25:00.00  Session_End 

    Here is the output with the heartbeat:

    10:26:06.10  ****ApplicationStart
    10:26:08.05  Session_Start
    Client: Poke Server
    10:26:18.93  Server: I am poked
    Client: Poke Server
    10:26:28.95  Server: I am poked
    Client: Poke Server
    10:26:38.96  Server: I am poked
    Client: Poke Server
    10:26:48.98  Server: I am poked

        . . . (lines deleted)

    Client: Poke Server
    10:29:59.45  Server: I am poked
    Client: Poke Server
    10:30:09.47  Server: I am poked
    Client: Poke Server
    10:30:19.48  Server: I am poked

        . . . (lines deleted)

    It looks like the session is staying alive while the client is idle: Excellent!

    I hope someone finds this useful.

    Steve Wellens

  • IE 8 Can Profile JavaScript

    Being on the software "bleeding edge" is similar to being the "point man" in combat. I generally avoid being the first to adopt new technology until some other poor bastard has led the way…and occasionally paid a price: The price being missed deadlines, ulcers and ruined reputations. No thanks.

    However, with Internet Explorer 8, for some inexplicable reason, I jumped right in. And I was pleasantly surprised. One of the nicest features is the new Developer Tools toolbar that comes with IE 8. Previously the Developer Toolbar was an add-on.

    On the Developer Tools window there is a new Profiler tab. Since there have been recent performance issues on the Asp.Net forums where I'm a moderator, I thought I'd give it a spin.

    • I clicked Start Profiling.
    • I navigated to the Asp.Net forums website.
    • I waited for the page to finish loading. Having the Profiler running slows things down quite a bit…which is understandable.
    • After the page had finished loading, I clicked Stop Profiling.

    It was that easy. The results are below. It appears the getAvatar function is taking a lot of time. If each call to getAvatar results in a database call, and each call results in an image being resized, that could explain why there are performance issues.


    I hope you find this useful.

    Steve Wellens.