Ext.MessageBox does not stop program flow

[TheBerliner]

I am going nuts over a trivial problem using Ext.MessageBox asking the user to a confirm a question. I am using Ext 3.1.1. and I took the code from the message box example #4 from ../examples/message-box/msg-box.js and embedded it into some method in one of my classes to call it from my code. Here is this method:

Translation.prototype.openDialogYorN = function(title,text){
         Ext.MessageBox.show({
           title: title,
           msg: text,
           buttons: Ext.MessageBox.YESNOCANCEL,
           fn: showResult,
//         animEl: 'mb4',
           icon: Ext.MessageBox.QUESTION
       });  
    };

function showResult(btn){
        Ext.example.msg('Button Click', 'You clicked the {0} button', btn);
    };

The program flow never stops to wait for user response after showing the message box!

I don't understand that, especially because this is exactly the same code that is used in the example - with the only difference that it is "isolated" into another method and not called from any event.

What am I doing wrong?
This is so trivial....

Just for the records: In the "doc" it says: "showing a MessageBox will not cause the code to stop. For this reason, if you have code that should only run after some user feedback from the MessageBox, you must use a callback function (see the function parameter for show for more details)."

Well, I am clearly using a callback function - or rather so does the code copied from the example. Thus, either must be wrong: the doc or something in the code.

Thanks for any hint!

[sunco]

Crystal clear "Note that the MessageBox is asynchronous"

Unlike a regular JavaScript alert (which will halt browser execution), showing a MessageBox will not cause the code to stop. For this reason, if

"For this reason" is not the same as "For stop the flow"

I agree with you that sometimes the docs are not enough clear, but this time i see it crearly

The callback is just for catch the pressed button, not for stop the flow

[TheBerliner]

Well, thank you for commenting that but I have well read this "doc" very carefully and more than once. It also says: ".... For this reason, if you have code that should only run after some user feedback from the MessageBox, you must use a callback function (see the function parameter for show for more details)."

In other words, as this mst be understood: You must supply a callback function to use this class on purpose, i.e. to have it wait for some user response. That is exactly what the code in this example is doing (not even my code, taken from Ext example). A MessageBox without user response is totally useless.

Therefore I disagree with you and again: Either MessageBox has some bug(s) or this documentation is great crap and in the latter case (if you are right) MessageBox is pretty useless for a real life app.

Still: Why does it then work in the example when called from an onlick?

So here is something fundamentally wrong in Ext!



P.S. In a "good doc" it would be explained how to properly use this class aka how to circumvent this great deficiency. But I have given up hoping for a good doc, because obviously this would kill Ext's business model, which seems to rely on users asking for paid doc substitution through "support" (which normally is meant for different purposes).

[sunco]

"Still: Why does it then work in the example when called from an onlick?"

Add an alert after the MessageBox and you will see how is displayed

A workarround:

- Move the code after MessageBox to a function
- Show the MessageBox and set a flag to True (because the MessabeBox is still show)
- When the callback is fired you can set that flag to False

- Use DelayedTask to see the flag state and then run a function

"is pretty useless for a real life app."

I disagree completely with this. I have app's little big with no MessageBox problems (not an expert)

[TheBerliner]

"Still: Why does it then work in the example when called from an onlick?"
Add an alert after the MessageBox and you will see how is displayed

I see the box displayed but inside my method the flow does not stop (like it does in the example with onclick).

A workarround:

Muchas gracias para las explicaciones sobre los problemas de Ext!

It's absurd that a $ 330 package is incapable of supplying a trivial and properly usable MessageBox / Confirm box without hacks and tricks.

I am designing my code as much o-o as possible and thus it's out of the question to "move code after MessageBox to a function". This would mean tightening o-o application logic (i.e. model) to a UI widget (i.e. view) and that would be a deadly sin. I am not going back to procedural stoneages because of Ext and the use of events that the Ext people are so proud of doesn't make this any better and it's nothing special either. Events have been common pratice in Smalltalk since the mid 80-ies and, if properly used, don't disturb pure o-o design.

Ok, so one more great disadvantage of Ext discovered! Thanks again for the clearer view. I meanwhile found out that this was discussed and critisized long ago but the Ext people don't seem to have learned from it.

[evant]

It's not possible to stop the program flow in JavaScript unless you use the native prompt(), confirm() or alert() methods.

The docs are quite clear in explaining that you need to callback if you must wait for input.

[tryanDLS]

Ok, so one more great disadvantage of Ext discovered! Thanks again for the clearer view. I meanwhile found out that this was discussed and critisized long ago but the Ext people don't seem to have learned from it.

Once again, as in you previous posts, you seem to want to argue every point, take shots at the doc and at ExtJs the company, when you don't understand or disagree with an answer.

This is NOT a design-flaw or disadvantage of Ext - it's how JavaScript works. You cannot truly stop execution without using the built-in JavaScript alert, confirm type functions. If you had read this thread and the other thread with an open mind, instead of thru the colored glasses of your strict Smalltalk and windows programming paradigm, you might be able to take some understanding away from what a number of people have spent a good amount of time trying to explain in both threads. You can't program the browser in exactly the same manner as the Windows GUI, regardless of the client-side toolkit you choose.

You might not like this, but once again, that's the way it is. If you'd like to argue the point further, you might want to try comp.lang.javascript - maybe someone will put this in the next version of the JavaScript language.

Thread closed.