CMXtraneous: Dreamweaver

Right on the edge of useful

Undocumented Dreamweaver: Every Millisecond Counts

Posted Tuesday, August 31, 2004 11:46:50 AM by Paul R. Boon

Paul R. Boon

When developing an extension you may need to know how long the user's machine has been running and thanks to a handy undocumented API, you can.

dw.getMilliseconds() returns the number of milliseconds since the start of the current OS session.

Example of use.

var sessionMill=dw.getMilliseconds()

Category tags: Dreamweaver, Extensibility

Think Pink!

Posted Monday, August 30, 2004 3:23:50 PM by Stephanie


On August 18th, I was thinking about color and trends and wrote some of my thoughts out over here. I asked a question in that entry like, "Should we start using pink in our web sites since it's gotten so popular in clothing?"

Seems others feel it is time. Look at this site I ran across today: Rapha - High Performance Roadwear. Interesting. And though pink is not one of my personal favorite colors and I've not bought any girlie pink clothes this year, I admit to liking the palette on this web site.

Category tags: Designing for the Web, Dreamweaver, Fireworks

In Vivid Color

Posted Monday, August 30, 2004 9:09:11 AM by Stephanie


Recently I was talking about color and color psychology. Today, I ran across a site, from my Wise-Women list, that really shows this in the most creative way I've seen yet. If you're a visual person (or even if you just love Flash) check this site out.

It was created by Claudia Cortez as her Thesis for her Master of Fine Arts, Computer Graphics Design. I especially love the little "movies" that teach you about each color. Very visual, very easy to remember, and her graphics are really excellent. Take a look!

Category tags: Designing for the Web, Dreamweaver, Fireworks, Flash

Undocumented Dreamweaver: getSelectorsDefinedInStylesheet

Posted Monday, August 30, 2004 3:59:17 AM by Paul R. Boon

Paul R. Boon

A handy undocumented API call is available to those developers wanting to write extensions that deal with stylesheets.

getSelectorsDefinedInStylesheet('selector'), this API call is a child method of the Document Object, so once again a reference to a DOM is required.

getSelectorsDefinedInStylesheet('selector') does exactly as its name implies, it returns a array of selectors that match the type passed in as an attribute. The passed in attribute can be either 'class' or 'id'.

To get an array of the 'class' selectors we would use the following:

var dom=dw.getDocumentDOM();
var classSelectors = dom.getSelectorsDefinedInStylesheet('class');

To get an array of 'id' selectors we would use the following:

var dom=dw.getDocumentDOM();
var classSelectors = dom.getSelectorsDefinedInStylesheet('id');

Category tags: Dreamweaver, Extensibility

Clearing Dreamweaver's Temp folder

Posted Saturday, August 28, 2004 12:05:32 PM by Danilo Celic

Danilo Celic

Paul Boon has been going nuts over in his blog An Infinite Number of Monkeys putting up a ton of undocumented Dreamweaver extensibility API calls. His latest, Locating the systems temp folder, discusses a method of determining a couple of folder locations, Dreamweaver's Temp folder and the system's Temp folder. While I've not had occasion to need the system's Temp folder I have used Dreamweaver's Temp folder for pulling files from remote servers to use locally.

When you're done with you're operations in the Temp folder, you typically want to clean up after yourself. One way to do that would be to use DWfile.remove(fileURL) to delete the file(s) that you created, and you can even use DWfile.remove(fodlerURL) to delete your own sub-folder. That's all well and good, but Dreamweaver offers a quick and easy way to clean out the Temp folder using the MMHttp object. The MMHttp object provides access to a remote server, such as grabbing the contents of a file for updating your extension, or even posting data to a server to update the powers that be that you're done with your part of the project. (see my 4 part series on this object, Sending and Receiving Data within Dreamweaver Extensions for more information on this). As part of its functionality, the MMHttp object may pull files into the Dreamweaver Temp folder, so it also offers a documented method (sorry folks no hidden gem in this post) of cleaning up after itself, clearTemp(). This method deletes the contents of the Temp folder. Example usage below:


Category tags: Dreamweaver, Extensibility

Undocumented Dreamweaver: Locating the systems temp folder

Posted Saturday, August 28, 2004 7:16:36 AM by Paul R. Boon

Paul R. Boon

The documented API call dreamweaver.getTempFolderPath() returns a File URL to a temporary folder within Dreamweaver's configuration folder where you can store temporary or transient files. These are usually files that you may need during a session of Dreamweaver but are not needed across sessions.

I commonly use this location when one of my extensions needs to write out temporary data collected from other locations or when performing complex file system operations, as it is safe known place to move files during the current DW session.

Note: When using this folder you should treat it like the shared folder, by first creating your own child folder.

However you may require access to the operating systems own temp folder and luckily there is yet again an undocumented API call the comes to the aid of us extension developers.

getSystemTempFolder() This undocumented call is exposed by the DWfile File I/O Object and so to reference it we use DWfile.getSystemTempFolder();

Example of use:

var systemTempFolder = DWfile.getSystemTempFolder();

Note: This call returns an operating system file path and not a file URL like other path related API calls.

Category tags: Dreamweaver, Extensibility

Undocumented Dreamweaver: Dynamic toolbar attributes

Posted Friday, August 27, 2004 6:12:47 PM by Paul R. Boon

Paul R. Boon

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') "
    tooltip="hello mum."
    update="onEveryIdle" />

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.

Category tags: Dreamweaver, Extensibility

Undocumented Dreamweaver: Obtaining the current selected sites local root URL

Posted Friday, August 27, 2004 12:18:57 PM by Paul R. Boon

Paul R. Boon

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

Category tags: Dreamweaver, Extensibility

Handiest keyboard shortcut

Posted Friday, August 27, 2004 11:51:17 AM by Tom Muck

Tom Muck

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.

Category tags: Dreamweaver

Undocumented Dreamweaver: getElementsByAttributeName

Posted Friday, August 27, 2004 8:47:09 AM by Paul R. Boon

Paul R. Boon

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');


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');


Category tags: Dreamweaver, Extensibility

Fill a list with defined site names

Posted Thursday, August 26, 2004 10:45:40 PM by Danilo Celic

Danilo Celic

Sometimes you want you users to be able to select a site into which you're going to perform some action, perhaps to copy in some files to install the latest version of your server side application. So maybe you want to have a select list to display all the of sites for the user to choose from.

Dreamweaver makes it simplie to grab an array of all the defined site by using site.getSites(), so all you need to do is to place the site names into a specified select list. Sure you could use JavaScript DOM methods to find and manipulate a select list with a particular ID, but there is an easier way. By combining site.getSites() with a pre-built JavaScript object that is available in configuration folder: ListControl. The ListControl object has a number of methods that make it easy to add items to a select list, as well as grabbing the selected item. To use the ListControl object, just include the JavaScript file /Shared/Common/Scripts/ListControlClass.js into your extenion. to link in from a Command use the following code:

<script src="../Shared/Common/Scripts/ListControlClass.js"></script>

Because I've had to create site lists so many times, I've created a function that takes the name of a select list as a string, and creates a ListControl object out of it and then inserts a list of site names into the select list. I've also added another string parameter that is used as the first item in the select list if you want a "Please choose a site" item at the top. Here is that function:

function cmx_SiteList(listName,insertTextAtTop){
var theList = new ListControl(listName);
var sites = site.getSites();
if(insertTextAtTop) sites.unshift(insertTextAtTop);
theList.setAll(sites, null);
if(insertTextAtTop) theList.setIndex(0);
return theList;

Note: This function requires that the ListControl object be available, so remember to include the ListControlClass.js file, as indicated above.

To use this function, insert a <select> tag into your document, and give it a name, let's say, mySiteList. then use one of the following lines of code. The first is used to get a reference to a ListControl obejct stored in siteListObj, and the second get a reference, and also inserts an item at the top of the list:

var siteListObj = SiteList('mySiteList');

var siteListObj = SiteList('mySiteList','Choose a site');

From here on out, you can just use the ListControl's methods and properties to be able to determine which site your user has selected so that you can do further processing from there. If you want to be able to grab the path to a site's root folder, check out this entry: Locating root folder for a specific site

Category tags: Dreamweaver, Extensibility

Undocumented Dreamweaver: Which OS, Mac or Windows?

Posted Thursday, August 26, 2004 4:08:11 PM by Paul R. Boon

Paul R. Boon

When developing cross platform extensions (Windows or Mac), a developer may need to write a different piece of code for each operating system. A good example of this is when handling OS based file paths (not file URLs), as Windows and Mac Operating systems use different formats. Another example of the need for determining the operating system being used, is the need to use different styles of graphics for extension interfaces, so as to conform with an operating systems look and feel.

The standard Documentation does not explain the different ways a developer can handle these situations, but there are in fact a number of Undocumented API calls that we can use in these situations.

Undocumented DWfile Object (file I/O) API
The DWfile Object exposes an undocumented call getPlatform() that can be used to determine if the extension is running on a Windows or Mac based machine.

Example of use:

var osType = DWfile.getPlatform();

In the above example DWfile.getPlatform() returns 'macos' when executed on a Mac or 'win32' when executed on a windows based.

navigator Object API's
The core navigator Object also exposes a documented property for finding out what operating system Dreamweaver is running on. This is the navigator.platform property, this property works in a similar way to the previous mentioned DWfile.getPlatform() API call.

Example of use:

var osType = navigator.platform;

Note: this is a property of the navigator Object and is not a method of the Object so we do not add the () at the end of the statement like we have when using DWfile.getPlatform().

The navigator Object does have an Undocumented sister static property, this handy property is navigator.winOSname and holds a string value representing the family version of Windows Dreamweaver is running on. For Windows 98 the property value is 'Win98', for Windows XP or 2K the value stored is 'WinXP2K' and for Windows NT the value stored is 'WinNT'.

The type of situation this might be needed is when a developer needs to access a different folder on the system to get to windows specific information or by using a third party API accessing different parts of the windows registry.

Example of use:

  case 'win98':
       Place code for Windows 98 based situation here...   break;
  case 'winxp2k':
       Place code for Windows XP/2K based situation here...   break;
  case 'winnt':
       Place code for Windows NT based situation here...   break;

Undocumented dwscripts Static Properties
A developer can reference a number of static properties of the undocumented dwscripts class to determine if they are dealing with a Mac or Windows based machine, as well as finding out the version of windows being used. The static properties of the dwscripts Object that relate to operating system identification are listed below.

dwscripts.IS_MAC, true if on a Mac false if windows.
dwscripts.IS_WIN, true if on window false if a Mac.
dwscripts.IS_WIN_98, true for Windows 98 false if not.
dwscripts.IS_WIN_XP_2K, true for Windows XP or 2K false if not
dwscripts.IS_WIN_NT, true for Windows NT false if not

Example of use:

    Place code for Mac based situation here...

    Place code for Windows based situation here...

Other Undocumented Operating system related API calls.
Finally there are two other undocumented API calls that can be used in relation to the operating system Dreamweaver is running on, these are dreamweaver.isXPThemed() and dreamweaver.isOSX(). These API calls are referred to as enablers, as they are usually used to determine if a function/feature is enabled or disabled.

dreamweaver.isXPThemed() returns true or false. If the user has a Windows XP theme running as there desktop theme then the call would return true. This is the normal or default state for Windows XP. The call would only return false if the user is running Windows XP using the classic mode or running a version of Windows that does not support themes.

dreamweaver.isOSX() returns true or false depending on the type of Mac OS the user is running, if the user is running a version of Mac OSX then the call would return true.

These calls would primarily be used to handle the display of different styles of user interface graphics, making sure the extension had the look and feel of the versions of operating system being used to run Dreamweaver. Although these calls would be used in conjunction with some or all of the above mentioned API calls and properties.

Example of use:

       Place OSX interface code here...
      Place non-Mac OSX interface code here...
       Place Win XP interface code here...
      Place non-Win XP interface code here...


Category tags: Dreamweaver, Extensibility

Upgrading to Panther before Tiger is Released?

Posted Thursday, August 26, 2004 3:27:51 PM by Stephanie


Maybe some of you are as slow as I am to update your Operating System -- maybe not. It always scares me to death ... I just can't afford any down time at all with the rate of speed I work at. So yes, I'm just getting ready to upgrade from Jaguar (OS 10.2.8) to Panther. And yes, Tiger is coming. But it will be a while before I adopt that kitty. I like to let other people work out the bugs and find out which programs don't yet work.

Here's my plan. With Studio MX 2004's product activation scheme, I have to transfer my program licenses before reinstalling or upgrading my operating system. Activation has gone pretty smoothly for most people. But to avoid any problems, I'm going to complete the following steps I found a while back (I will be brave...I will be brave...):

  • In Dreamweaver MX 2004, choose Help > Activation > Transfer License and deactivate the license on your computer. (In Flash MX 2004 or Fireworks MX 2004, choose Help > Transfer Your Software License.)
  • Install Panther.
  • Relaunch your Studio MX 2004 applications and reactivate them.

Generally, activation and deactivation require about 30 seconds or less. Wish me luck!

Category tags: Dreamweaver, Flash, Fireworks, Mac

Undocumented Dreamweaver: Getting to the root of the issue.

Posted Thursday, August 26, 2004 7:26:46 AM by Paul R. Boon

Paul R. Boon

When developing an extension you may need to know the file path the user used when installing Dreamweaver. An obvious example of this is when a developer needs to access files to do with the JVM (Java Virtual Machine) that ships with Dreamweaver. The JVM is installed in a child folder to the main applications parent folder, but is not inside Dreamweaver's Configuration path. Luckily there is an Undocumented API call that will return the path used to Install Dreamweaver. The undocumented call is dreamweaver.getRootDirectory(), unlike nearly all other path related API calls in Dreamweaver, this call returns a file path and not a URL.

Example of use:

var dwInstallDIR=dreamweaver.getRootDirectory();

This call is also helpful if you need to get access to other files installed alongside the main Dreamweaver executable or to the folder help files are installed in by default.

Category tags: Dreamweaver, Extensibility

Extreme Makeover for Dreamweaver

Posted Wednesday, August 25, 2004 7:35:00 PM by Kim


I love Dreamweaver. Really I do. But there is one area of the user interface that is overdue for an extreme makeover. The CSS Styles Definition Editor.

Now before you start ragging on me and telling me that I really ought to be using a text editor, or TopStyle, or some other method for defining my styles, I'll admit that the world of heavy-duty styling is sort of new to me. Sure, I've always understood intellectually how things are done in the CSS Editor, and even written a tutorial or three about using it. But now that my job has me spending a significant amount of time in Dreamweaver, and creating a complex style sheet, the sheer inelegance of the interface seems to slap me in the face all the time. When I'm designing I need to be able to do it from the gut, and not have to think quite so much about operating that editor thing.

I also think that the current user interface is an impediment to creating styles and makes it harder for people new to web design to learn how to create and style their work. The CSS Editor is clunky and kludgy and feels like it was designed by committee. Two areas in particular rub me the wrong way.

First, the categories listing on the left side is meant to be descriptive, but really conveys too little information to be helpful for those of us who don't eat, drink, and sleep CSS. OK, some of those categories jump out at you, but what's the difference between Box and Block? Shouldn't it be more evident what each of those categories allows you to do?

The second one that gets me is a lack of any visual feedback when working in the editor. For someone who is new to this type of styling the whole notion of setting properties in some sort of modal dialog box, and then hitting OK or Apply to see things take effect is just too big a leap of faith. How hard would it be to allow me to see a preview of the style before I apply it? Are there too many variables? Too many options? I don't know, but I do know that the current design is counter-intuitive. I hope it gets some serious work done before the next version of Dreamweaver is released.

Dreamweaver isn't the only application in the MX Studio that needs some work. Tomorrow I'll write about my pet peeve in Fireworks. If you've got one of your own feel free to post a comment.

Category tags: Dreamweaver

Undocumented Dreamweaver: Credit where credits due.

Posted Wednesday, August 25, 2004 4:46:04 PM by Paul R. Boon

Paul R. Boon

Ever wondered who is behind Dreamweaver MX 2004's extensibility, well thanks to an undocumented static property you can find out.

Whilst this API property has no real use when it comes to extension development, you can at least see who you should be thanking or screaming at when it comes to extension development :-).

So here is the static property:

dreamweaver.credits (type String)

The best way to see the result is simply to alert the property like so:


Also do not forget to take note of the last part of the message that appears...

Category tags: Dreamweaver, Extensibility

JavaScript hack for those sometimes errors

Posted Tuesday, August 24, 2004 1:52:32 PM by Tom Muck

Tom Muck

Have you ever built a page with a simple JavaScript that works most of the time but sometimes gives you a JavaScript error "Object expected"? Many times this is caused by a JavaScript executing before the page is fully loaded. It happens frequently with mouseovers -- especially menus that are at the top of a page. What happens is that a user will type the URL into the browser, and as the page is loading the mouse is brought over a mouseover. Because the document is not fully loaded, the object cannot be located.

One trick (read: cheesy hack workaround) I use to overcome this problem is to use a JavaScript try/catch block. A try/catch block is saying "try this, and if it doesn't work do this instead". A try/catch block effectively stops an error in its tracks. For an error handling routine it is a lifesaver, but for an annoying "sometimes" error, it is simply a nice workaround. The most basic syntax is this:

try {
  // code you want to "try"
}catch(e) { // "e" is the error
  // code to execute in the event of an error

Use it like this:

  1. Find the culprit script that throws the error. It's usually a mouseover of some variety.
  2. Add the try/catch around it.

Here is a simple example. Suppose a link has a mouseover event like this:


Every once-in-a-while you will see a JavaScript error on this bit of script. Add the try/catch:

onmouseover="try{doRollover('myImage') }catch(e){};"

That's it. The catch block does nothing -- it simply exists to fill out the try/catch block, but has no alternative operation. When the page is fully loaded, the script will execute normally.

Category tags: Dreamweaver

Undocumented Dreamweaver: reloadSnippetList, I wonder what this does?

Posted Tuesday, August 24, 2004 1:49:00 PM by Paul R. Boon

Paul R. Boon

For developers developing extensions to manipulate snippets, the main issue has been the lack of an API call to force the Snippets panel to refresh itself. This especially becomes an issue when your extension makes dynamic changes to the Snippets folder within Dreamweaver's configuration directory.

An undocumented API call comes to the rescue once again, this time in the shape of:


This handy API call simply reloads the Snippet Panel showing any and all changes made to the snippets folder structure.

Category tags: Dreamweaver, Extensibility

Undocumented Dreamweaver: Using Popup Menus in Extension Interfaces

Posted Sunday, August 22, 2004 11:17:13 AM by Paul R. Boon

Paul R. Boon

The main issues many developers find when starting to write extensions is that many of the techniques used to develop DHTML Interface elements simply are not possible within Dreamweaver extension Interfaces.

Another issue is the annoyance that something that is possible in one type of extension is not available in another type of extension.

An example of this is the classic popup menu. Popup Menus can be a life saver when designing an interface for an application, as they allow the developer to group similar or related features to a single interaction point within an interface.

Of course when developing toolbars they are nearly always essential. Without popup menus interfaces would be at best large and confusing and at worst impossible, resulting in most cases with the developer having to leave out a feature that might otherwise have been added in.

When developing Toolbars and Insertbar Objects Extensions for Dreamweaver, developers can make use of popup menus by utilizing the MENUBUTTON tag. But according to the documentation that ships with Dreamweaver if your developing commands or other types of extensions there seems little a developer can do... or is there?

An undocumented Core Object type comes to the rescue with the somewhat obvious name PopupMenu Object. The PopupMenu Object is not packed with features and does not support sub menus or icons and other graphics and menu items can not be grayed out. But it does allow the developer to call a popup menu when and where ever they wish within any extension type.

So how do we use this object?

To define a popup menu in your code you simply declare a variable being of type PopupMenu like so.

Var myPopupMenu = new PopupMenu();

To add items to the menu you make use of addItem method that is one of the two methods the PopupMenu Object exposes. So if we wanted to have four items in the menu when it pops up we would need to call this method four times like so.

myPopupMenu.addItem('item 1');
myPopupMenu.addItem('item 2');
myPopupMenu.addItem('item 3');
myPopupMenu.addItem('item 4');

To make the popup menu appear we need to call the other exposed method which is the popup method. This displays the popup menu allowing the user to select an item from the menu.

var respone = myPopupMenu.popup();

When a user clicks a menu item on the menu the menu item text is assigned to the variable used, in the case of the example above the variable response is assigned the value of the menu item selected.

A simple way to make use and to simplify the code is to write a function to handle the creation and displaying of the menu. This way we can pass in an array of menu items and then use a single function call when ever we need to call a popup menu. The code below demonstrates how to do this.

function popupMenu(a){
    var m = new PopupMenu();
    for(var i=0;i < a.length;i++){
    var s=m.popup();
    return s;

to use this function we simply call the function popupMenu() passing it an array of menu items and it returns the item the user selected.

Example 1 (Code example)

var myMenuItems=new Array('item 1','item 2','item 3','item 4');
var response = popupMenu(myMenuItems);

Example 2 (Code example)

alert(popupMenu([ 'item 1','item 2','item 3','item 4' ]));

Category tags: Dreamweaver, Extensibility

Nothing Like a Fresh Pair of Eyes

Posted Friday, August 20, 2004 4:14:30 PM by Kim


So, this afternoon I'm busily banging away at a page design, trying to get a simple CSS rollover menu to work correctly. Not a big job, but for the life of me I could not get the menu to display correctly in Internet Explorer. I kept getting this weird padded area above some links, but not above others. I stripped out everything I could think of from the style definitions, one at a time, thinking that there must be something in there that was causing IE to whack out.

Finally I asked a coworker to come and have a look. He knows nothing about CSS, but it only took him a minute to spot the blank spaces after some of the list items. Ah yes. I seem to remember that very thing causing people problems. All I had to do was remove those spaces and Voila! No more weirdness.

I might have found it myself sooner or later, but sometimes you just need someone who hasn't been staring and cussing at the code for an hour to have a look.

Category tags: Dreamweaver