Dreamweaver adds connection incudes at the top of the file using code similar to the following:

<?php require_once('Connections/localhost.php'); ?>

If you add code above the connection includes using require_once(), or include() and you use single quotes around the file name, then Dreamweaver will mark the Recordsets in the ServerBehaviors panel as broken. If you try to inspect the recordset to fix it, once you click OK, the include is removed (or the first include is removed, if you have more than one include at the top of the page).

FIX: If you switch to using double quotes around the file names, then the recordsets aren't marked as broken, and the require_once() and include() aren't removed, as in the following:

<?php require_once("myinclude.php"); ?>

Adobe released an updater for Dreamweaver 8 to push the version up to 8.0.2. Included in the 8.0.2 release are updates to server behaviors that prevent SQL injection. The updater can be found in the Dreamweaver support center. For those that interested check out the release notes to see what has been changed.

Dreamweaver MX 2004 users can update their code by following the directions for: ColdFusion
PHP
ASP VBScript
ASP JavaScript
JSP

Dreamweaver 8.0.1 updater has been released, check out the Dreamweaver Updaters download page for are a link to the updater.

Read over the Resolved Issues in case you're one of those, "if it ain't broke, don't fix it crowd" to see if it'll help you with any problems that you're experiencing.

Also, before you install, or if you have installed and ran into a problem or two, make sure to check out the Dreamweaver 8.0.1 Updater installation issues page.

MMUG Chicago, The Chicago Area Macromedia Users Group presents:
"XSLT Authoring with Dreamweaver 8"

Unless you have been snoozing, you know that the use of XML is growing by leaps and bounds, especially with RSS rapidly taking off. Briefly, XSLT (Extensible Stylesheet Language Transformations) is a way to format and display XML documents.

Join us Monday January 23rd when Danilo Celic, of Team Macromedia, will explain exactly what XSLT is, why you'll want to use it. Danillo will demonstrate how you can use the new XSL tools in Dreamweaver 8 to assist you in creating content for your pages with data derived from XML sources. In true Dreamweaver fashion, these new features enable you to visually edit your XML derived content with drag and drop ease.

MONDAY, JANUARY 23rd, 2006
Illinois Institute of Art Room 234
180 North Wabash Chicago, IL
Doors open at 6:00 meeting starts 6:30PM
FREE

Parking garages around the area and accessible from the Randolph/Wabash EL stop, or Lake Street Red Line Stop.

http://www.mmugchicago.org

I figure since my last post was on the announcement of the acquisition that I may as well post the news of it becoming final. From Macromedia's Press Room: ADOBE’S ACQUISITION OF MACROMEDIA EXPECTED TO CLOSE ON DECEMBER 3, 2005

Of course, until we hear through the offical channels what changes are to be made,  I'm sure a lot fo folks will be on edge (especially those with jobs in the line of fire), but I'm not so worried. This world is full of change and we'll keep going onward and upward.

Here's to Macromedia! Here's to Adobe! (raises first of several beers of the night)

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" />

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 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.

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.