Extensioneering

require_once and includes above connections in Dreamweaver under PHP

Mon, 10 Jul 2006 17:45:48 GMT

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"); ?>

Dreamweaver 8.0.2 released 5/09/2006

Tue, 09 May 2006 20:06:04 GMT

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 released 1/16/2006

Mon, 16 Jan 2006 18:15:09 GMT

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 Presentation 1/23/2006: XSLT Authoring with Dreamweaver 8

Sat, 14 Jan 2006 18:13:25 GMT

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

Adobe Acquisition of Macromedia to complete December 3, 2005

Fri, 02 Dec 2005 23:03:43 GMT

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)

ANN 4-18-2005 : Adobe seeks to purchase Macromedia in an all stock deal

Mon, 18 Apr 2005 14:15:11 GMT

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.

<label> tag without a for attribute can crash Dreamweaver MX 2004 when used within an extension

Fri, 15 Apr 2005 04:18:10 GMT

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:

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.

Undocumented Dreamweaver: dreamweaver.popupCommand() and extra arguments

Wed, 30 Mar 2005 05:17:48 GMT

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.

Undocumented Dreamweaver: Hiding menu items (or showing menu items when a modifier key is pressed).

Thu, 24 Mar 2005 03:40:47 GMT

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):

Combining common message strings and variable parameters

Fri, 18 Mar 2005 23:12:49 GMT

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:

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.

Undocumented Dreamweaver: dw.loadString()

Sun, 06 Mar 2005 00:08:20 GMT

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:

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.

Dreamweaver JSExtension SWFFile.getNaturalSize() returns null in some cases

Sat, 19 Feb 2005 21:24:04 GMT

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  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 extensions for Dreamweaver MX 2004

Tue, 08 Feb 2005 03:02:14 GMT

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.

Objects for Dreamweaer MX installed with Extension Manager 1.5 need to specify Insert bar changes

Sat, 29 Jan 2005 16:18:03 GMT

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.

Dreamweaver extensibility documentation error: Variable grid control columnWidths attribute

Fri, 14 Jan 2005 17:18:05 GMT

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:

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.

Transparent PNGs and Dreamweaver toolbars

Mon, 10 Jan 2005 21:13:44 GMT

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.

Underscores not supported visually in Dreamweaver menu items

Thu, 06 Jan 2005 21:46:03 GMT

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:

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.

Undocumented Dreamweaver: Using Includes for code reuse within a Dreamweaver extension

Wed, 05 Jan 2005 02:53:26 GMT

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:

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.

Undocument Dreamweaver: Run a JavaScript function within the page you're editing

Thu, 23 Dec 2004 02:29:13 GMT

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.

Undocumented Dreamweaver: dreamweaver.setFocus()

Thu, 16 Dec 2004 03:14:32 GMT

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.

Return the Code Navigator to Dreamweaver's Document toolbar

Fri, 10 Dec 2004 16:54:33 GMT

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

Removing unwanted labels from Dreameaver toolbar buttons

Thu, 09 Dec 2004 15:20:15 GMT

Since I'm on the topic of toolbars, I wanted to share a quick space saving tip for the Document toolbar. When Dreamweaver MX 2004 first came out, I was disappointed that I didn't have a preference setting option to turn of the labels for the View icons. No I don't mean, The View, that trite morning show with insipid hosts, I mean Code, Design, and Split View buttons on the Dreamweaver Document toolbar.

If you'd like to remove the text from those icons, either to save room, or because you know what they do already, the fix is relatively easy. Open up /Configuration/Toolbars/toolbars.xml. To Locate this file, check out Dreamweaver Configuration files locations. Check in the User's folder first for the file. If it isn't present, check in the All Users/root folder, then check the application install folder. In that order, the first one you find, open toolbars.xml. Next, look for a <toolbar> tag with an ID of DW_Toolbar_Main. It should be the first one listed. Then, the first 3 tags are the tags related to the view buttons. Look for the label attributes and set the value to an empty string. i.e.: label="".

Save toolbars.xml, close and restart Dreamwevaer, and your View icons will be label-less.

As with any configuration edits, make a back up copy. For many of the Dreamweaver XML files, it is best to give the back up a different file extension, or save the back up outside of the folder you're modifying.

Keeping your toolbars visible in Dreamweaver

Mon, 06 Dec 2004 16:08:29 GMT

When you install some extensions, Dreamweaver has a nasty habit of resetting your toolbars. So if you have the Standard toolbar visible, you may find after installing an extension that the toolbar has been turned off and isn't visible any more. There may be more situations where this happens, but I've seen it happen when you install an extension that modifies the menu system, if you install a toolbar extension, or if you reload extensions.

To see your toolbars getting reset, CTRL+Click on the Options menu of the Insert bar when it is Tab layout, and select Reload Extensions. Please note that resetting your toolbars will cause them to stack up vertically, turn off any toolbars that are not set to be visible by default, and the toolbars will get reattached to the document window, if you have moved your toolbars off of it.

While you can't stop Dreamweaver from resetting your toolbars, you can stop it from turning off the toolbars that you want to remain visible:

Go to your user configuration folder and open up /Toolbars/toolbars.xml. If you do not have toolbars.xml in your user folder, then go into the application install folder and open that toolbars.xml file. Back up the file, by saving a copy with a different file extension, or save a back up copy in another folder. Within toolbars.xml, look for the <toolbar> tag with an ID of Standard_Toolbar. Change the value of the initiallyVisible attribute to "true". Save toolbars.xml and restart Dreamweaver.

If you have other toolbar extensions installed, and they disapper, then you can change the initiallyVisible attribute to true and they won't disappear when your toolbars are reset. Some toolbar extensions will install their own XML file into the Toolbars folder. You'll need to open that file in order to perform the necessary edits.

Adding a preview image for a page design in Dreamweaver's New Document Dialog

Wed, 24 Nov 2004 04:58:15 GMT

While building the Seattle JumpStart extension, I ran into a small issue. The previous extension I had made that added an item to the New Document dialog for Dreamweaver, the page design previewed just fine. Unfortunately, the Seattle pages used some styling that didn't render as well as a browser does. And because Dreamweaver uses it's own rendering engine for the display in the Preview area, the preview of Seattle pages didn't show up as well as they could. Fortunately, Dreamweaver engineers built in a method of allowing the extension developer the ability to specify a preview image.

As with the rest of the options for a page design extension, the setting for the preview is stored within a Design Note for the page design in question. So to display the image seattle.gif that is saved in the same folder as the file that it is representing, the following code has to be added within the <info> tag:

Design Notes are saved in a _notes folder within the folder that the file resides. Design Notes are named by taking their associated file and adding a .mno extension to the end. For exmaple, the home page for Seattle is called seattle.html within the files for the New Document dialog (for Seattle: Configuration/BuiltIn/CMX JumpStarts/seattle/ ), so it's Design Note file would be named seattle.html.mno in a _notes folder within the seattle folder, or Configuration/BuiltIn/CMX JumpStarts/seattle/_notes/seattle.html.mno

Be aware that _notes folders are not displayed within the Dreamweaver Files panel, so a quick way to find the Design Notes files is through through your file manager.

Copy Dependent Files dialog does not appear when creating a page from a page design

Mon, 22 Nov 2004 17:13:27 GMT

While creating the extensions that add the various CMX JumpStarts to the Dreamweaver New Document dialog, I ran into a problem where the Copy Dependent Files dialog that specifies the location to save the associated files for a page design did not appear. Turns out that Dreamweaver is a little picky regarding the location of defined sites and the New Document dialog. Below you'll find the note that is included in the article that accompanies at least the first few CMX Jumpstarts packages:

Note: The Copy Dependent Files dialog may not appear on your system if you have one or more sites defined that point to the Dreamweaver application, or user configuration folders. This tip will generally only be applicable to extension developers. Our experience has found that to get the Copy Dependent files dialog to reappear, you have to remove the definitions for your configuration sites (remember to export first), and restart Dreamweaver.

Upon further testing, it appears that the issue is triggered by having a site that is defined that points to the user's configuration folder. Haven't tried it, but given Dreamweaver's multiple configuration folders, a site defined that points to the All Users config for a Windows users, or the root user folder for a Mac-head, is likely to trigger this issue as well.

Undocumented Dreamweaver: Take out the garbage - dw.forceGarbageColletion()

Fri, 19 Nov 2004 04:59:19 GMT

A thread on memory leaks in the DW extensions group a couple of days ago caused me to remember a undocumented function that told me about a couple of years ago: dw.forceGarbageCollection(). He mentioned it to me when I was working on an extension that would do a lot of site-wide processing that would take up a lot of memory and frequently caused Dreamweaver to crash on larger sites (1500+ files).

Essentially, dw.forceGarbageCollection() is supposed to cause Dreamweaver to clean up any memory the application was using to store variables that aren't being used any more. Paul told me that the function doesn't actually force it to run at that moment, just that it tells DW that it should try cleaning up its memory usage. Any attempt to clean up the used memory will typically occur when DW is idle, so as to not be processing that when it should be processing the user's instructions.

Turns out that the function didn't help me any, as I wasn't freeing up references to objects being stored in memory, so once I cleaned up my code the problem went away, but the poster in the memory leak thread above, it worked just dandy. Thought you'd like to be aware of it in case you're running into Dreamweaver memory usage problems.

Dreamweaver Drag Layer behavior broken in Mozilla with valid doctype (solution provided)

Tue, 09 Nov 2004 20:30:25 GMT

Due to "old" coding, the Drag Layer behavior with Dreamweaver (up to and including DWMX2004) does not work in Mozilla, and likely other standards compliant browsers, when the page has a valid doctype, but works in IE6 and probably earlier. There are two methods to fix this problem:

Put the browser into quirks mode by deleting, or "breaking" the doctype
Fix the broken code

What with everyone clamoring to be valid these days, I'll address the second method, fixing the code. Open up:
{dw install folder}/Configuration/Behaviors/Actions/Drag Layer.js
on my Windows XP Pro system, this is at:
C:/Program Files/Macromedia/Dreamweaver MX 2004/Configuration/Behaviors/Actions/Drag Layer.js

Note: See Dreamweaver Configuration files locations for a location near you.

In Drag layer.js go to line 161 and change it from:
else if (NS6){style.left = newLeft; style.top = newTop;}
to:
else if (NS6){style.left = newLeft+'px'; style.top = newTop+'px';}

Then go down to line 174 and change it from:
else if (NS6) {style.left = MM_targL; style.top = MM_targT;}
to:
else if (NS6) {style.left = MM_targL+'px'; style.top = MM_targT+'px';}

The first change allows the specified layer to be dragged, and the second change allows the layer to snap to a location when dropped if that option is selected within the Drag Layer behavior dialog. Notice in both cases, all we added the units to the values being assigned.

Close and restart Dreamweaver and it should happily add in the correct code to run in valid pages for Mozilla.

Please note that Safari doens't seem to like Drag Layer. It has something to do with Safari being identified as a Netscape browser by the script, and routing of the drag event. Anyway, Safari won't let you drag a layer using this behavior.

Drag and Drop from Dreamweaver's Components panel triggered when drag is started

Mon, 01 Nov 2004 15:20:50 GMT

Just making a note for myself and others that may run into it...

getCodeViewDropCode() in /Configuration/Components/Common/CFCs/CFCs.js runs when the drag is started and not when the dragged item is dropped. Not so much a big deal really, but if you wanted to pop up a dialog after the user had selected the drop point, you're pretty much outta luck. Well, at least I was when I tried using this function to show a dialog to allow the user to make a selection or two related to the CFC being dragged, and then generate the code to drop. ;-).

If anyone knows if there is a way to access the drop event from the Components panel, please leave a comment. Thanks.

Font chooser within a Dreamweaver extension

Sat, 23 Oct 2004 16:50:56 GMT

While working on an extension that I'm hoping will combine Dreamweaver and Flash I needed to have the user select the font that they want to use. So I used the API call dw.getSystemFontList() to grab a list of fonts to display to the user, and then dropped the list of fonts into a select list to give the user their choice of fonts.

To do this, add the ListControl class to your extension (see Fill a list with defined site names for how to do that), then add a select list to your extenion dialog, give it a name of "fontList" and then in your initilization function, add the following code:

var fonts = dw.getSystemFontList('all');
FONT_LIST = new ListControl('fontList');
FONT_LIST.setAll(fonts);
processFontChange();

Voila, instant font list. getSystemFontList() can also take 'TrueType' to list only the TrueType fonts on the user's system.

Extension Manager crashing on Mac OSX

Sat, 16 Oct 2004 18:11:50 GMT

Adding this entry because I've seen a number of people come across this bug recently.

What happens is that when Extension Manager is starting it crashes, and says that there was an unspecified error. This is happening because of a bug in either the way Extension Manager reads in the installed extensions within Dreamweaver or in the way that it installs Dreamweaver extensions that causes the reading in of extensions to break. I've not seen this issue with non-Dreamweaver extensions, but I've seen the crashing reported when installing an extension into another product such as Flash through Extension Manager. Apparently this has been a problem since Dreamweaver MX, and continues on with Dreamweaver MX 2004 on Mac OSX as there is a TechNote on the issue: Extension manager crashes upon launch after installing extension to Dreamweaver MX 2004. If EM is crashing on you, then please give it a read.

There is change to the process described with the TechNote that I think would be good to make. I would suggest moving one MXI file at a time into the "Hidden" folder, starting with the extension that was installed most recently and moving backwards, testing EM on each move to see exactly which MXI file EM is choking on. When you find the one, then start moving back the other MXI files making sure to again see if EM crashes.

As an extension developer, I think it fair to mention that this is not the responsibility of any particular extension; this is an issue with Extension Manager itself. Reason being is that I've seen this issue reported a number of times over the past year or so, and I've yet to see the same MXI file implicated more than once.