It's been a long time since I posted.  There are many reasons for this, but mostly, I'm not working with FrontPage anymore.  For the next release of FrontPage, there are a lot of changes happening.  One of the largest is a stronger focus on SharePoint and SharePoint site design and development and less focus on Web development. You can read more about the changes to FrontPage for the next version in Rob Mauceri's blog. I haven't been working with FrontPage nearly as long as Rob, but I have worked with several other Web development apps, and the changes that they made to the FrontPage code this time around are, in a word, incredible. Rob explains what these features are, so I won't go into detail. Please look at his blog for more information

However, as a result of these changes, they didn't really need me anymore. Since I write about code and developer stuff and not so much about design or UI stuff, so I've gone back to working on Word for the time being. As a result, I won't be posting anymore about FrontPage (thus the name change), but I won't be posting about Word either, so this won't become a Word programming blog. (I actually think there are plenty of those, Brian Jones blog being the predominant one for Office 12 changes.) I'll just write about the things that interest me. The next time I post something I've been doing lately.

I usually always try to respond to comments to my blog, but lately, we've had some disconnects with comments being sent in email, so I thought I would respond to a few recent comments. If I've missed your comment, please forgive me and feel free to send me mail using the Contact link in my blog.

Comment from Jason:

"Do you guys purposely markup your pages to render incorrectly in every browser other than IE?

Jason, I'm not sure if you're talking about the FrontPage dev portal on MSDN or my blog, but I assure you that it isn't intentional. Both the blog tool and MSDN have their own ways of marking up HTML, which are very different from each other and which I haven't yet quite figured out.

I just tried both MSDN and my blog in Firefox, and the blog looked fine, but sure 'nuf MSDN looked pretty bad. Unfortunately, I can't do much about this, so please don't dis our content because IMHO we have some pretty great content.

Comment from orcmid:

"Please screen the most-active newsgroup discussions before you feature them. After reading the thread about multiple body tags, I am very wary of ever asking a question that one of those MVPs might want to tell me is stupid.

"No one ever did bother to ask what DAWG found valuable about being able to have multiple body tags (regardless of the fact that FrontPage is not designed to allow it), assuming that there was an alternative solution without checking with him what he really wanted to do. The resulting incivility was unpleasant to watch."

First, newsgroup posts are included using a Web component. I'm not sure exactly how this is determined, but I believe it is based on how many responses there are to a post, so I have no direct control over which posts get "featured."

Second, no one should ever be treated rudely in any of the newsgroups. The newsgroups are moderated by MVPs and other users who volunteer time to respond to customers. Although we have no control over what general users say, we do have some control over how MVPs treat customers.  I'll forward your comment to the MVP lead, who I'm sure will follow up appropriately with the MVPs. If you ever see any user being abused, called names, or generally treated like an idiot in any of the newsgroups, feel free to contact me, and I'll follow up with the MVP lead.

Finally, I wanted to address DAWG's issue about using multiple BODY elements in the same document. The HTML schema doesn't allow for multiple BODY elements, so it's not surprising that FrontPage doesn't support it. However, I can think of a couple reasons why someone might want to use multiple BODY elements.

In documentation, there is something called single-sourcing. It allows people to create one file that can be used in multiple places. For example, you might have some files that you want included in a book as well as in a compiled help file. If this is what DAWG wanted to do, his best choice would be XML.

Old-timers often associate XML with literal data, as you might find in a database, but XML has many more uses, and single-sourcing is one of them. XML allows you to create a custom schema that you can use to markup content.

With XML, you can markup the content in a file and specify where different portions of the content get published. As in the case I cited earlier, say you have help files that you want published to a compiled help file as well as in a book.  Another case where you might want to do single sourcing is where some content gets published to a Web site, some content is included in a marketing flyer, and some content is compiled into a brochure. These are only a few instances where XML is the ideal markup language, and I have no doubt that many of you can think of many more possible scenarios where a single file might be published in multiple formats.

Although XTHML is similar to XML in the sense that the XHTML schema generally encourages that the formatting be kept separate from the HTML, it isn't XML. It's really just an HTML schema that enforces certain style restrictions. True XML uses a custom schema that contains custom markup tags. You use XSLTs to "transform" the appearance of the content in XML files, but XSLTs do more than just change the appearance of the text, for example making some text bold and other text underlined.

XSLT allows you to convert an XML file from one format, or XML schema, to another. For example, you can use an XSLT to compile XML files into a Word document, or you can use XSLT, to convert files into HTML format. You can even use XSLT to convert from one XML schema to another XML schema.

The second reason that I can think of is for browser compatibility.  For example, perhaps DAWG wanted to put in multiple BODY elements with the idea that only the BODY element for the client browser would be visible. This seems to me to be the least likely of the two reasons that I can think of.

Ideally, all Web pages should be cross-browser compliant (MSDN pages not withstanding!), but in the case where you need to develop different HTML pages for different browsers (or connection speeds), you could have a script that determines the browser on load and serves up the correct page for that browser. I'm sure there are several scripts available on the Internet, in fact, I believe FrontPage 2003 includes a behavior for just this purpose, but I'll provide a simple script in a future post for those who are interested in knowing how to do this.

Thanks, everyone, for your comments. As I said, as much as possible I like to respond to comments and usually do so in email when an email address is provided. Keep the comments coming!

Until next time, happy surfing!

It has been awhile since my last JavaScript 101 post. I apologize. I have a very lame excuse: I've been busy. But I'm back with the next installment: working with events.

Most JavaScript events are relatively simple and easy to use. For example, clicking on a button, an element, or a page. There are some more complex events that deal with data, but to keep this simple, I'll talk only about the ones that affect user interaction, such as onclick, onmouseover, onmouseout, and onfocus. There are, of course, many more events than this, but these four events seem to cover a majority of the uses that you will need ... at least to start with.

The Script

First, of course, you need a script, so here's a simple little script.  All it does is display a message box.  Just copy the code below, including the opening and closing <script> tags, and paste them into the HEAD section of a Web page.

<script language="javascript">
function ShowMessage(text)
{
    window.alert(text);
}
</script>

In order to call a script from an event, it must be inside a function, so the above script contains a function called "ShowMessage" that takes one argument, the text to be displayed.

Note   As I mentioned in my last JavaScript 101 post, you can use IntelliSense in Code view in FrontPage to write your scripts.

The HTML

Second, you need to reference the function from an event inside of an element. I'll use a P element. Here's the HTML code that you need.

<p>Here is a sample paragraph 
with an event.</p>

Putting Them Both Together

Next, add to the P element a an event handler that calls the function.  You can add it to any event, such as the onload event, but to make things simple, add it to the onclick event.  Here's the code:

onclick="ShowMessage
('A little JavaScript fun!');"

Your P element should now look like the following code:

<p oncl­ick="ShowMessage
('A little JavaScript fun!');">
Here is a sample paragraph with 
an event.</p>

And that's it.  Save your page and display it in the browser.  When you click on the text in the paragraph, the browser displays a message like the one in the following image.

What You've Learned

In this post you learned how to hook up a JavaScript function with an event handler for an HTML element. Now that you understand how to hook your scripts up to events to create user interaction, we can move onto writing more scripts.  Next time, I'll talk about working with text—things like changing the text or HTML in an element, changing colors, formatting, etc. Until then, have fun!

John Jansen, one of the FrontPage testers, sent me these three different ways to password protect pages in FrontPage.

Using a FrontPage site template and ASP
Using Code Snippets
Using ASP.NET

To password protect pages using a FrontPage site template and ASP

Here are specific steps to password protect pages using features built into FrontPage:

1. From the File menu, click New.
2. From the Web Site tab, select FrontPage Server Templates from the first list, and then select Database Interface Wizard from the second list.
3. Type the location where you want to put your password protected page. This must be an Windows Web server running IIS.
4. Click OK.
5. In the Wizard…
   1. Click Next to create an ASP solution.
   2. Click Next to use the default name for the connection.
   3. Click Next to use the default columns in the table.
   4. Click Next after the DB is created.
   5. Click Next to use the default table.
   6. Check the box to use a Database Editor.
   7. Click Next.
   8. Choose a password and enter it.
   9. Click Next.
   10. Click Finish.
6. After FrontPage finishes building the site, all of the necessary code for password protecting pages has been generated. In order to protect any new pages, simply put the following code:
   

   <!-- #include file=”login.asa” -->
   <%
   If Session(SiteId) <> true Then
   Response.Redirect(“login.asp?requester=<!--insert page name here-->”)
   End If
   %>

   above the <HTML> tag on any page and save as .asp.

To password protect pages using Code Snippets

Here are steps to create password protected pages using code snippets:

1. Create a new site in FrontPage.
2. Create a new page and switch to Code view.
3. Delete all the code in the new page.
4. Paste the following code as a code snippet.

   <%
   Username="user"
   Password="pass"
   ' if any of the variables do not match, create error message
   if Request.Form("login") <> Username or Request.Form("password") <> Password then
       MsgErr = "<h3>Authorization Failed.</h3>"
       Response.Write MsgErr
       ' if correct, set the session variable and proceed
   Else
       Session("someStringValue") = true
       ' redirect
       If Len(Request("requester")) > 0 Then
           Response.Redirect (Request("requester"))
       Else
           Response.Redirect "protected.asp"
       End if
   End if
   %>
   <html>
   <head>
       <title>Results -- Login</title>
       <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
       <meta name="GENERATOR" content="Microsoft FrontPage 6.0">
       <meta name="ProgId" content="FrontPage.Editor.Document">
   </head>
   
   <body bgcolor="#FFFFFF">
       <FORM ACTION="login.asp" METHOD="post">
       <h3>Login</h3>
           <TABLE BORDER=0> 
               <TR>
                   <TD ALIGN="right">User name:</TD>
                   <TD><INPUT TYPE="text" NAME="login" size="10" VALUE=''/></TD>
               </TR>
               <TR>
                   <TD ALIGN="right">Password:</TD>
                   <TD><INPUT TYPE="password" NAME="password" size="10" VALUE=''/></TD>
               </TR>
               <TR>
                   <TD><input TYPE="hidden" NAME="requester" VALUE="<%=Server.HtmlEncode(Request("requester"))%>"></TD>
                   <TD></TD>
               </TR>
               <TR>
                   <TD align="left"><INPUT TYPE="submit" VALUE="Login"/></TD>
                   <TD></TD>
               </TR>
           </TABLE>
       </FORM>
   </body>
   </html>

5. Save page as login.asp.
6. Create a new page and switch to Code view (or do this with any page you want to protect with a password).
7. Above the opening <html> tag, paste in the following snippet.

   <%
   If Session("someStringValue") <> true Then
       Response.Redirect("Login.asp?requester=protected.asp")
   End If
   %>

8. Save this page as protected.asp (or replace the requester text above from protected.asp to the page name you are protecting).
9. Browse to protected.asp.

To password protect pages using ASP.NET

Here are steps to password protect pages using ASP.NET:

1. Create a new page in your Web site and switch to code view.
2. Select and delete all the code in the page.
3. Paste in the following code.

   <html>
   <body>
       <h1>Please Log In</h1>
       <hr>
       <form runat="server">
       <table cellpadding="8">
           <tr>
               <td>User Name:</td>
               <td><asp:TextBox ID="UserName" RunAt="server" /></td>
           </tr>
           <tr>
               <td>Password:</td>
               <td><asp:TextBox ID="Password" TextMode="password" RunAt="server" /></td>
           </tr>
           <tr>
               <td><asp:Button Text="Log In" OnClick="OnLogIn" RunAt="server" /></td>
               <td></td>
           </tr>
       </table>
       </form>
       <hr>
       <h3><asp:Label ID="Output" RunAt="server" /></h3>
       </body>
       </html>
       <script language="C#" runat="server">
           void OnLogIn (Object sender, EventArgs e)
           {
               if (FormsAuthentication.Authenticate (UserName.Text, Password.Text))
                   FormsAuthentication.RedirectFromLoginPage (UserName.Text, false);
               else
                   Output.Text = "Invalid login";
           }
       </script>

4. Save the page as loginpage.aspx.
5. Create a new page and switch to code view.
6. Select and delete the code in the page.
7. Paste the following code into the new page.

   <configuration>
       <system.web>
           <authentication mode="Forms">
           <forms loginUrl="LoginPage.aspx">
           <credentials passwordFormat="Clear">
       <user name="Bruce" password="Batman"/>
       </credentials>
       </forms>
       </authentication>
       <authorization>
       <deny users="?" />
       </authorization>
       </system.web>
   </configuration>

8. Save the page as web.config.

And that’s all there is to that. Any aspx pages in the same folder as the web.config file are protected.

I apologize for not posting much lately. I have the next installment of JavaScript 101 almost ready and will post it as soon as I have a chance to finish it. I've been hard at work writing the doc plan for the next version of FrontPage. No, I can't share what's planned (for articles or features), but I will eventually. Please be patient.

In the meantime, I wanted to share with you the IE blog. If you haven't seen the IE blog, you might want to keep an eye on it. There's an interesting post about the Internet Explorer 7 User Agent String that might be important to Web developers who have code that sniffs out the client browser. As explained in this post, you may need to make a change to your code to be compatible with newer versions of IE.

As I mentioned in the previous post, JavaScript 101: An Introduction, JavaScript is an Object Oriented Programming (OOP) language, and as such, it is comprised of objects. A bunch of objects bundled together is called an object model, also called an application programming interface (API). Each object in an object model has characteristics that describe it — properties, actions that you can take against it — methods, and actions that happen in response to other actions — events.

JavaScript is admittedly not as robust as most compiled OOP languages; the object model is simple by comparison, but in order to write, modify, or even reuse someone else's JavaScript code, you should understand the basics of an object model.

Properties — Properties describe the characteristics of an object. To use the car analogy that I used in the previous post, a car has characteristics, or properties, like make, model, and color. Often, properties have a single value. For example the make property of the car object might have a value of "Dodge"; the model property might have a value of "Durango"; and the color property might have a value of "Red." Properties can also be objects. These are called "accessor properties" because they access another object. In our car analogy, the car object might have a steeringWheel property that accesses a steeringWheel object, and the steeringWheel object may have its own set of properties, methods, and events.

Methods — Methods are actions that you can take against an object. To continue the car analogy, actions that you can perform with a car might be start, drive, and get a tune up. Some methods return values; other methods require values passed into them. For example, the start method of the car object might return a true or false (boolean value), and the tuneup method might require passing in a date for when the tune up occurs. The values that methods return are called return values; values passed into methods are called arguments.

Note   The term "parameters" is also often used to refer to the values passed into methods. The actual definitions of these two terms differ somewhat, but a complete discussion of these differences are beyond the scope of this discussion. I'll explain these terms a bit later.

Events — Events are actions that happen in response to other actions. The car analogy works here, also. For example, the car object might have an event named die to handle the possibility of the engine quitting unexpectedly, or it may have a crash event to handle the possibility if the car is involved in an accident.

Collections — Another part of an object model is collections. Collections are comprised of one or more instances, or copies, of the same object.  For example, in the car analogy, a car object might have a tires collection that has five instances of the tire object (with one tire object having the isSpare property set to true).

Don't worry if this all seems confusing. I'll explain properties, methods, events, and collections a bit more when I discuss specific objects in the JavaScript object model. However, before I describe the objects in the JavaScript object model, there are a few things you need to understand first. I will describe some of these in greater detail later, but you will need at least a general understanding of these before moving onto the specifics of the JavaScript object model.

Variables — In programming, variables are considered temporary storage. The can represent objects or data, such as strings or numbers.

Data types — Simply put, data type indicates the type of data in a variable. The three basic data types in JavaScript are strings, numbers, and booleans. String variables contain text, number variables contain ... well ... numbers, and boolean variables indicate true/false, on/off, and yes/no conditions.

Case sensitivity — JavaScript is case sensitive. This means that JavaScript considers the word "doc" and the word "Doc" as two different words and not the same word.

Arrays — Arrays are variables that contain multiple values of the same type. For example, an array of numbers could contain the values 1, 3, 45, 50, and 69 all within the same variable name. JavaScript programmers frequently use arrays to store multiple values.

So the things you learned about JavaScript in this post are

• The JavaScript object model (or application programming interface) is comprised of objects, collections, properties, methods, and events.
• Properties describe characteristics of an object.
• Methods perform actions against an object.
• Events handle actions that are performed against an object.
• Variables are temporary storage.
• Data types indicate the type of data contained in variables.
• JavaScript is case sensitive.
• Arrays contain multiple values of the same type.

This is a lot of information, but I think we're through with the basics. Next post, I'll diagram the specific objects in the JavaScript object model.

In my various lives, I've worn a lot of hats, from teaching to marketing and desktop publishing (back before there were computers for the masses) to writing text and code, and in all those lives, wearing all those hats, I've worked with my share of computer applications. As a teacher, one of the things I told my students was that if you've worked with one Windows application, you can easily transfer those skills to other Windows applications.

I, personally, think this was true for DOS applications, too, although I'm sure many would disagree, and I think this is true of many, if not most, occupations that changed with the advent of the personal computer. For example, many who worked as desktop publishers for print media became Web designers. In many ways, Web design is very much like print design, and many of the design guidelines for print media apply to the Web ... but they also don't. It's hard to explain without an example.

One guideline of print media is the importance of white space. Of course, white space isn't always "white" but rather blank or empty space that has no text or graphics. Flip through any magazine and you'll understand what I mean. The advertisements that grab your attention aren't usually those that have a lot of elements on the page fighting for attention; they are usually the ones that have a few and in many cases one main element surrounded by empty space. There may be just a few words attached to an evocative image, usually something that causes readers to feel some emotion, encouraging them to buy whatever the ad is selling. Newspapers are probably the one form of print media that gets away with using up every inch of spare space with text or images, and most do this very well because they coordinate the different elements on the pages so that they all compliment each other.

On the Internet, white space is still important, but you rarely see Web sites that incorporate huge amounts of it. In fact, the only Web site I know of that truly incorporates white space is Google.com. Most Web sites try to fill up every spare pixel of space. Some do this very well, others very poorly. I would even go so far as to say that either Web sites do it very well or they do it very poorly. There doesn't seem to be a happy medium here. If you look at some of the popular sites, like amazon.com and msn.com, you see sites that are very busy but also very well designed because they coordinate all the elements to create a uniform whole. Even advertising coordinates in color and format with other elements on the page. By the same token, you can probably find exponentially more Web sites that are just as busy but don't coordinate the elements on the page nearly as well. Usually, these pages have multiple flashing ads with several different fonts and a rainbow of conflicting colors. Usually these are the pages that you can't get away from fast enough.

My point is this: many Web designers and Web developers didn't get started as designers. We didn't take classes and get degrees in design. We sort of grew into it as our jobs changed and grew. We designed a few graphics, and everyone ooh'd and ah'd. We designed a few Web pages, and our bosses called us a Web designer. Most of us, no matter how good we are behind a camera, wouldn't publicly admit that we couldn't draw a straight line if our lives depended on it.

That's where graphics applications come in. There are a ton of graphics applications available on the market, many (IMHO) so overpriced that even a veteran graphic designer couldn't use them enough to pay for them. However, there are some really good graphics applications available (some relatively inexpensive) that can make even non-designer developer-types look really good. Here are my favorite.

Paint. Okay, I'll say it again ... Paint. Everyone knows what it is, but many refuse to acknowlege that they use it. Everyone one who has Windows has it, and for the money (free), there are few graphics applications that are better. Okay, so you may not want to create a lot of intensive graphics in Paint, but there are some very cool things that you can do in Paint that you can't do in other graphics applications. For example, let's say you're designing a Web site or developing a Windows application and all you want to do is add a screen shot to a document or modify it just slightly.

Most if not EVERYONE knows that you can press Print Screen to take a screen shot (Alt-Print Screen to get just the active Window or dialog box), and since this copies a bitmap of the screen to the Windows Clipboard, all you need to do is paste the results into any document. But what if you need to edit it? Perhaps you're writing a spec and need to edit out or change some portion of a dialog to create a new look; perhaps you're creating a training handout that describes portions of an application and need to add callouts. There are a million and one reasons why you might want to edit a screen shot, and I don't know of another graphics application (at least not for the cost of Paint) that allows you to edit a bitmap pixel by pixel.

Now some of you are probably thinking right about now that you can't use bitmap images on the Internet, and yes, that is true (or rather you can but they're not as good as GIF or JPEG and not useful across platforms, etc.), and while you can save GIF files in Paint, the color fidelity isn't good, so I'd like to introduce you to another tool that costs just about as much as Paint.

Office Picture Manager. If you have any Office System 2003 application (and if you have FrontPage 2003, you have an Office System 2003 application), you get Office Picture Manager free. Yes, you read that correctly ... gratis. And you can do some pretty nice things with Office Picture Manger. You can save a bitmap as a GIF ... or JPEG ... or PNG ... or TIFF ... or you can save any one of those as any one of the other. You can change the colors, crop, rotate, flip, resize. There is only one thing that you can't do with the current Office Picture Manager that you could do with its predecessor (the one in Office 97, Office 2000, and [I think] Office 2002), and that is specify a transparent color. IMHO this is sad for those of us who work with Web images, but in every other way, the Office Picture Manager included with the Office System is a better application.

The scenario would go something like this: take a screen shot, paste it and save as a BMP in Paint, open it in Office Picture Manager, and export it into the format of my choice, usually gif. I often use Office Picture Manager to convert bitmap graphics and screen shots that I use in my articles to GIF and to resize them as appropriate to meet MSDN guidelines. Although more recently I've been using a different product, Office Picture Manager is a great choice and definitely a great tool to keep in your toolbox for working with graphics of any kind.

PaintShop Pro. This is a non-Microsoft graphics program developed by Jasc (www.jasc.com) that I've worked with, and compared to high-end graphics applications like Adobe PhotoShop, it's a terrific application for creating and manipulating graphics of all kinds. I love to use the different effects on photographs and for the money, this is an awesome application. I especially love that I can see what my image looks like with a proposed change before I make it. If I don't like what I'm seeing, all I have to do is click Cancel and my image remains unchanged. I'm sure I don't use it to its full capabilities, but I definitely like to keep it around for working on Web graphics. (As a side note, I actually preferred PSP 7.0 to PSP 8.0, but I have PSP 8.0 because it was the only one available when I purchased, and although it is good, IMHO 7.0 was better.)

A while ago I found instructions for creating repeating designs, which are great as background images for Web pages, in PSP 7.0. I can't remember if I tried the steps in 8.0, I've since forgotten how, I don't remember the URL, and a quick look at the PSP 8.0 UI doesn't provide any clues, but in 7.0, it was a simple task of selecting part of a larger graphic and selecing a "make repeating graphic" command. I don't see the same command in 8.0, so I don't know if it's possible. However, even with this deficiency (which is relatively minor since I don't use repeating designs on Web pages), PSP 8.0 is an excellent graphics application.

Picture It. For all the things for which I love PSP, I love Microsoft Picture It, but for working with photographs, I've never worked with a simpler, better application. It has some great tools for cleaning up photos, like adjusting the angle on crooked photos to erasing flaws. About a year ago, I had the opportunity to use it on photos for a furniture Web site, and I was amazed at how well it worked. For photos that had too much glare, Picture It allowed me to cut the glare and deepen the colors to a richer tone; for photos that were too dark, I could lighten them without losing definition. I've never gone googoo gaga over a graphic program, but this one gives me hours of enjoyment.

Visio. Recently, I've used Visio more freqently for creating images for articles, especially if the image isn't a screen shot, but Visio has a feature (IMO) that is very important for Web designers and developers beyond the ability to create or save images in Web-compatible formats. With Visio, you can create a map of a proposed Web site (which you can probably do in most graphics applications) and you can also map out the structure of an existing Web site just by providing a URL. If this ability exists in other graphics applications, I admit that I've never seen it. I was first introduced to this feature years ago (perhaps even before Microsoft acquired Visio), and I've found it a very useful tool when working with Web sites. As long as a site has pages that have links, Visio can map the structure of the site. The default is 3 levels deep and 300 links, but you can adjust these settings as you need to. Visio is, admittedly, the pricier of the graphics applications listed here, but if you work with multiple Web sites (perhaps as a consultant) or manage a medium to large web corporate site, this one feature alone makes the cost of Visio worth the expense.

Gif Construction Set. As I said, I've worked with a lot of graphics applications, but this is the only one I've worked with that allows you to create really cool text effects. You can do a lot more with it, like animated gifs (if you've read even a few of my posts, you've figured out how much I "love" animated gifs), but text effects is what I've used it for most. If you've spent any time at all working with Web sites, you know that in order to show special fonts on Web pages, either the visitor needs the font on their local computer or you create graphics to show the font. Gif Construction Set, developed by Alchemy MindWorks (www.mindworkshop.com), allows you to create very cool text effects with any font installed on your computer. You can set shadow effects, create outlined text with fonts that aren't outlined to start with, create scrolling text marquees (okay, yes, an animated gif, but it's text!), and a host of other special effects. For a great price, you get a great tool to add to your toolbox, and if you're unsure whether it will suit you, I think you can still download a demo so that you can try before you buy. (If I'm not mistaken, it's a full working version except that the images have text written across them until you register ... if I'm not mistaken.)

Of course, these are only a few of the graphics applications available, and most are much more expensive than the ones I've included here, but all of these (IMHO) deserve a place in a professional Web designer/developer's graphics toolbox.

If you've worked with Code view in FrontPage 2003, you've undoubtedly come to appreciate IntelliSense. But what if you need an element or attribute that isn't included in any of the default HTML schemas? For example, W3C accessibility guidelines include a headers attribute for TD elements. If you frequently use the headers attribute, love hand coding, and are tired of typing "headers" everytime you need to insert this attribute, this tip is for you.

Background

FrontPage uses XSDs (XML Schema Definition documents) to provide IntelliSense in Code view.  In fact, this is the same as what Visual Studio uses to provide IntelliSense for HTML and XML schemas, and FrontPage even uses many of the schema annotations that Visual Studio uses.  Schema annotations are contained in the schema definition (i.e., <xsd:schema ... >) listed at the beginning of an XSD.  (For more information, see Visual Studio .NET Schema Annotations.) However, you should note that FrontPage does not use all of these annotations, so be careful using annotations or annotation values other those included in existing FrontPage IntelliSense schemas.

In addition, FrontPage provides IntelliSense only for HTML (including XHTML), not XML. So if you are inclined to playing with this feature by adding custom elements or using a custom XML schema, you may quickly find that IntelliSense for a selected schema won't function as expected or desired. However, making simple changes to existing HTML schema files (which I show you how to do in the procedure below) allows you to create some custom HTML IntelliSense.

You should also keep in mind that although changes you make may validate in Visual Studio or another XSD editor, FrontPage may not be able to understand them, which more than likely will break IntelliSense for all documents that use that schema.  Whenever possible, work with the XSD source code (such as in Notepad or XML view in Visual Studio) rather than with a visual XSD designer and make simple changes.

Note   Breaking IntelliSense does not mean that IntelliSense will not work at all. Rather, IntelliSense won't work for documents that use a specific IntelliSense schema that FrontPage doesn't understand.  IntelliSense will work for other IntelliSense schemas.  Simply select a different schema from the Schema Version option on the Authoring tab of the Page Options dialog box.

More important things to remember when playing with IntelliSense schemas are

• always copy the schema file so that you don't overwrite the original schema making it impossible to recover the original schema without reinstalling FrontPage 
• always change the vs:friendlyname annotation value at the beginning of the XSD so that you can differentiate between existing schemas and your custom schema (this value shows up under Schema Version on the Authoring tab of the Page Options dialog box)
• don't make too many changes before testing the schema in FrontPage (and always create a backup of your changes XSD before making additional changes in case an additional change breaks Intellisense)
• never replace an existing schema with a custom schema (just in case a future service pack or update replaces this file, destroying all of your changes)

Procedure

Okay, now that you know all the gochas, the following instructions explain how to add the headers attribute to a custom IntelliSense schema.  You can use these basic instructions to create additional IntelliSense schemas for FrontPage.

1. Close FrontPage.
2. Open Windows Explorer and navigate to:
   C:\Program Files\Common Files\Microsoft Shared\OFFICE11\SCHEMAS\HTML
   This folder contains the schema and type libraryfiles that FrontPage uses for IntelliSense. All the XSD files are IntelliSense. For example, ie3_2nav3_0.xsd contains IntelliSense for IE 3.2 and Netscape Navigator 3.0.
3. Copy IE5_0.xsd and change the name of the copied file to IE5_0_Modified.xsd. Copying makes sure that you don't overwrite the original file. DO NOT SKIP THIS STEP.
4. Open the new file in Notepad.
   Note You can also use Visual Studio or another XSD editor. However, you should note that if you use something other than Notepad, you will need to view the source of the XSD in order to follow the remaining instructions.)
5. In Notepad, turn off Word Wrap (Format menu). (This makes the schema easier to read and work with.)
6. In the opening XSD statement, locate vs:friendlyname="Internet Explorer 5.0" and add the word "Modified" to the friendly name so that it reads: vs:friendlyname="Internet Explorer 5.0 Modified"
7. Search for: name="td"
8. Scroll down to the list of attributes for the TD element.
9. Add a new attribute for "headers". For example, add the following text under one of the existing attributes. (I placed it beneath the id attribute, but you can put it beneath any attribute for the TD element as long as you don't add it between the opening and closing tags of the attribute element for another HTML element.)
   <xsd:attribute name="headers" />
10. Save the file.
11. Start FrontPage.
12. From the Tools menu, select Page Options.
13. On the Authoring tab, under Schema Version (at the bottom of the dialog box), select Internet Explorer 5.0 Modified.

If you did everything right, when you add a TD element in Code view, you will find the headers attribute listed in the IntelleSense. The IntelliSense feature in FrontPage is very sensitive, so if you don't follow these instructions exactly, it may break Intellisense for your schema. Also, you can't make changes to the XSD while FrontPage is opened (or rather you can, but if you do, Intellisense will not function properly). You need to reboot FrontPage before IntelliSense schema changes take effect.