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:

<infoitem key="mm_new_doc_preview" value="seattle.gif" />

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.

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.

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.

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.

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.