Can you wait for javascript callback?

You've just hit a big limitation in JavaScript. Once your code enters the asynchronous world, there is no way to get back to a classic procedural execution flow.

In your example, the solution would be to make a loop waiting for the response to be filled. The problem is that JavaScript does not provide any instruction that will allow you to loop indefinitely without taking 100% of the processing power. So you will end up blocking the browser, sometimes to the point where your user won't be able to answer the actual question.

The only solution here is to stick to the asynchronous model and keep it. My advice is that you should add a callback to any function that must do some asynchronous work, so that the caller can execute something at the end of your function.

function confirm(fnCallback) {    jConfirm('are you sure?', 'Confirmation Dialog', function(r)     {        // Do something with r         fnCallback && fnCallback(r); // call the callback if provided    });}// in the calleralert('begin');confirm(function(r){    alert(r);    alert('end');})

jConfirm('are you sure?', 'Confirmation Dialog',    function(r) {        result = r;        response = true;        return r;    });if (response == true) {

This betrays a misunderstanding of the sequence of events that occurs using asynchronous code. Just because you've written it inline doesn't mean it's going to execute strictly top-to-bottom.

1. jConfirm is called, receiving a function as one of its parameters, which it remembers.
2. jConfirm displays its UI on the page and returns immediately.
3. The 'if (response==true)' line executes. Really this should just read 'if (response)', the boolean comparison is superfluous. But in any case response is of course false. Your function gives up and exits, giving control back to the browser.
4. The user clicks jConfirm's UI.
5. jConfirm only now jumps into action and calls back the function you gave it and it remembered earlier.
6. Your nested function sets response true, far too late for the 'if (response==true)' condition to do anything with it.

You have written "//wait for response" as an alternative, but there is no JavaScript code you can write that will actually do that. Your function must return to give control back to the browser, before the browser can fire the click events on the jConfirm UI that make processing proceed.

Ways to make asynchronous code work in a synchronous context (and vice versa) exist - in particular threads and coroutines (and their limited relation generators). But JavaScript has none of these features, so you must write your code to fit the synchronous-or-asynchronous model your library is using.

Since the callback is asynchronous (at least, in the sense that it's waiting on the user to do something), it might be easier to handle what you need to inside the callback:

function confirm() {    jConfirm('are you sure?', 'Confirmation Dialog', function(r) {        if (r) doSomething();    });}

@klogan [comments]

I assume you got these from here?

The page gives you your answer: (look under Usage)

These methods do not return the same values as confirm() and prompt(). You must access the resulting values using a callback function. (See the demo for more details.)

@klogan

The point I'm trying to make is that there isn't really an easy way to accomplish what you want. You're trying to correlate procedural and event-driven programming -- something JavaScript doesn't help you do.

The simplest (though, risky) solution is to use a pseudo-infinite-loop. But, if callback never gets called, you now have an actual infinite loop. And, depending on the JavaScript engine, you might kill the browser waiting.

function confirm() {    var result = false;    var response = false;    jConfirm('are you sure?', 'Confirmation Dialog',      function(r) {        result = r;        response = true;    });    while(!response) continue; // wait    return result;}