From the time Macromedia launched Dreamweaver and introduced the ability for everyday users to extend the product by developing extensions, one extension type was missing, the Toolbar extension. With the release of Dreamweaver MX, extension developers finally got the chance to customize Dreamweaver's toolbars.

Toolbar based extensions are extremely useful, each button or item on a toolbar can be used to launch a single feature/function or by the use of popup menus can be used as the launch point for a group of features/functions. They take up a small amount of screen real estate and allow functions/ features that otherwise might be berried within the menu system to be no more than a mouse click away.

When developing a toolbar item you can choose from eight different base item types, those being Button, Checkbutton, Radiobutton, Menubutton, Dropdown, Combobox, Editcontrol and Colorpicker.

The toolbar items are defined in an xml file called toolbars.xml. Each toolbar is deinfed using a Toolbar tag and toolbar items are defined as child tags, using one of the eight item types i mentioned before.

<toolbar id="DW_Toolbar_Main" label="Document">
  <button id="MyButton"
    command="alert('hello mum') "
    enabled="true"
    image="Shared/images/alert_on.gif"
    disabledimage="Shared/alert_off.gif"
    tooltip="hello mum."
    update="onEveryIdle" />
</toolbar>

Whilst toolbars and toolbar items are easy to define, one of the main issues developers find is the lack of ability to dynamically change a toolbar item tags attributes at run time, and for those changes to be effective within the current active session.

Developers often ask if its possible to change a toolbar items defined image at runtime or want to change the tooltip that appears when the users mouse passes over a toolbar item.

Changes made to a toolbar items definition only take effect the next time Dreamweaver is restarted or after a forced reload of Dreamweaver's extensions, using the Dreamweaver.reloadExtensions() API call.

It would be nice to be able to change a toolbar items defined attributes and for the change to take effect on the fly, without doing a restart or using the dw.reloadExtensions() API call. Thanks to an undocumented API call this is possible.

The undocumented call is a child method of the Core Document Object and is called setToolbarItemAttribute();
To use this method we first either need to get a reference to the DOM of a document or to reference the DOM directly when using the method like so:

Example of changing the tooltip for the toolbar item defined above.

var dom=dw.getDocumentDOM();
dom.setToolbarItemAttribute('DW_Toolbar_Main', 'MyButton', 'tooltip', 'Boo');

As you can see from the example above the first argument is the unique id of the parent toolbar, followed by the unique id of the toolbar item we want to change. Then comes the attribute you want to change, in our case this is the tooltip attribute. The final argument is the new value to use.

Alright, who's the Iron Curtain refugee who designed this piece of work? Man oh man. I was kvetching about Dreamweaver and Fireworks earlier this week, but for truly awful user interfaces in a major software product the award has got to go to Outlook.

I have to use Outlook in my new job, and that's not going to change anytime soon. At an enterprise level there's really no competition. So I've been plunging into the depths of Outlook attempting to kick out the cobwebs in my brain and make myself use it. And you know, I don't think it's me. I've used Apple's Mail program, in addition to Entourage, Outlook Express, Eudora, Netscape, Mozilla, and Thunderbird at one time or the other. No problem.

But Outlook. All I can say is "Oh my." Somebody must have hidden the usability manuals when that thing was put together. And removed all the letter "I's" from their keyboards just in case someone wanted to make a note about how intuitive the program should be.

So what's got me all riled up? Simple. I need a personal file to archive the many many many many e-mails that I get. OK, got it. In there I have an exact duplicate of everything in my "regular" folder. Including my calendar which I have been posting to when I have appointments out of the office--as I'm required to do. But hey, guess what? I was posting to the wrong one, the "personal" folder instad of the regular "Outlook" folder. And when I came back to the office this afternoon our secretary gave me The Look and let me know that I needed to get my head out of...well, you know the rest. She needs to see where I am and she can't do that when the appointment is in my personal folder.

So, my bad and all that, but what a stupid construct for program design. Why give me duplicates of everything? How about asking first huh? And why put the personal folder in the same level of the document tree as the regular one? Shhesh!

And that's just the tip of the iceberg. It seems that every blessed thing I want to do is found in some obscure path through multiple clicks and arcane tabs into an area of the interface that I'll never remember how to get back to. I bet the Outlook engineers were really good at memory games when they were kids.

But me, I'm sure having trouble getting my head around that puppy. Maybe when the magic Longhorn version is released Outlook will become simpler and easier to manage. I'm not holding my breath.

Following on from Danilo's blog on Locating a root folder for a specific site. There is another undocumented API call dw.getSiteConfigurationPath(). This API call returns a URL of the current selected site within Dreamweavers site panel.

Example of use:

var selectedSiteRoot =dw.getSiteConfigurationPath();

Note: This API call only returns the URL for the site currently selected within the Sites panel. If you need the URL of a site thats not the current selected site, you should follow the instructions here: Locating a root folder for a specific site

I wonder how many people are using the keyboard shortcut CTRL>Y (Windows.) I find it to be one of the most useful shortcuts in any program -- and it does work the same in most programs. If you haven't used it, the shortcut basically repeats the last action -- whatever it is. In MS Word this is handy for adding a certain style or heading to text as you are working on a document. In Dreamweaver I find it very handy for adding CSS, page structure (adding those <h1> and <h2> tags) and also for adding server-side functions as well. For example, in Community MX articles we have a style called .plaincode that is used inside of paragraphs to highlight code. If I apply the CSS to a word or tag inside of the text, I can then move through my paragraphs and hit CTRL>Y to add the same style to other words or tags. It makes it very easy to quickly style a document. The same thing works for form elements. Let's say I have 50 text fields on a page. Some will have a .shortfield class, and some will be a .longfield class. I select one element, set the class in the tag selector (select tag, dropdown list Set Class > classname), and then simply select each element in turn and hit CTRL>Y to add the class to each element.

Dreamweaver's DOM (Documeny Object Model) is made up of a subset of objects, properties, and methods from the World Wide Web Consortium (W3C) DOM Level 1 and some properties of the Microsoft Internet Explorer 4.0 DOM.

The most usefull methods available to extension developers are the methods used to return a custom collection of elements contained within a Document Object, such as getElementsByTagName().

However there is a another undocumented method for returning a custom collection of elements that is not part of W3C DOM standards or from Microsofts IE DOM, this being getElementsByAttributeName('passedInAttributeName').

This handy API call works in a similiar way to the getElementsByTagName() API call but as its name implies it returns a collection of elements that have the attibute passed in defined within thier markup.

Example Element Markup with a style attribute defined:

<div id="myDivOne" style="width:100px;height:200px" ></div>

So if we were looking to get all elements within a document that contained a defined style attribute we would use the following:

var elementsWithAStyleAttribute = dw.getDocumentDOM().getElementsByAttributeName('style');

or

var dom=dw.getDocumentDOM();
var elementsWithAStyleAttribute = dom.getElementsByAttributeName('style');

As this method is also an undocumented child method of the core Element Object you can also use this method to return a collection of elements that are child elements of another element, for example a Form element or Div based element.

For Example, to return all elements contained within the second Div element that have a style attribute defined we could use the following:

var dom = dw.getDocuentDOM();
var divElements=dom.getElementsByTagName('div');
var Div2=divElements[1];
var childElements=Div2.getElementsByAttribute('style');