This responds the same as before in CS4 Commercial version.

In the latest version of Dw CS4, they have introduced relative file management (Related Files). Breadcrumbs style links that show which pages are being used for quick and easy access. This is a great feature, but has added an obstacle during development.

In the Dw preferences there is a check box to open CSS file when modified. With this unchecked, the changes should be saved to the file right away.  The downside to this is a loss of the history of changes for multiple undos. But this speeds up productivity tremendously and ensures you do not have any unsaved css files remaining in the background when you test in the web browsers.

With the new Related Files bar feature, and that check box turned off, the file remains open and unsaved. When using the preview in browser command, it does not ask to save the changes to the file. You have to manually click on the css relative file or choose the “save all files” before previewing.

In a normal workflow I like to be able to see my changes on the fly, without having to perform a save all, or go to the file and save. 

My suggestion would be to offer this as part of the preferences. The open CSS when modified, I believe, was intended for this workflow. Dreamweaver is essentially opening, writing, saving, and closing the file in the background when this is checked. So it does not seem like it would be much of a leap to have dreamweaver automatically save the file when you have finished making changes in the CSS dialog editor. Perhaps Dw would offer the following preference/checkboxes instead.

• Save externally linked CSS files after each edit in the CSS Palette

This would only include css files that were modified but not currently open or included in the relative files bar. If the CSS file was open as a stand alone edit, it would remain unsaved as expected.

Still responds the same in CS4 Comm. Dist.

When using the Duplicate style command Dw places the duplicate at the bottom of the css. While this is not such a big deal when you have 3-4 selectors, when you have a large site it can get lost in the mix. organization of selector order it extremely useful for managing the styles.

When creating a new CSS rule (dialog), it places the new selector under whatever selector you have selected. This is great, and should preform the same way when you create a duplicate.

Current Workaround: Option + Click and Drag the selector puts it where ever you want, works on multiple selections too. Copy and paste from within the code.

Still not working in CS4 commercial distribution. At least it still lets me close out of all open files and test the frameset. But you have to tell it to stop warning you, and test locally. Its a workaround. Testing frames should be possible from all angles.

I am at a loss on wether this should be part of my wish list, or a bug. When setting up a testing server (PHP & MySQL), Dreamweaver does not allow the previewing of Frames with the URL prefix.

Whenever I am teaching about testing servers this really throws the student for a loop. Not only are they trying to wrap their head around the idea of a testing server, but struggling to know why the lights do not turn on. If you press ignore, or publish it fails to add the URL testing Server prefix and the student ends up seeing the plain text instead of the resulting PHP page.

I have yet to understand why the Dw developers do not allow the author to preview frames on a testing server. I imagine because framesets rely on multiple files that would need to be published to the testing server to work, however, isn’t this the role of publishing dependent files?

Workaround
I have found that if you tell Dreamweaver to stop warning you about this you can get the frameset to preview in the web browser. However, you must close out of all open files and preview the file from the Files palette. I think that dreamweaver does not check to see that it is indeed a frameset file if the file has not already been opened.