In my last post, I complained about sites that pop up windows and take away my menu bar so I can't print. Tonight I found the perfect Firefox extension to stop this annoying scripting: Unhide Menubar. It keeps scripts from ever hiding the menu bar, ever. I've already put it to use to print out my flight confirmation through Orbitz.

Big news in the web development world, I'll let the announcements speak their own volumes, and I'm sure you'll hear plenty of others on the topic. I'm going to wait an see what further info comes out before I decide what I'm going to think about the whole deal.

Macromedia's side
Adobe's side
Mike Chamber's

I guess we'll become quite tired of the "forward looking statements" statements in the near future.

Note: Reported to Macromedia already.

I was trying to help a budding extension developer that was experiencing crashes of Dreamweaver when they added a <label> tag to their file. The basic code boils down to this within an extension:

<label>Name:</label><input style="width:135px" type="text" name="name" id="name">

Turns out that there are two potential breaking points (only played with the code in a Command and only with the text box, for other extension, YMMV):

• Adding the for attribute to the label tag, would cause the issue to go away. In my brief testing, it didn't seem to matter what the for attribute value was, as long as it was there.
• If you removed the id attribute for the text field, the crashing would stop.

One thing that is weird about it all is that if you keep the id and add the for, and you set the for to have the same value as the id, and you have no value attribute, or the value is set to an empty string ( value="" ), that is, when you do not specify a value for the value attribute, then when your dialog appears some square symbol characters will be within the text field instead of the field being empty.

Quite strange indeed.

While it's deprecated, dreamweaver.popupCommand() is used in several places within Dreamweaver, it isn't documented as that method that is supposed to be replacing it, dreamweaver.runCommand(). In the documentation for dw.runCommand() it states that you can pass in option arguments that will be procesed by the receiveArguments() function within the called Command. dw.popupCommand() also can take optional parameters to pass on to the called Command. For example, if you wanted to pass along a first name, last name, and age of a user to a Command, you could use the following code:

dw.popupCommand('MyCoolCommand.htm','Bill', 'Horvath', 97);

Again, this method has apparently been deprecated since Dreamweaver 3, but its still around, at least through Dreamweaver MX 2004, 4 versions later.

If you want to show a button on a toolbar, the Dreamweaver docs tell you that you can use the showif attribute to determine when to show a particular icon. For example, the Live Preview button on the Document toolbar is only shown when you are working with a document type that is one of the dynamic pages, such as ASP or ColdFusion. If you wanted something similar for a menu item, then just reading the docs, you'd think that wasn't possible.

Fortunately, you can show a menu item if the condition in the showif attribute of that menu item returns true. Take the following example that shows the File > New menu item only when the Shift key is held down (added code highlighted):

<menuitem id="DWMenu_File_New" showif="dreamweaver.getKeyState('Shift')" name="_New..." key="Cmd+N" enabled="true" command="dw.newDocument()" domRequired="false" />

If you haven't noticed, Google Desktop quietly came out of beta a couple weeks ago. I didn't install the beta because there was no support for Firefox, but Google Desktop now supports Firefox, Mozilla, and Internet Explorer, as well as Thunderbird, Netscape Mail, and Outlook.

I just installed it last week and it's truly astonishing - not to mention a bit creepy - to find every file, every Word doc, every image, every email, and every newsgroup post that contains the word you're searching. Even conversations you don't remember having! Surprisingly, it doesn't search your Gmail account, but maybe that option will be added to a future version.

Like other Google inventions, Google Desktop changes the way you think of personal computing. For example, you can install Larry's Any Text File Indexer plug-in and use it to search your ActionScript files. You can use the Developer Search API to generate a slideshow or an MP3 playlist from a query. What about using GDS to maintain a personal journal? Just send an email to your Gmail account every day and you'll have a threaded, searchable diary.

If you're thinking of installing Google Desktop, check out these terrific tips. I used this tip to move the index file from my C (6 GB free) to my E drive (80 GB free). Unfortunately, Google Desktop didn't index some folders on my E drive, so I'm going to use this tip to force a re-index.

Here's another tip. If you want to search Google Desktop from Firefox, Mozilla, or Netscape, download our free Community MX Sidebar. This Flash-based extension (requires FP7) adds a tabbed sidebar that displays the latest CMX articles, and enables you to create and save custom searches. Once the extension is installed, here's how you add Google Desktop to your list of search engines:

1. Select the Search tab on the CMX Sidebar.
2. Click the down arrow next to Go to reveal the search editor.
3. Click the Plus (+) button to add a new search.
4. Enter "Google Desktop" in the first text box.
5. Enter your GDS URL in the second text box.
6. Click Test Search.

What is your GDS URL? When you conduct a Google Desktop search, you'll notice it has the following format:

http://localhost:4664/search&s=[Security token]?q=cmx&btnG=Search+Desktop

The easiest way to add this URL to the CMX Sidebar is to search a word with Google Desktop, copy the URL from your browser's address bar, and paste it into the second text box. Remember to replace the search term - cmx in the example above - with %s. The revised URL looks like this:

http://localhost:4664/search&s=[Security token]?q=%s&btnG=Search+Desktop

When you're finished, simply select Google Desktop from the combo box, type your query, and press Enter. The results of your GDS search are displayed in the main browser window. You can also search Google Desktop by creating a bookmark keyword, or by installing this free search plugin for Firefox.

I've mentioned how you can store commonly used strings for use in your extensions, but that only does you so much good, especially if you need to have "dynamic" error messages such as those that tell the user which form field they didn't fill in, or perhaps that a named element on the user's page is no longer present. If you do run into a position that you have a commonly used string but you need to make it dynamic, that is, has certain parts of it be changeable depending on input either from the user, or based upon the current page, then you have to work things out a tiny bit differently.

Sure, you could always use the stringVar.replace(pattern, newValue) method to insert the dynamic part(s) into the generic message, but you might end up repeating that bit of code into every page. Dreamweaver has built in JavaScript library files offer a way in which you can keep your loaded strings and still be able to have them be dynamic. Within /Shared/Common/Scripts/dwscripts.js is a method of the dwscripts object sprintf().

By way of example, if you had this string definition within the /Strings folder:

<string id="cmx/MyLayerMessage" value="The %s with an id of %s is no longer present on the page." />

And you'd use it with code similar to the following:

var errMsg = dwscripts.sprintf(dw.loadString('cmx/MyLayerMessage'), 'DIV', 'myDiv');
alert(errMsg);

And you'd get an alert with the following message:

The DIV with an id of myDiv is no longer present on the page.

You can have as many areas to replace within your string as you want (the %s items), and the sprintf() method will take as many string parameters as you want to throw at it. Of course you'll want to make sure that you match up the number of %s with the strings being passed in.

Many users have problems with rogue extensions, bad extensions, or extensions that have been uninstalled improperly. Dreamweaver's Extension Manager is not entirely reliable when installing/uninstalling extensions. This is because of the way that modern operating systems work with multiple users, and because Macromedia, like other software companies are forced to comply with a multi-user configuration. When you run Dreamweaver, you can be logged onto the operating system as yourself, the computer Administrator, or another user. When you install an extension, the files are not installed to the main program directory, as they were in the past with Dreamweaver 4 and earlier. They are installed in the local user directory, or in the All Users directory. Danilo posted about the Dreamweaver configuration folder locations in a previous entry at CMXtraneous.

One of the major problems that has plagued extension developers from the beginning is when a rogue extension developer overwrites a Dreamweaver system file, or any Dreamweaver Configuration folder file. For example, some extension developers try to add additional functionality to the Dreamweaver Recordset. Instead of creating their own version of the Recordset files (such as Recordset.htm and Recordset.js), they modify the existing Dreamweaver files. That works great if this is the only extension the user will ever install. If the user wants to install an extension from another developer, however, this could severely break the way that Dreamweaver works, because expected functionality might not be there or might act differently. Additionally, if two rogue extension developers overwrite the same file, one of them is out of luck because the second extension overwrites the first extension.

Make no mistake, when a Dreamweaver configuration file is overwritten by an extension developer, it is the equivalent of a virus, a spyware, or other intrusive worm. The installation is now corrupt.

Additionally, some extension developers are including a directive in the .mxi file that creates the extension package, putting a systemfile="true" directive for each system file that they overwrite. This causes problems as well, because when you uninstall the rogue extension, the bad system file is left in your Dreamweaver installation. The effect of this is that your Dreamweaver installation is corrupted. Dreamweaver is using the corrupted file rather than the file that Macromedia created.

Another problem exists: when Macromedia comes out with new versions of Dreamweaver, these rogue extensions are still being distributed, and are being used by users. Let's say, for example, that a new version of Dreamweaver has to change the Recordset.js file in order to work with some new functionality. A user installs an extension that overwrites this file using a version from the last version of Dreamweaver. The program is now broken with no way to recover other than deleting the local All Users or the local user folder, or just making it easy on yourself and reinstalling Dreamweaver.

More problems: If a Dreamweaver user decides he wants to modify a file in the Configuration folder, if the file has been overwritten by an extension developer, the user's changes are not respected.

An additional note: when I say that the file is "overwritten", it's not entirely accurate. In a modern operating system, the files are not overwritten in the main Program Files directory (Application directory on the Mac). The files stored in the All Users supercede the files stored in the Program Files directory. In other words, if Dreamweaver requires a Recordset.js file to run, the file will remain untouched in the Program Files directory, but a new version of the file is stored by the Extension Manager in All Users. However, to the uninformed user, this is the equivalent of a corrupt installation. The typical user does not know that there is a special hidden directory that contains rogue extension files.

What to do about this? Well, the first and most important step is to convince these rogue extension developers that what they are doing is harming the community. In their overzealous approach to adding functionality to Dreamweaver, they are basically spoiling the program for other extension developers, and setting the average Dreamweaver user up for a corrupted installation full of JavaScript errors every time they want to open a file. Secondly, Macromedia should step up to the plate and disallow extensions to be downloadable from the Exchange if the extension modifies core Dreamweaver configuration files. Lastly, users should write to extension developers that do this and demand that they stop.

It is a political issue, unfortunately. The extension developers who do this (I'm not naming names) insist they are trying to make Dreamweaver better. Some of us extension developers who have been around a while have always made an effort to extend Dreamweaver without ruining it for the next guy, though. Sadly, if it keeps up, more extension developers will do it and before you know it every extension you install will overwrite some other guy's file, and no extensions will work. What a mess that will be. . . .

I issue a challenge to all Dreamweaver extension developers to stop this practice. It's already late, but we can minimize the damage going into the future. Extension development has come a long way since the early days of Dreamweaver, but if we can't develop extensions in a responsible way, it is going to impact the way that Dreamweaver users view extensions.

What to do if you have a corrupt installation? The first thing you should try is uninstalling the extension. Of course, that doesn't work always because of reasons I've stated. If it doesn't work, find the local Configuration folders mentioned above (not the main Program Files directory) and rename them or delete them. This will completely remove all extensions so that your Dreamweaver installation will be fresh again. Alternatively, reinstalling Dreamweaver should do this as well.

Cross-posted at Tom-Muck.com

Many times you'll need access to similar messages that you present to the user, whether in alerts for errors, or in notes on dialogs in a Dreamweaver extension. You could include the same text over and over again, in all of the extensions you have as part of your project, or you could write your own custom file manipulation functions that would share a common file to store your common text. Well, the great folks that bring you Dreamweaver also thought of this second method, they just happened to not document it just yet, and it's called dreamweaver.loadString().

Essentially, the loadString method takes as a parameter, an identifying ID that identifies the particular string that you're trying to use within your extension. Well, what does that mean? Ok, here's a code snippet to test out using Tom's JavaScript Eval panel:

alert(dw.loadString('General/docEncoding'));

On my system, I get alerted: iso-8859-1

So, where, and how do you store your strings so that that you can load them when needed?

As usual, you need to get into the Dreamweaver configuration folder. Go to the Configuration/Strings/ folder. You store your data in a specially formatted XML file. See the following code for an example of the format:

<strings>
  <string id="uniqueIdentifier" value="string to store">
</strings>

You can have multiple <string> tags within the parent <strings> tag.

Make sure that you uniquely identify your strings, preferably by "scoping" the strings by including your company name, or your initials, and also save your strings XML file with a unique name inside the Strings folder. All this is to avoid any naming conflict with other developers, or with built in stings, and strings XML files.

If you work with SWFs in your extensions, you may want to be able to determine the dimensions of the SWF so you can generate the proper HTML code. Dreamweaver has a built in object called SWFFile that has a method getNaturalSize() that is supposed to return an array that contains the width and height of the SWF. However, if there are times when you won't get an array back. It seems that if the SWF was published as a compressed movie, then you get a null returned rather than the dimensions array. So if you depend on user supplied SWFs, you won't be able to rely on SWFFile.getNaturalSize() to allow you to generate the proper dimensions for use in your code.

I had seen a question in the Dreamweaver Extension forums a while ago and found out that compressed SWFs and SWFs created by Dreamweaver's Flash Elements seemed to cause the null return rather than the SWF dimension array. Thanks to Drew McLellan who ran into this issue on a new extension he's working on for bringing up this issue again, and inspiring me to find a way around the issue so that you don't need to find out the dimensions, you let Dreamweaver do it for you automatically.

So, what can you do to get around it? Well, you may think that looking in the Flash object on the Insert bar may give you some guidance, as when you use it, you end up with code on your page that has the proper dimensions for the SWF file in it. However, you'd be a little miffed checking the code in that the object itself doesn't do that, Dreamweaver seemingly performs some magic in the background after the Flash SWF code is added to the page. The code the Flash object generates sets the dimensions to 32x32, and immediately after the insertion, Dreamweaver somehow makes the changes to the code reading in the proper dimensions and setting them in the code.

So with this in mind you might follow along with the logic of an object that inserts code into a page and attempt to use dom.insertHTML() to place the code into your page. Again, you'd be stymied, as that doesn't seem to trigger the resetting of the SWF's code by Dreamweaver. Ok, if you're like me, you carry on with thinking through the problem, so if an object can do this, can I call an Object file to do the code insert for me? The answer to that would be: "yes...but". You can invoke an Object from your extension using dom.insertObject() passing in the name of the object file to run (minus the file extension). The "but" part of the answer is that you need to use the objectTag() type of Object to insert code into your page, as the insertObject() type of Object forces you to use dom.insertHTML() or some other method of code insertion. Doing with insertObject() causes Dreamweaver to do the replacement for you immediately after the code is inserted into the page.

So you have a workable solution, but you may need to be able to pass along the path to the SWF file to your Object that inserts your SWF code for you. Unfortunately dom.insertObject() doesn't allow for passing of parameters as dw.runCommand() and dwscripts.callCommand() do. So one way around this would be to attach a new property to the MM global object, say MM.my_flash_path, and then in the object take that value, and use it in the creation of the code to insert into the page.

Create an extension, and use whatever code you need to to get the path to a SWF file, then call dom.insertObject() and pass in the name of your Object. The following code just uses a default document relative path to the SWF, and calls an Object whose file name is blankFlash.htm. It doesn't matter which folder within the Object folder your Object resides, as long as it is named uniquely.

MM.my_flash_path = 'batang.swf';
var dom = dw.getDocumentDOM();
dom.insertObject('blankFlash');

Within your Object file, in this case blankFlash.htm, create an objectTag() function and pull the value out of MM.my_flash_path and create the code to insert your Object. See the following code as an example (:

function objectTag(){
  var flashFilePath = MM.my_flash_path;
  rtnStr = '<OBJECT CLASSID="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"' +
' CODEBASE="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0" WIDTH="32" HEIGHT="32">\n' +
'<PARAM NAME="movie" VALUE="' + flashFilePath + '"> <PARAM NAME="quality" VALUE="high">\n' +
'<EMBED SRC="' + flashFilePath +
'" quality="high" PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer" ' +
'TYPE="application/x-shockwave-flash" WIDTH="32" HEIGHT="32">'+
'</EMBED></OBJECT>';

  MM.my_flash_path = ';
  return rtnStr;
}

As you can see, the height and width are each set to 32, but when the Object is run, it will insert the code and Dreamweaver will automatically change those values to the proper ones. Plus, Dreamweaver will insert the code using your code tag and attribute case settings, so you'll get lower case tags and attributes if that's what you have set in your preferences.

Interestingly, if you try to just insert the <object> code and leave off the <embed> Dreamweaver will not perform the conversion. If you just insert the <embed> tag and no <object> wrapping tag, Dreamweaver will do the proper modifications.

Note: Your Object will be displayed in the Insert bar and be clickable, so you'll need to find some way around this if you only want to only be able to use your SWF code object through your extensions, such as checking for the MM.my_flash_path value in canInsertObject() prior to allowing the Object to run. Generally, you can include <!-- MENU-LOCATION=NONE --> at the top of your extension file to prevent it from being listed in the menus, and it does stop an object from being listed in the Objects panel, however, if you attempt to invoke an object with dom.insertObject() and it has the menu hiding code in it, you'l get an error popped up by Dreamweaver.

ColdFusion 7 was released today, as you've probably heard if you've been reading the Macromedia related blogs today. With the new version comes new tags and attributes, and if you want to use them in Dreamweaver MX 2004, you'll need to get the CF7 extensions for Dreamweaver MX 2004. Also part of the suite of extensions for CF7 are several other enhancements:

• A datasource editor that allows you to edit and create new datasources directly within Dreamweaver
• CFC filtering for the Components panel to show cfcs only for the current site
• CFC recordsets which allow you the same point and click creation through the recordset dialog, and drag and drop functionality from the Bindings panel but the extensions allow you to abstract things a bit by placing your code into a CFC rather than inlining the code in the page as with the "normal" recordsets.
• Login wizard which brings point and click protection to a web site using the cfloginuser tag new to CF7.

To find out more about the ColdFusion 7 Extensions for Dreamweaver.

The Dreamweaver MX release changes things a bit when it came to the Object type of extension. Dreamweaver MX changed the Objects panel to the Insert bar and also added an XML configuration file that is used to specify which tab an object is supposed to be placed on. However, with this change came a change in the way that you needed to package up MXP files for use with Extension Manager 1.5 that came with DWMX. In previous releases of Dreamweaver, installing an Object all you had to do was to specify the folder within the Objects folder you wanted the object to appear and it would show up on the Objects panel in the proper category, even creating a new category if you added a brand new folder.

That functionality changed a bit with Extension Manager 1.5. You had to specifically add some code to your MXI file to be able to create your own category, but you also had to add code to add your Object to a folder, even if that folder already existed. Fortunately, this was removed from Extension Manager 1.6 which can be downloaded found at the Exchange, and is installed with Dreamweaver MX 2004. But if you have users that are on Dreamweaver MX and you can't be sure that they have upgraded their Extension Manager, then you have to add the code to your MXI files.

I found all this out when I was creating an Object that I'll be releasing here at Community MX, and I didn't specify the changes that were to be made to the Insert bar. Worked just fine in Extension Manager 1.6 and Dreamweaver MX, but not with Extension Manager 1.5. Be sure to check the Dreamweaver extensions page for the File Name Link extension soon. While you could read the MXI format document (PDF) and glean a little bit about what you'd need to do, it doesn't really cover the exact code you'd need for making changes to the Insert bar configuration file. See below for code I'm using in the File Name Link extension.

<configuration-changes>
  <insertbar-changes>
    <insertbar-insert>
      <category folder="Common" id="DW_Insertbar_Common"
      name="FileNameLink">
        <button file="Common\FileNameLink.htm"         id="CMX_Insert_File_Name_Link_FileNameLink"
        image="Common\FileNameLink.gif"
        name="File Name Link" />
      </category>
    </insertbar-insert>
  </insertbar-changes>
</configuration-changes>

Reading into this, you can see that you are making a configuration change, in particular insertbar changes, and it is doing an insert into the insertbar. There is a category specified, this tells Dreamweaver which category (tab) of the Insert bar to display your object. If you want to create a new category, then you'd specify that here, this example is placing the Object on the Common category. then using the <button> tag, the file to run and its associated image is specified, along with a unique ID for the inserted item.

The Dreameaver extensibility documentation contains an error that could cause your variable grid to not display the column widths correctly. The documentation, found at Help > Extensions > Extending Dreamweaver > Contents tab > Overview > User Interfaces for Extensions > Using custom UI controls in extension > Adding a variable grid control , has this code sample:

<select name="ParamList" style="width:500px;" type=mmparameterlist columns="Name,SQL Data Type,Direction, Default Value,Run-time Value" columnWidth="100,25,11," size=6> </select>

The widths of the columns are specified in the columnWidth attribute in the code above, however, this attribute is actually called columWidths. Note the pluralization of the attribute name.

This error was encounterd by yeudoi in a thread at the Macromedia DW Extensions web forum.

I have been into Opera for some time now, and it's an excellent browser, particularly the "zoom" feature. Unfortunately I am sometimes prevented from operating certain sites, and I have found that Firefox reliably handles them, so I know it's not just IE-specific code at fault.

So, I have been toying around with FF1.0 a little, and I didn't care for a few of the ways it behaves, so I was reluctant to switch over. Well no more.

Today I went for it, and started gleaning thru the hundreds of new FF extensions to be had, and suffice to say, my mind HAS BEEN BLOWN. Right now an explosion is happening in the FF extension field, and the sky is the limit.

I'm literally chortling with glee (and I don't do that too often) over all the cool functionality now at my beck and call. Irritating Flash ads? Zap 'em. Don't like a particular image or text block? Kaboom. Ads in general giving you hives? Blacklist them, complete with wildcards. Woohoo! Blog tools galore, RSS stuff, developer tools, you name it.

And that's not all. There's a popup counter, showing just how many popups FF blocked for you on a page, along with the "all time high" # of popups ever blocked at one time. "Madge, I THINK I'm going to be sick!" You can select a plain unlinked url on a page, right click and off you go. Does it irritate you to have to register at every Podunk paper just to see some linked story, only to never visit again? Arrrr, ye be covered, Matey. >;-D One extension employs algorythms to make the mouse wheel scrolling butter smooth. Ahhhh.

This only scratches the surface of what's available, and the fun is just getting started. Consider "Fangs", which gives a text representation of what a screen reader would speak. Awesome. One extension even replicates my beloved "restore closed tab" feature from Opera. Happy happy happy! Joy Joy Joy!

Yes, I now feel a true master of my domain (no pun intended). It's good to be King.

Dreamweaver MX 2004 supports transparent PNGs as icons in its toolbars, unfortunately, Dreamweaver MX doesn't. MX does support PNGs, just not transparency. So if you're looking to have great looking icons on your toolbar, and you're also looking to support Dreamweaver MX, then you may be in for a bit of a surprise. However, all is not lost, I've found a relatively easy way around this.

The graphics designer at a company that I was creating a custom toolbar for really loved the transparent PNGs that he had created, and I must admit, they did look good. However, the toolbar also needed to support Dreamweaver MX, and when I broke the news that they would need to give up the transparent PNGs of MX 2004 just to support MX, the designer and the company owner, wasn't too happy. The company asked if there was anyway short of creating multiple MXPs, one for each supported version of Dreamweaver, to have the lovely PNG icons for MX 2004 and the adequate GIF icons for MX.

After thinking about things for a bit, I remembered that the toolbar XML files are initialized after the startup Commands are run. So taking that a step further, I placed GIF and PNG versions of the icon images in the toolbars installer MXP, and I created a startup command that would read in the toolbar XML file for their toolbar and edit the paths to point to the proper images based upon the version of the application that the toolbar was installed by by the MXP. Could have been done either way, but since more potential users were in MX at the time, I decided to make GIF the default image specified for the toolbar button icon rather than the PNG version.

Within the startup Command, a quick check of dw.appVersion to determine if any editing might be necessary (only needed for 7.0 and higher), and if so, the Command then used DWfile.read() to get the toolbar XML file contents as a string file, a simple RegExp is performed to see if and references to GIFs were present, and if there were, then simply replace them with the proper PNG equivalent. Then resaving the file using DWfile.write() and the transparent PNG problem was solved, as Dreamweaver would then load in the modified file.

Note: For more on startup Commands: take a look at: Event-Driven Dreamweaver Commands: Startup and Shutdown.

Now, you may have noticed that according to the instructions above, that it looks like the toolbar would get read in every time Dreamweaver is started, and you'd be correct. My first attempt at working about the PNG issue in toolbars, I wrote out a file that I'd check for its existence, and if it was there, I'd assume the XML file had been corrected. Unfortunately, then next time I made an updated version of the toolbar extension, the "already updated" file was still there, throwing off the test for rewriting the XML file, leaving me with the "bad" GIFs when I was expecting the PNG icons. So I went with the read always method, and only performing edits if I found GIFs present, which would only happen the first time Dreamweaver is started after an install, or update, of the toolbar extension.

Dreamweaver does not support displaying underscores in the text of a menu item. I found this out when following up to a question in the Dreamweaver Extensions group, How to use the underscore character in a menu extension. For an example, here is the code for a menu item for the Edit > Prefereneces menu item:

<menuitem id="DWMenu_Edit_Preferences" platform="win" name="_Preferences..." key="Cmd+U" enabled="true" command="dw.showPreferencesDialog()" />

Notice the underscore ( _ ) in the name attribute. This tells Dreamweaver that the letter P will be an access key for this menu item. Becuase of this functionality, underscores are not supported as being visually displayed as the text in a menu item. I've even tried escapping them by using \_ and doubleing up on them using __ and neither work. Interestingly, doubleing up does cause an ampersand to be displayed ( & ), but in no case is an underscore displayed.

Subsequently found out from a Dreamweaver engineer that underscores are not handled within the text of a menu item due to the access key functionality.

If you've been working long in the web world you've probably become accustomed to useing some type of include, be it #include with ASP, cfinclude in ColdFusion, include() in PHP, or other type of server side include. Well, Dreamweaver also offers this to you for use within its extensibility layer.

To include a file into your Dreamweaver extension, use code similar to the following:

<!-- #include virtual="demoInclude.htm" -->

The included file, in this case demoInclude.htm, will be pulled into your extension when it is run by Dreamweaver. The file being included can be referenced using a document relative path, or a root relative path. Root relative paths take as their root the Dreamweaver configuration folder.

Because of using the virtual method of including, Dreamweaver will automatically compensate for files located in the user's folder including files in the configuration folder for the application.

You may recognize this type of include as being quite similar to regular SSI type of includes, and you'd be correct. However, one difference is that the Dreamweaver includes only use virtual and not file references.

I ran across an interesting little Dreamweaver extensibility tidbit this evening while reading through the Dreamweaver application install Configuration folder. I'm writing it up now, as I'm not sure what use it will be for anything in particular any time soon for me, but I don't want to forget it.

You can invoke a JavaScript function in the page that you are editing. You can also call multiple functions within the page one after the other. Now, there is one pretty big limitation the function you're calling can't call other functions within the page. A bit limiting, but interesting anyway. Here's how you go about doing it:

var dom = dw.getDocumentDOM();
var p = dom.parentWindow;
p.runMe();
p.otherFunction();

Not milk-in-a-bag neat, but neat nonetheless, eh?

Using Tom's JavaScript Evaluation panel (or the Sniplet version), or within a Dreamweaver extension of your own, try the code above with a document that has the following code:

<html>
<head>
<title>DW invoke JS demo</title>
<script>
function runMe(){
document.content.innerHTML+= "add content ";
}

function otherFunction(){
alert("I can alert too");
}
</script>
</head>
<body>
<div id="content"></div>
</body>
</html>

Have fun playing around. Let me know if you come up with how invoking JavaScript functions within the document might be good to do. I haven't thought of anything yet that would be useful given the inability to call other functions from within the invoked function.

The topic slipped my mind for a while, but a thread in the Dreameaver Extensions forum I participated in brought it back up from the depths.

A while back I was testing out the code I was using to position the cursor for the column portion of the Go To Line Column extension. Code looked perfect, worked great....on paper. But wouldn't you know it, Dreamweaver had other things in mind. Funny thing was the if I added an alert() to try to figure out where the error was occurring, the error stopped happening. Remove the alert() and back comes the error.

Randy, one of the Dreamweaver engineers pointed out that perhaps it was a focus problem. When the user clicks into the text field to type in their column to go to, the document could be losing focus. He pointed out that there is a function used in a couple of places within Dreamweaver that can handle positioning the focus where you want it to, dreamweaver.setFocus(). This function takes a string as a parameter, with values of document, textView, or html. document places the focus into design view, textView places focus into code view, and html places the focus on the Code inspector (F10). All of these are predicated upon those views being visible at the time dw.setFocus() is invoked.

Interestingly, the reverse function dreamweaver.getFocus(), according to the docs, will return document, textView, html, site, or the name of the floater in focus. However, don't try site, or a floater name as the input to dw.setfocus() as you'll run into an error. Not sure exactly why that is, but that's how it works, at least in Dreamweaver MX 2004.

Yet Another Toolbar Item, brought up by installing Dreamweaver on a new system. It alwasy takes a bit to get things settled in correctly. Placing the toolbars properly, grouping panels, removing labels form toolbars, etc.

The Dreamweaver MX 2004 release introduced several feature removals. Among them, but not listed at the link above, the Code Navigation button on the Document toolbar was "removed" in favor of just being placed in the Code inspector (F10). The Code Navigation button allows the user to quickly jump to certain areas within the code of your page based upon the location of functions within the code. For example, if you were working on a page and you saw a call to a JavaScript function, you could use the Code Navigatioin button to jump directly to the function (as long as it was in the same page). That button instilled quite a habit in me I can tell you, expecially when building Dreamweaer extensions as they typically involve a lot of JavaScript functions.

You may have noticed that I put quotes around removed above. The reason for that is the Dreamweaver engineers didn't actually remove the functionality, they just commented out the small bit of XML code that told Dreamweaver to display the Code Navigation button. Not sure why they decided to do that, but when MX 2004 came out, I was temporarily lost until ~Angela told me about the commenting out issue.

So how do you get this button back? At it's simplest, all you'd need to do would be to uncomment the code for the button within the proper XML file: /Configuration/Toolbars/toolbars.xml**. However, due to to the way that Dreamweaver works with multi-user operating systems, if you have installed an extension that has modifed any of the built in toolbars, then you may find that the commented out code is no longer present within toolbars.xml.

Open up your user copy of toolbars.xml and look for code similar to that listed below. It may be all in one line rather than spaced out. I'd suggest doing a Find for DW_CodeNav, to see if it is present. If it is present and commented out, then uncomment it.

<menubutton id="DW_CodeNav"
image="Toolbars/images/MM/codenav.png"
disabledImage="Toolbars/images/MM/codenav_dis.png"
imageMac="dwres:18067"
disabledImageMac="dwres:18080"
tooltip="Code navigation"
enabled="dw.getFocus() == 'textView' || dw.getFocus() == 'html'"
menuID="DWCodeNavPopup"
update="onViewChange"/>

If this code is not present in your user config toolbars.xml, then copy the code above, and paste it into your toolbars.xml file within the <toolbar> tag with an id of DW_Toolbar_Main. If you want to keep the original placement from Dreamweaver MX, then paste the code just after the <button> tag with an id of DW_DocRefresh. Save toolbars.xml, then close and restart Dreamweaver, and you should now have the Code Navigation button present on your Document toolbar.

Note: You can also copy the code from the application install configuration folder. As well as the code for the reference button which was also commented out.

**Dreamweaver Configuration files locations