JS Script hang error in DW CS5 (uncommon issue)

Greetings. Sorry to be an early embracer but extension opens but then hangs (see screenshots). Tried the dat remove trick, though I think its not related; tried clearing the JS cache manually. No joy. Looking forward to v1.1. Thanks!

This seems to be a rare issue with site settings that we haven't been able to reproduce. I have opened up a backend ticket to take a look at this issue with you. To check your backend ticket, log in to your account and check your support history.

Greetings. Hoping for an update? Thanks.

We were able to determine the issue having to do with a site being defined in CS4 and the same site then being defined in CS5.

A workaround is to add a testing server to the site definition. This will update the site variables to be stored in the way CS5 is looking for them.

Thanks Ray. This was a new site in CS5 that was minimally defined per the new feature set in CS5 of only having to define a name and local root. I went back and added a remote server which allowed the extension to open. But the extension runs very slowly, hangs up when adding new pages, moving pages in the tree, etc. while still only defining them. I have seen this in general with WebAssist extensions which provide page previews in the wizard but this one is basically dramatically more unstable than others. Machine is a 2xquad core Xenon with 16GB RAM, running XPP SP3, with no antivirus/firewall/etc., strictly setup for dev work. Will keep my eyes out for the next release as I'm sure these issues will get sorted. Cheers.

If the issue is related to preview, then perhaps try going to the menu item Edit->WebAssist Preferences, and try disabling the preview. You will still be able to click to preview in a browser.

If that speeds it up, significantly we could consider adding a preview button to update the preview onclick of a button instead of automatically updating.

Originally Said By: Ray Borduin

  We were able to determine the issue having to do with a site being defined in CS4 and the same site then being defined in CS5. A workaround is to add a testing server to the site definition. This will update the site variables to be stored in the way CS5 is looking for them.  

Hi Ray,

I have exactly the same problem as "webassist285130", with Site Sculptor on Dreamweaver CS5 hanging and the Javascript-related error message popping up after a few minutes.

Site Sculptor is my first purchase from WebAssist and I did expect a well-tested, high-quality product from the company. I'm actually very disappointed about this issue which should have been resolved during testing, and why WebAssist would release a product that will not run "right off the bat" on CS5.

We don't want to have to create a remote/test server early in the site-building process and disable the preview feature as suggested just to make Site Sculptor work. I expect Site Sculptor to make it easy for me to do my work, not hinder it.

I appreciate your effort and feedback to assist us here, but please do try to resolve this issue ASAP with an update to Site Sculptor.

All the best,

Oscar

We try to fix all bugs reported in a timely matter. This one will be included along with any others reported in a free update.

Technically it is a CS5 bug that a call to get the number of sites returns a very large number when in fact it should return zero when no sites are defined. We will produce a fix to work around this CS5 bug soon... as you can see it was reported about a week ago and we just found the problem 4 days ago, 2 of which were a weekend.

In the meantime we are giving the work around to set up a test server, even a fake one, in your site settings and it will then properly update your site settings to the cs5 format that doesn't cause this issue.

Thanks Ray.

As I inferred previously, this should have been a simple test scenario which could have resolved the issue with adequate testing for CS5. I wasted time doing an uninstall-install-uninstall-install with this puppy trying to make it work.

Looking forward to the update, though.

So far you and I believe two other users total have been able to reproduce this problem. We were only able to debug it and find a fix by calling one of those users on the phone and doing a screen share and investigating on thier machine.

We have tried repeatedly to reproduce the error even after it was reported and we are still unable to. We still don't know any simple test scenario that causes this problem. We are lucky enough to report we have a workaround for now and a fix coming in a future update.