Here is how this really works:
1. Changes you make to the DOM always take effect immediately. If you make
any change to the DOM and then immediately follow that with code that looks
for your change, that code will indeed see the change. For example:
$('#mydiv').html( 'hello' );
alert( $('#mydiv').html() ); // alerts 'hello'
2. BUT... The browser does not refresh its display until your JavaScript
code finishes running. So the user will not see any of your changes until
then.
3. A synchronous Ajax call does not let your JavaScript code finish running.
In that sense it's just like your hard loop. The user will not see anything
you change in the DOM until after that call finishes and your code stops
running.
Why do you need a synchronous Ajax call? This is a VERY bad idea. In
single-threaded browsers such as Firefox, it's not just a matter of the page
display not refreshing. Your code will completely lock up the browser's user
interface - menus and all - and not just for the current browser tab or
window, but for *all* browser tabs and windows.
Can you use the BlockUI plugin to simulate the effect you need? This would
be MUCH better than using synchronous Ajax:
http://www.malsup.com/jquery/block/
If you must use a synchronous Ajax call and you want the user to see a
message you put into the DOM, then you will need to yield control after you
add the message but before issuing the Ajax call. You can do this with
setTimeout.
Where you have code like this:
$('#message').html( 'Sorry, dude, I will now lock up your browser' );
$.ajax({ async:false, ... });
You need to change it to:
$('#message').html( 'Sorry, dude, I will now lock up your browser' );
setTimeout( function() {
$.ajax({ async:false, ... });
}, 1 );
That will allow the user to see your message before you lock up the browser
by issuing the Ajax call.
But what would be the point? By using setTimeout() you've made the code
asynchronous anyway. So you could just use asynchronous Ajax in the first
place, with BlockUI to give the blocking effect you want in the UI.
-Mike
On Mon, Nov 16, 2009 at 3:21 AM, nowotny <nowotn...@gmail.com> wrote:
> On 16 Lis, 11:40, Michel Belleville <michel.bellevi...@gmail.com>
> wrote:
> > Well for a start I wouldn't use a this kind of pause() trick if I were
> you,
> > it's pretty brutal suff looping along until time has passed will likely
> > freeze your interface and that's a bad thing.
> Like I said... it's only a stand in for the ajax call that'll replace
> it in the end... the thing is I have to test if on the IP and port the
> user specified there is a certain service running and if a user puts
> in an invalid IP (where the service is not running) the ajax call
> takes some time (until timeout) to process... during that time the
> interface is frozen and I want it to be... I just want it to show that
> it's testing the connection and I thought putting "Testing" into DOM
> before doing the ajax call would inform the user what's happening but
> it's not being changed until after the whole function finishes
> processing when it's already to late cause I already have the results
> of the ajax call...
>
> > You'd probably be better off
> > with a setTimeout() which would delegate exécution of a callback after
> the
> > time, thus truely imitating an Asynchronous call.
> Again, I said I want to do a synchronous ajax call... and I don't need
> to delay anything so setTimeout() is not needed here...
>
> --
> nowotny
>
