Making a jQueryUI Button

We now use the nice jQueryUI library in Tracker.Net, Exam Engine, and Training Studio. In each case, you link in the correct JavaScript files and style sheet and then use JavaScript to create the button. The nice thing is that you can use various types of HTML objects (input, anchor, ASP.NET buttons, etc.) and they still end up looking like a button. Here is an example from Tracker.Net:

$(function () {
        var optionsBtnId = $("#optionsBtn");

        if (optionsBtnId.length) {
            optionsBtnId.button({
                icons: {
                    primary: "ui-icon-home"
                },
                text: false
            });
            optionsBtnId.click(function () {
                var returnVal = true;

                if (isOnCoursePage == true) {
                    if (isOneCourse == true) {
                        window.resizeTo(800, 600);
                    }
                    else {
                        returnVal = checkIfOkToLeave(LessonOpenMessageLeavingScreen);
                    }
                }

                return returnVal;
            });
        }
    });

The $() means that the jQuery will call the function after the page fully loads. We then get our hands on the HTML object that we want to use for our button. The #optionsBtn means that we are looking for an object with an id of “optionsBtn.” We then call the jQueryUI button method to create the button. In this case, we tell it to use the jQueryUI home icon and not to have any text. Next, we define the click function. Here we are doing some logic to determine whether to proceed with the click. If returnVal is false, the server side event will not be processed and we stay on the page.

Advertisement

ASYMI_AutoSize Property

With version 11.5 of Learning & Mastering ToolBook, we redid virtually all screen captures to show the Windows 8 style. These captures were a few pixels bigger. The easiest way to update the buttons/images was to change them to autosize to the graphic they hold. We could do this via the Property Sheet, but that got pretty tedious. Quicker was the script below. You select the object and use the Command Window to execute this script.

ASYMI_AutoSize of selection = True; send ASYM_Reset to selection

How did I figure out what property to set? I used the Property Browser and looked at the user properties for the object after setting the AutoSize via the Property Sheet.

Why ASYM_Reset? That tells any object to redraw or otherwise reset itself.

Debugging Your Applications

This is a short segment from my Programming for e-Learning Developers book.

Although all of us would like to write perfect programs from the start, that rarely happens in the real world. We therefore need a way to figure out what is wrong with them. This is known as debugging. While entire books have been written on the subject, we can at least take a look at the core debugging techniques you can use in each of our environments.

ToolBook – OpenScript

To debug OpenScript, you open the Script Editor for the script you are interested in and click the “Debugger” button on the toolbar.

The next step is to put in a “breakpoint.” This is where the script execution will stop and allow you to “step through” and watch the code. In OpenScript, you click on the line(s) where you want to stop.

You then return to “reader” mode and initiate the script. For example, you might click the button that starts the sequence or re-enter the page. The Debugger will then pop up. The first thing I recommend doing is viewing variables (View menu – Variables). This allows you to see the current value of your variables. ToolBook also displays sysError, Target, and TargetWindow. These can also be helpful for figuring out strange problems. You can then use the Trace menu (Figure 137) to step through the code. Most common is to continue line by line (“Trace Statement”) or to step into another method (“Trace Into Call”). If all looks OK and you want to either jump to the next breakpoint or finish the script execution completely, you can choose “Continue Execution.”

ToolBook – Actions Editor

The Actions Editor doesn’t have an integrated debugger. While it is possible to use the OpenScript Debugger on the code generated by the Actions Editor for native mode, that is not for the faint of heart, since the generated code is typically more complex than hand-coded script would be. Similarly, you can publish to HTML and use a JavaScript debugger like those covered later in this chapter, but trying to find the right code and digging through ToolBook’s own generated JavaScript can be daunting. In most cases, you can get by with the poor man’s debugger: alert boxes.

For example, we add a Display alert action with both the variable name and variable value. These work both natively and after publishing to HTML. It was important to try this in both native and HTML mode as CRLF in our code turned out to be one character in native and two characters once inside the browser. If you are linking to external .js files, you can put JavaScript alert calls for simple debugging of those scripts. You can also put in a debugger; line to launch as explained in the upcoming JavaScript section.

Flash

Flash has a robust debugging environment that is much improved in recent versions. Rather than needing to go to a separate “debug” mode as in ToolBook OpenScript, you set the breakpoint by clicking to the left of the line number.

The next step is to go to the Debug menu and select Debug Movie. This will launch both the Flash Debugger and the Flash movie itself. You then run the movie as normal until you hit the breakpoint. The Debugger window will then come to the front. You can view various object properties and the values of your variables. You don’t need to wait until you have a problem in order to use the Debugger. I’ll often fire it up just to confirm initial logic or to see what variable values look like if I’m not positive about the format or contents .

We can then use the Debug menu to control our debugging session. The most common options are to “Step In” to a function, “Step Over” the current line to stay in the current function, or to “Continue” execution until you reach another breakpoint.

JavaScript

There are two approaches for debugging your JavaScript. If you are using a development environment like Visual Studio, you can set breakpoints directly within it and then run the project. To do this, you click to the left of the line where you want to set the breakpoint. This is quite similar to how you set a breakpoint in Flash.

You’ll also need to “Disable script debugging ” for both Internet Explorer and other browsers in order for this to work. When you do this, you’ll get the option to debug any JavaScript errors out there as you browse the web. This is a great idea when you are testing your own software but can be a drag when you run into all the bad web pages out there. So remember where the setting is so you can turn it off later if desired.

When you perform the action (such as click a button) that calls that code, Visual Studio comes to the front and shows you the current execution line. The variables and parameters that are currently being used are automatically shown in the “Locals” window. The “Autos” window limits the display to variables used in the current and preceding line of code. You can also have one or more “Watch” windows which show the value of just variable(s) you select.

As with the ToolBook OpenScript and Flash debuggers, you can “Step Into” a Method (e.g., jump into its code), “Step Over” a line to get to the next one, or “Continue” to the next breakpoint or to the end of the program. You can also “Step Out” to move back up a level to the calling method. This can be handy if you have “stepped in” to a method and now want to return to where you were without having to step through each line of the called method. You control this with the Debug menu. Notice that the accelerators (F8 for “Step Into” for example) are settable based on your language profile. F8 is traditionally the value for Visual Basic developers while C# and C++ developers have typically used F10.

The second approach for debugging JavaScript involves using the browser itself. Firefox has a free JavaScript Debugger “Add-on” that then is listed under the Tools menu. That brings up the JavaScript Debugger itself. You can go to the correct HTML page in the upper left of the screen. If the page is using .js files, you can select the one you want from the list. The Debugger will then show the code from the page or file in the right window. You can then set a breakpoint by clicking to the left of the desired line number. We then return to the main browser window and exercise the code.

The JavaScript Debugger then comes to the front with the breakpoint highlighted. We can then “Step Over,” “Step Into,” or “Step Out” using the toolbar or the Debug menu. We can then view variables on the left side window.

Starting with Internet Explorer 8, IE also has a debugger right in the browser. It is located with HTML, CSS, and Profiler tools under the Developer Tools option under the Tools menu. Once you have the Developer Tools open, you want to click on the “Script” tab. From there, you can list the JavaScript in the page itself or select the desired .js file from the drop-down list. You can then set one or more breakpoints in the normal way by clicking in the area to the left of the line number. We then return to the browser window and cause this code to be executed.

The JavaScript Debugger then comes to the front with the breakpoint highlighted. Rather than use a menu in this case, we use the toolbar to “Step Over,” “Step Into,” or “Step Out” the current line of code. We can choose to view Locals as well as a Console (for executing code), a list of breakpoints, a list of “watched” variables, and the entire “call stack.” Notice how we can again expand nodes and other variables to view their values. This is extremely useful, particularly when working with XML.