If you are running DNN on your localhost, then if you edit the ascx file in your skin folder associated with the portal page that you are editing, then once you do your edit, as soon as you press F5 the changes you just made appears in whatever browser you are looking at the page. If you are in Edit mode in your browser, you will not see exactly what users (NOT IN EDIT) see. So that is why I suggested to also have another browser like FF look at the same page (NOT IN EDIT) - that is if you have IE open in Edit.

HTML editing requires an additional step before you see your resulting changes in your skin. Since HTML needs to be parsed by the core to overright the ASCX, therefore you need to have your ADMIN/SKIN or HOST/Skin page open so that you could parse the skin. That is the additional step that most skinners in DNN world dont like. However, once you are like me having done so many, the process is quick enough. Since I eventually want to deliver a HTML skin to the customer so to ensure better future upgradablity, this little extra step is well worth it.

Salar

Hi Bill,

The server extensions are needed if you want to manage a remote DNN file system with EW. If you are using EW directly on local files and only editing them indivdually rather than in context of each other, then it isn't necessary. It is also not needed if you use an application like SmartFTP as an intermediary between the server and the editor. However then you don't get the benefits of EW as a file manager. If EW is in full control and is aware of the file system as a 'Web' then you can do all the cool EW things like follow code links and shift files around quickly freely.

The method I was assuming you'd want to use was the one with the fewest steps between edits and live viewing... and that means editing the ASCX files directly on the server. Use another browser to view the results like Salaro has said - I always keep IE open and signed in, and Firefox open and not signed in, or sometimes the other way around. 

Tip: In order to get a better view of the skin in the EW design or mixes pane, it is very helpful to insert a stylesheet link into the skin during the editing phase. Be sure to remove the link when you're finished with the skin however. When you're working on HTML skins you don't get the effect of the classes that are applied to objects via the XML file unless you parse the skin. In the ASCX skin you will see all classes in action directly in EW.

When you're working on the live server it's so quick and easy to copy and paste skin folders to make new ones or backups. In additon, you can carry out portal upgrades, modify module files, language files, the web config, and edit almost any other file with a proper code view - and most usefully for a hack like me, EW looks after all the syntax and suggests code and styles where appropriate - I've learned a lot from that.

The point about avoiding the portal folders was meant in relation to client sites on your DNN instance. You're correct of course that you can't avoid the portal folder where the skin is when you're actually working on that skin. However, it's also irrelevant to DNN whether the skins folders contain EW file stubs, so you can actually go in there and make changes and not worry about it. The only place you don't really want the stubs to show up is in the content folders for the portal. If you have remote access then it's just a matter of doing a search on the DNN folder for "_vti_cnf" and then deleting the result.

There's really nothing easy about DNN skinning until you've sorted out a good edit and view process and have it down pat. Until then it does make one feel stupid and I've got plenty of early posts along those lines.

The most important and productive things for me have been working on the live file system with EW, and using Firefox with the Firebug and Web Developer add-ons to carry out troubleshooting.

Rob

You'll still see the DNN controls rendered as grey boxes with "Error rendering control" in them, but treat them as if they were tokens. You can drag them around the page in the design view if you want. They do also upset the exact layout of the page, but for the 100% accurate view, just click the view in browser button. At least you won't have had to package and upload a skin or wait and parse one on the server.

To add the style sheet link, open teh ascx skin, go to format, CSS Styles, Attach Style Sheet, then type the name of your skin.css into the box and click Ok. It will insert something like this into the code:

head>
link rel="stylesheet" type="text/css" href="skin.css">
/head>

But with the proper angle brackets that I'm sure would stop it being displayed here in the forum.

Now you will see your styles applied in the design view. Note that this does not apply styles from other sheets such as default.css. Add links to those if you need to, but normally you won't. Note also that the skinpath function doesn't work in this view, but none of this will matter much in the end. Ultimately you'll find yourself on a much faster learning curve towards working in code view. The super-quick saving and viewing of your edits makes it all the more fun and productive. Skinning was just a nightmare before I finally settled on all of this.

Remove the stylesheet link when you're finished with the skin because DNN automatically loads the sheet for you andyou don't need it loading twice, as the second load actually overrides the portal.css. There are plenty of skins and containers on Snowcovered with that issue.

Rob