For an extension project I was working on, Design Notes seemed like a great candidate to store information about the users settings. Generally they work very well using the MMNotes object to store and retrieve data.

I wanted to store file paths as the key name to track the settings on a per file basis, and then a date for the value to indicate when a file was last edited by the extension. So to test out my reporting mechanism, I generated a demo notes file contains some sample file paths, and sample dates. I carefully made sure to match the file format for the .mno files that I've found.

However, I ran into an issue where my reporting based upon the content in the design notes file (.mno) wasn't giving me the info based upon what I knew was in the notes file from looking directly at its code. The file paths were getting truncated so that only the first 63 characters were recognized.

To see this in action, you can use the following code:

var dom = dw.getDocumentDOM();
var url = dom.URL;
var metaFile = MMNotes.open(url, true);
if (metaFile) {
// 63 character key name
var settingName = '123456789012345678901234567890123456789012345678901234567890123';
var value = 'value here';
MMNotes.set(metaFile,settingName,value);
// 70 character key name
var settingName2 = '1234567890123456789012345678901234567890123456789012345678901234567890';
MMNotes.set(metaFile,settingName2,value);
MMNotes.close(metaFile);
}

metaFile = MMNotes.open(url, true);
if (metaFile) {
var keys = MMNotes.getKeys(metaFile);
for(var i=0;i alert(keys[i]);
}
}
MMNotes.close(metaFile);

You should get an alert that displays the 63 charater key name, but not the 70 character key name.

So keepthis limitation in mind when you're working with design notes programatically through the MMNotes object.

Do you ever get into a situation where you write an e-mail that you think is honest, to the point and basically about the facts but then someone else reads that e-mail and thinks "Oh my gosh! I can't believe you went off like that!!!" and so, for the rest of the day, you spend your time reading and re-reading the e-mail thinking "what did I say that was so harsh or so bad?".

Those of us that work in the "corporate field" or are part of a committee of some sort might relate to what I am talking about. I'm in such a situation right now.

You see, I work in one of those corporate environments and we tend to design web sites by committee (not the easiest thing in the world to do, let me tell you!). And part of my many responsibilities is to make sure all of our web sites follow a very specific set of guidelines. Unfortunately - and on occasion - a "rogue designer" will create something that, on the surface level, looks really nice but hasn't followed any of those very specific guidelines. Now, his immediate superiors might like what he has done as well, but in the overall scheme of things, the guidelines still weren't met or were completely ignored. So, I'll have to play "bad guy" and mention such a thing and reiterate to all involved exactly WHY something can't be done or published to the web.

I just sent such an e-mail and, for the life of me, I can't see where one of my co-workers sees the "anger" and "hostility" in my typed words. I've re-read this sucker three times now and I STILL don't see what they see. I don't see "anger" in my words. I see facts. I don't see "hostility". I see an insistence on maintaining rules. I don't even see "frustration" either. I see, instead, questions about how a particular decision came to be.

Isn't that the crazy thing about e-mails, though? How one person can "interpret" the feelings and inflections in a person's voice when there really isn't any there? Do we - when we read an e-mail from someone we know - automatically IMAGINE what and how they are speaking and this CAUSES us to come to our conclusions? What makes us "see" the emotions in an e-mail? And, in some cases, respond to them in kind?

In any case, I'm probably going to have to send another e-mail explaining what I'm NOT feeling or what I DIDN'T intend. Ahhhh well. Such is the life in the age of faceless communication.

Too bad it's not entirely devoid of emotion though. Real or not.

:-)

Chris Flick

Although Dreamweaver extensions can be written in HTML, there are a few things that the HTML within an extension cannot do, probably the most frustrating to a developing extension developer is that links do not work the way they do in HTML. For example, to create a link on a web page that delived the user to your company's help page would use code similar to the following:

<a href="http://www.example.com/help/">Help me!!!</a>

However, within a Dreamweaver extension, this code won't work. Particularily frustrating about this code is that it will actually look like a link within the extension, but clicking it won't do anything. So what's a developer to do? The Extending Dreamweaver documentation covers this situation in a round about way. For DWMX2004 it is located here:

Help > Extensions > Extending Dreamweaver > Extension APIs > How Dreamweaver processes JavaScript in extensions

This is what it says:

Dreamweaver supports the use of event handlers within links. Event handlers in links must use syntax, as shown in the following example:
<a href="#" onmousedown="alert('hi')">link text</a>

What it doesn't say here is that the href attribute is ignored. They also don't say that the onclick event isn't recognized for the <a> tag. So if you want to send your visitors over to your help page, you'd have to use the dw.browseDocument() API call within the event to open a browser and send your user onto your web site for support. Your code will look something like this (line feeds added for clarity):

<a href="#"
onmousedown="dw.browseDocument('http://www.example.com/help/');">
Help Me!!!
</a>

Now, if you want to have your logo clickable and have the user go to your home page, you'd have to do something a little different because when an lt;img> tag is wrapped with a link, the link's event's aren't triggered. To use an image as a link, within a Dreamweaver extension, you'd need to use code similar to the following (line feeds added for clarity):

<a href="#">
<img src="alert_icon.png" border="0" height="100" width="100"
onMouseDown="dw.browseDocument('http://www.example.com/help/');">
</a>

Note: Dreamweaver MX 2004, displays the hand pointer as expected when the mouse pointer is over a linked image, but Dreamweaver MX does not do this, even though the image is linked.

A recent visit to the Motorola site made me realize how much usability really does matter and how much truth there is behind those old rules.

My mom needed a manual for her cell phone. Motorola had told her to go to their web site and download it, but she couldn't get it to work and asked for my help.

I went to www.motorola.com. Not being a Motorola owner (or a cell phone owner, for that matter), it was my first visit. The first place I looked for a link was along the top. They have three buttons along the top by their logo, but they were all corporate stuff. I then saw four buttons at the top right: At Home, At Work, In the Auto, On the Move. None of those cryptic buttons sounded right.

I finally spotted it: in a sidebar on the right (ironically labeled "Fast Find"), in tiny gray text on a gray-blue background, the words "Cell/Mobile Phones." I clicked. A list of phones popped up, and I scrolled through. None was what I wanted, so I clicked on "View all phones" at the bottom. Then I was presented with a list of countries that I had to select from, but instead of using a regular drop down list, it was a Flash-based widget with only an up and down arrow. So, I couldn't just grab the scroller, drag it to the bottom, and select United States. Instead, I had to hold the down arrow down until it finally got to the US. It only took 8 seconds, but when something takes 8 seconds that should have taken 0.5, we web users get mad.

After selecting US, I went to a US portal page where I had another box to select my phone from. Since my phone wasn't listed (turns out mom gave me a slightly wrong name), I hit back to try my luck on the home page again. I had to navigate through the Flash widget again. This time, I selected "Downloads," because I needed to download a user manual. It then presented a little graphic saying I could get my hands on games, ringtones, etc. Oops – this didn't sound like what I wanted. I wanted to go back and choose "Support" instead of "Downloads." But there was no way to get back! (Turns out the widget did have a back button, but I didn't see it all the way at the bottom.) I would have to hit refresh, scroll through that list of phones again, then select "Support." After selecting support, I had to select US again. Guess where it sends me? The same US portal site as before, not the support page! So, I had to search around on that page and select Support, even though I told it back on the home page that I wanted support. Talk about unneccessary clicks.

On the support page, it was easy to find the link to Manuals. Finally! On the Manuals page, I selected a category of manuals, Phones. I then went to the next drop down box to select my particular phone. But the list was empty. Suspicious, I loaded up the same page in Internet Explorer (I use Firefox as my default browser). Sure enough, the select box worked in IE. Now I was really mad. They were using some cheap, lazy Javascript that wouldn't work on Firefox. How irresponsible of Motorola, a site that must receive millions of hits, to exclude so many users of their site! If they are going to require you to use their site to receive support, they need to make sure it is accessible to all.

Now forced to use IE, I attempted to locate my mom's cell phone in the list. It wasn't there. After looking a few more times, I finally spotted it. Her cell phone, 280, was not at the top of the list with the other numerical phones. It was stuck in the middle of a bunch of phones starting with V. Why? Who knows. Motorola apparently doesn't know how to alphabetize either.

The whole process was protracted and difficult – and I'm a web designer who knows my way around a site! Web developers, I beseech you – don't do this to your customers.

Four months ago a purple sauropod suddenly appeared on the bleak, volcanically active White Island, off New Zealand. Holly did some web research and discovered the identity of the dino to be, well, Dino!

There happens to be an hourly webcam on the island, so we can keep tabs on everybody's favorite cartoon dinosaur

After Dino became world-famous, the geo-survey head honcho stated that the caustic vapors of the island would make short work of our plastic buddy, but it looks like he's made of sterner stuff. Go Dino, go!

Quartz technology on OS X and ClearType on Window XP -- the answer to all our pixely type woes. For ages now I've been telling people that their XP machine can display fonts so well that we can now use CSS to style headers and nix the whole header image routine. (I even wrote an article about it last year -- Styling Headings for Fun and Profit with CSS.) No more of that pixely, horrid stuff -- everything will be smooth and lovely. And then I bought a testing box with XP on it. And it was not lovely. It was pixely and gross. Had I been lying to people all this time? I was alarmed. I looked for a setting within XP but to no avail.

I discussed this with Kim C., and he dug around and found the solution. The ClearType text smoothing ships in the OFF position. Yup, that's right. Microsoft added the beautiful ClearType smoothing to XP, but Joe and Jane User have no clue. And I, who had a clue, couldn' t find it. Just in case you're one of the clueless gang and you'd like a more beautiful web typography experience, here are the steps I took:

1. Right click on your desktop. The Display Properties panel will appear.
2. Click the Appearance Tab.
3. On the bottom right side, click the effects button.
4. Click the second item that says: "Use the following method to smooth edges of screen fonts." Select ClearType.
5. Click OK
6. Click OK in the Display Properties panel.

Now open a web site, or simply view this blog again. You'll notice the headings look almost as good as they do on a Mac. ;) Enjoy!

ESPN Motion Showcase: I came across this from a post at Macworld Editor's Weblog, which is significant because Mac users had previously been shut out of some of the broadband video offerings that media outlets are providing. ESPN's solution? Switch to Flash video and your cross-platform problems are solved.

Max Design, a Sydney, Australia-based design firm, has posted a comprehensive checklist of web design standards. As they say, designing to standards means to

"adhere to standards (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) and pursue best practices (valid code, accessible code, semantically correct code, user-friendly URLs etc). In other words, a site built to web standards should ideally be lean, clean, CSS-based, accessible, usable and search engine friendly."

This is an excellent one-stop source for the kinds of things that modern web developers and designers should keep in mind when developing new sites with standards in mind. It's hard to imagine any professional developer who doesn't at least attempt to design to standards these days. For those still learning what the mysterious "standards" are, this checklist not only gives excellent short descriptions, but also provides relevant links to documents that provide more information.

Via Digital Media Minute.

Avast! This may not be on your list of important dates to remember, but it doesn't seem right to let today go past without noting that today is International Talk Like a Pirate Day. So me buckos, be sure you're talkin' like a pirate today, or ye may find your timbers shivered and yer grog watered down. If you're not sure how to talk like a pirate, this glossary of pirate terms may come in handy. Arrrrrrr!!

Just a reminder about the presentation I'll be doing on extension building for Dreamweaver on Monday Sept. 20:

Building a Better Dreamweaver, Sept 20, Chicago

Dreamweaver users on XP boxes that have been upgraded with SP2 have reported problems connecting to databases with their ASP.NET pages. If you've gotten wierd errors trying to create MM:DataSets or build OLE DB connections, check out this Dreamweaver support document at http://www.macromedia.com/support/dreamweaver/ts/documents/dw_xp_sp2.htm

The ASP.NET so-called "workaround" is to use a testing server not running XP SP2. Sorry folks.

The second ASP.NET problem discussed in this support document: "Build" button does not work in ASP.NET OLE DB connection dialog -- affects Win2k users, too, not just XP SP2. I'm pretty sure this it also has to do with MDAC 2.8 since I just did my Windows update, which included MDAC 2.8, and now can't use the Build button. The workaround to use templates worked great for me.

The technote has other important info for XP SP2 users, besides the ASP.NET stuff, so check it out if you've upgraded to SP2.

My power is back on as of yesterday, and after 12 days of urban camping, life is beginning to return to something close to normal.

Even with the sweet joy of a cool home and the modern conveniences that we're accustomed to, things somehow seem different. After being displaced from our regular life for so long, facing the tasks ahead to complete the clean up and get on with life still seem monumental. Perhaps I'm suffering from Post Hurricane Traumatic Stress Syndrome--a condition which I just made up, but which seems very real to me. I'm not sure. But even though I can once again sit at my beloved Mac and get back to work, there is much that remains to be done in picking up, cleaning up, and putting things back in their normal places. One of your local newspaper columnists, Frank Cerabino, captured that displaced feeling very well in talking about how he felt when his power finally came back on:

"It felt defeating, not to be able to feel comfortable in your own home. To have to be out in the world, at restaurants, at friends' houses, at a mall — someplace other than your own little sanctuary, that dark, sticky place that had changed from a home into a huge, unwelcoming storage shed for your things.

I could think of nothing more appealing than feeling normal again. To eat at home. To fall asleep watching TV. To get up in the morning and make a pot of coffee, rather than getting in line at the Dunkin' Donuts.

To have the luxury of feeling bored by routine, even."

I'm waiting for that bored routine feeling to return for me. Maybe in a few days when the mounds of laundry are washed and put away, the extension cords that are still snaking around in the house are out of sight, and the air mattress that we've slept on for nearly two weeks is deflated and the outdoor patio returned to a place to visit and not one in which you attempt to live.

You know, when the power company announced last week that it might be September 17th before everyone in my county got power restored I laughed. "Hah!" I chortled, "wonder who the poor shlub will be who has to go without electricity for all that time?" Turns out that it just might be me.

Thanks to the fabulous Florida Power and Light web site I now know exactly what's wrong and what's being done to resolvbe the issue. Nothing. Here's the text of the message I received after reporting the outage at my house:

We have identified a power problem affecting your location.

The problem is with a transformer and it affects 18 customers.

At this time we have no available estimated time of power restoration.

We apologize for the inconvience this power outage has caused you. Thank you for your patience.

Patience? PATIENCE!!!???? I'll show you some friggin' patience. Just come on over here around 11 p.m. when it's still too hot to fall asleep, even on the screened patio. I'm REAL patient right about then.

Oooops. Sorry. Back to my cheerful demeanor.

For those of you living under a rock lately, Firefox is becoming one sexy little browser. Even Forbes has mentioned it saying "Microsoft should be worried." I've been through most of the Mac flavored web browsers -- beginning with Internet Explorer, then to Safari, to Opera, to Camino, to Firebird and finally I've settled on Firefox. I love it. It's quick, blocks pop ups, gives me tabbed browsing, and best of all, the extensions rock!

My favorites are the Web Developer's Toolbar and Sage. The Web Developer's Toolbar (by Chris Pederick) gives me the ability to view a tremendous amount of information about a page, outline the table cells, edit the CSS, turn off images or JavaScript. I'm not sure how I worked on my sites before I had it. Sage (by Peter Andrews) is a cool RSS feed reader that extends FFox. I only found it recently, through my friend Andrew Jeffery, and I've really enjoyed having the headlines at my fingertips.

But now, enter the Preview Release of Firefox. It appears from their site that perhaps they've married the Sage functionality into the browser itself. I'm downloading now, so I'll soon know. But the site says, "Live Bookmarks is a new technology in Firefox that lets you view RSS news and blog headlines in the bookmarks toolbar or bookmarks menu. With one glance, quickly see the latest headlines from your favorite sites. Go directly to the articles that interest you -- saving you time." Sounds pretty close to Sage functionality to me.

Click that cute icon if you'd like to download the Preview Release. If you're already a Firefox convert, or you become one on this round, help spread the news. Maybe we can even slow down calls from clients about their computer problems if we can get them all hooked on a more secure browser. And check out their new site Spread Firefox where you can get your own cute little icons!

Obsessive. Wrapped up in work. Devoid of real friendships. Just some of the names I've been called since starting in this business a few years ago. I really do try to have activities outside of the web. And all of them are in the schedule so that they pop up in front of my face shortly before they're due to occur. Otherwise, I would sit here picking apart code and a friend would get married or something ... and I'd be none the wiser. ;) The only exercise I get (to avoid the curse of chair butt) is Beach Volleyball. Great exercise, I'm on two teams -- but the one I'm co-captain of is called, you guessed it, SandyGeeks.com. Yes, I am co-captain with yet another web developer in town. We may be sick, but hey -- we're playin' ball!

Writing code in my sleep, or lying awake at night solving a client's problems is one thing... but I think the most frightening thing about this web illness is when I mess up in life. You know -- somtimes you do something you want to change. And many times my first automatic thought is, "Cmd/Z" -- and suddenly I realize I'm in the kitchen, or on the volleyball court. Darn good thing people around me can't see inside my brain. I'd be committed. And why the heck can't I Cmd/Z in life anyway? It would be so much simpler.

A little boring given all the fun items that Paul Boon has been blogging about...

I frequently need to determine if an item is within an array. For example, in my extension CMX Create Include I have an array of file types that the extension can create includes for. When the extension loads up, in the initializeUI() function, I check the server model that the current document belongs to using dom.serverModel.getServerName();, so that within the list of avialable include types, I can automatically select the proper type of include.

So now, I need to find the position within the array that I need to select. to do this, I wrote a short utility funciton that will return the index within an array that the passed in item matches. If the item isn't present, then it returns -1. So here's the function:

function indexInArray(theArray, theValue){
var arLength = theArray.length;
for(var i=0; i
if (theArray[i] == theValue){
return i;
}
}
return -1;
}

Example usage

var mySites = site.getSites();
var mySite = 'CommunityMX';
var idx = indexInArray(mySites, mySite)
if(idx >-1){
alert('Found a great site at '+ idx );
}
else{
alert('Did not find the specified site');
}

For the most part things are beginning to look somewhat normal here in Palm Beach County again. My street is free of the piles of debris now, and there are more and more traffic lights functioning. Stores and restaurants are open for the most part, and people are getting back to their lives.

The killer is still the lack of electricity. Today is the 10th day without power at my house, and it looks like our local power company was right in estimating that it would be the 17th (!) before we all have air conditioning, working refrigerators, lights, and all the other simple pleasures that modern life brings with it. Sleeping in a real bed is high on my list, something I haven't done since Frances whacked us 10 days ago. I think I'm fairly well over my web withdrawal symptoms. Yes, I can get online, but once you're used to high-speed access it's tough to go back to dial-up. That and it's just too darn hot to sit in the house connected to the phone line so you can go online.

I'm heading back to work today, which will be a nice return to normalcy after 8 days off. If any of you happen to see one of those white electric company trucks would you please give them directions to my house? It's the one with the camp stove and air mattresses on the back porch. Thanks.

Dreamweaver ships with a custom control called the treeControl, this control allows data to be displayed in a tree, similar to the tree of the File & Snippets panel.

To use this control within your extension interface you use a MM:treeControl tags and the elements of the tree are displayed using MM:treenode tags.

If you are working with Dreamweaver's menu system and want to display the contents of the menus.xml file within a treeControl. You could either walk the xml nodes of the menus.xml files DOM, dynamically produce the html required to represent the menus.xml DOM as a collection of treenode elements, then insert this into your treecontrol using the innerHTML property of the treeControl.

Alternativly you could use the undocumented call getMenuTree() that returns an Object that contains Dreamweaver's menu system as a collection of treenodes.

This call was originally developed to allow shortcut keys to be easily mapped to menu items when using the Edit > Keyboard Shortcuts... option.
Due to the amount of time it would take using Javascript to walk the menus.xml file to gather all the information required, DW Engineers wrote the getMenuTree() API in C++. However this does not stop us using the call to get the parts of the menus.xml file in other extensions.

The object returned by the call contains a child collection of nodes as an Array of Nodes, a names Object and a keys Object.

accessable by using returnedObject.nodes, returnedObject.names and returnedObject.keys

In the Example below which is a htm file that you can save in the Configuration/Commands folder, you see first the doc type tag telling Dreamweaver to render this htm file using the CSS for a DWExtension dialog.
Inside the head tag we have the script tag that contains the function that we want called as the document loads, in this case doOnLoad() function.

You will see that the getMenuTree() function requires a number of parameters with the first parameter being the path to the menus.xml file and to do this we are using the undocumented call dw.getMenuFile() I mentioned in a previous blog.

Also required is the tag name we are interested in, the menus.xml file contains the references to shortcut keys defined using shortcut tags and menus defined using menubar tags. As we are interested in Dreamweaver's menus we are using 'MENUBAR' as the second parameter.

For the third parameter we are passing in the unique ID of the particular MENUBAR tag we are interested in and this is the menubar that represent Dreamweaver's main menu, this being 'DWMainWindow'.

The last parameter tells the API call to ignore child menuitems id attributes, and in this example we are passing in false.

The body tag in the example has the onload Attribute set to call the doOnLoad() function, and contains as a child tag Dreamweaver's custom UI Treecontrol tag, this tag is used to render the captured menu structure as a clickable tree.

AS the doOnload function is called the variable menuTree is assigned the returned object that contains the collection of nodes for the part of Dreamweaver's menu we are interested in. Then the treecontrols innerHTML is assigned the nodes array using the line of code document.myTreeControl.innerHTML=menuTree.nodes

Example of use:

<!DOCTYPE HTML SYSTEM "-//Macromedia//DWExtension layout-engine 5.0//dialog">
<html>
<head>

<script>

function doOnLoad(){
var menuTree = dw.getMenuTree(dw.getMenuFile(),'MENUBAR','DWMainWindow',false);
document.myTreeControl.innerHTML=menuTree.nodes;
}

</script>

<title>dw.getMenuTree() Demo</title>
</head>

<body onLoad="doOnLoad()">

<form name="theForm">

<mm:treecontrol name= "myTreeControl" id="myTreeControl" style="width:380px; " size="12" noheaders>
</mm:treecontrol>

</form>

</body>
</html>

To see what the command does simply copy the above code into a .htm file and save it as getMenuTreeDemo.htm in the configuration/commands folder and then restart Dreamweaver. Once restarted you will see a getMenuTreeDemo option in Dreamweavers main Commands menu.

Dreamweaver ships with a custom control called the treeControl, this control allows data to be displayed in a tree, similar to the tree of the File & Snippets panel.

To use this control within your extension interface you use a MM:treeControl tags and the elements of the tree are displayed using MM:treenode tags.

If you are working with snippets and want to display the snippets folder and its contents within a treeControl.

You could either walk the file structure of the snippets folder, dynamically produce the html required to represent the Snippets file system as a collection of treenode elements, then insert this into your treecontrol using the innerHTML property of the treeControl.

Alternativly you could use the undocumented call getSnippetsTree() that returns an Object that contains the snippets folder as a collection of treenodes.

This call was originally developed to allow shortcut keys to be easily mapped to snippets folder when using the Edit > Keyboard Shortcuts... option.
Due to the amount of time it would take using Javascript to walk the snippets folder and menus.xml file to gather all the information required, DW Engineers wrote the getSnippetsTree() API in C++. However this does not stop us using the call to get the Snippets folder structure in other extensions.

The object returned by the call contains a child collection of nodes as an Array of Nodes, a names Object and a keys Object.

accessable by using returnedObject.nodes, returnedObject.names and returnedObject.keys

In the Example below which is a htm file that you can save in the Configuration/Commands folder you see first the doc type tag telling Dreamweaver to render this htm file using the CSS for a DWExtension dialog.
Inside the head tag we have the script tag that contains the function that we want called as the document loads, in this case doOnLoad() function.

You will see that the getSnippetsTree() function requires a path to the menus.xml file and to do this we are using the undocumented call dw.getMenuFile() I mentioned in a previous blog. This is because as mentioned above, this call was originally developed for the edit shortcut keys command that ships with Dreamweaver and the menus.xml holds all Dreamweaver's keyboard shortcuts.

Although we pass in the parameter we are not interested in shortcut keys assigned to snippets, we are just interested in getting the snippets folder structure.

The body tag in the example has the onload Attribute set to call the doOnLoad() function, and contains as a child tag Dreamweaver's custom UI Treecontrol tag, this tag is used to render the captured snippets structure as a clickable tree.

AS the doOnload function is called the variable snippetTree is assigned the returned object that contains the collection of nodes. Then the treecontrols innerHTML is assigned the nodes array using the line of code document.myTreeControl.innerHTML=snippetTree.nodes

Example of use:

<!DOCTYPE HTML SYSTEM "-//Macromedia//DWExtension layout-engine 5.0//dialog">
<html>
<head>

<script>
function doOnLoad(){
var snippetTree = dw.getSnippetsTree(dw.getMenuFile());
document.myTreeControl.innerHTML=snippetTree.nodes;
}
</script>

<title>dw.getSnippetsTree() Demo</title>
</head>

<body onLoad="doOnLoad()">

<form name="theForm">

<mm:treecontrol name= "myTreeControl" id="myTreeControl" style="width:380px; " size="10" noheaders>
</mm:treecontrol>

</form>

</body>
</html>

To see what the command does simply copy the above code into a .htm file and save it as getSnippetsTreeDemo.htm in the configuration/commands folder and then restart Dreamweaver. Once restarted you will see a getSnippetsTreeDemo option in Dreamweavers main Commands menu.

This is a bit of a did you know blog.

Did you know that, at some time during Dreamweaver's development, snippets were going to be defined in an xml file called index.xml, this file would probably have held the shortcut key definitions that can be assigned to snippets using the Edit > Keyboard Shorcuts.. command. This xml file was going to be stored in the root of the configuration/snippets folder. How do we know this was the case? The answer is simply that an undocumented API call dreamweaver.getSnippetsFile() returns a file url that points to this index.xml file.

Example of use:

var nonExistantSnippetsFile=dw.getSnippetsFile();

Note: Using this call is pointless as the snippets file does not exist