https://webprog3.com,sametab
The native popups available in Javascript are extremely limited. They are almost untailorable, and they cannot be positioned. The worst is the confirmation widget, where the button texts are restricted to "OK" or "Cancel". This is often entirely inappropriate, since a lot of questions require a "Yes" or "No" answer, and NOTHING is being "cancelled"!
In contrast, the widgets you see on the left are 100% tailorable, and you can position them wherever you want. They were made in webProg3, which means that you can alter their appearance and size and change the texts according to your needs/taste.
If you want to download the Standard scripts for them, just click on the icons here on the left.
Demos of their usage follow immediately in the topics of this section.
Now we come to an important difference in the usage of these widgets in comparison to the native ones.
The native widgets have a characteristic known as "blocking". What that means is that when they are displayed, all further processing is halted until the operator presses a button such as "OK" or "Cancel". And when that happens, processing continues along the same thread, taking into account the answer that has been recieved from the operator.
However, if you use these custom widgets in the same way, it won't work. After displaying your widget, Javascript will blunder on like a maniac and not wait for your answer of "OK", "Cancel" or whatever! In other words, they are "non-blocking".
So how can you block these custom widgets so that they behave properly? Blocking can be achieved, I believe, using timers and/or other elements that come from the murky depths of Javascript. I wouldn't recommend their usage, since it involves a lot of extra work and complication.
Here's what you do. At the end of a handler, such as the mouseup/mousedown on a button widget, there is a brick wall. Nothing further is executed after the last statement in the handler. So after you have displayed your widget, that's it. Javascript cannot execute further instructions which do not exist! Just make sure that NO CODING is written after the widget call. Very easy.
Then, continue your coding using the handler(s) attached to the buttons on the widget. On the ALERT widget, there will be a single continuation thread because it has only one button. On the others, there will be (at least) two continuation threads, but in practice it's normally not a big deal.
