A user interacts with the application by scrolling lists, clicking active form elements, typing and then form fields, etc. Some user action trigger events that run our source code. There are cases when my code wants to talk to a user and give him some information or ask a question, like in this case, for example, when there are not enough products left. Let's see how we can communicate with the user from the source code. Here is an example for us working with the companies catalog. I noticed that I could click "refresh the map'' but no physical address is specified, in which case my current location is shown. Let's tell the user that they forgot to specify the address and then cancel the refresh procedure. Before we refreshing the map, we need to make sure these attribute is not empty. The attribute has the string type, so I'm going here and here is the function I need. Okay, let's open the refreshes clicked event handler and drop the function right here. This is my condition and here is the simplest way on forming the user. Now I'm just exit in the event handler without refreshing the map and this is what the message looks like. It just pops up at the bottom of the current form like this. Let's see what else we have got in the message and department. Wow, looks like we have the entire [inaudible] here. This is the message procedure we just used and this is the guy I want us to try next. Okay, let's replace message with the DoMessageBox and this is what we've got. Now, the message is in its own small form and a user cannot click anywhere on the screen but at this "OKAY" button. Looks and works good, but there is a catch. This small window is a modal one. It means that the entire replication is now stopped and waiting for a user to click this "OKAY" button. This is how our ancestors are, the ancient programmers used to make sure that the user has read the message or answered the question. Back then all applications were single-threaded and stopping the entire replication loss is the most natural and straight forward way of getting answers from a user. These times are long gone, and now the single threaded applications are rare artifacts like punched carrots or floppy disks. Now everything is multi-threaded. A lot of things that are going on in the background, so we cannot afford just stopping everything and waiting for a user to click "OKAY". I was able to make it work for the desktop client by changing this setting from its default value, but too now it won't work for all declines in the platform supports. If I try the same in the web client, this is what I get because my Chrome, like almost every modern browser, does not support modal windows anymore. What do we do instead? This is what. As you can see, there are pairs of methods with similar names except for the prefixes, the "do" methods, open modal windows, while the show methods do the same but without modality. This is what the difference looks like at the runtime. This is the modal do version of the message box. I'm setting a breakpoint here, we're running the application, clicking "refresh the map" and we are at the breakpoint. Let's execute this line and here is what happened. My source code execution has been completely stalled. It does nothing but waits for the user's input in this modal window and only after the user clicks "OKAY", the application moves to the next line of my code. Okay, let's try the non-model version of the message box. This method has an optional first parameter I don't need, so I'm adding a comma here. Okay, running the app, clicking "refresh the map" and we are at the breakpoint again, executing the line and the applications just continuing to work as if nothing happened. At the same time, a user still cannot click anywhere button this "OKAY'' button, so from their perspective, nothing has changed, except now it works everywhere, including older browsers but from the developers' perspective, the difference is huge, especially when you need to fork the execution depending on the user's answer to some question, which we ask using "DoQueryBox", or "ShowQueryBox" methods. Here is another example for us. Check out this new copy of functionality I've just implemented behind the scene. These are my cashiers and this is the cashier form that now knows how to combine a first and a last name to get the full name automatically, just like this. It works without bothering the user until they change the full name manually. After results, the form cannot afford to silently replace the user's version with an automatically generated one. It does this, it asks user's permission to replace the full name and if the permission is granted, it proceeds and regenerates the full name like this. Let me show you how it's implemented. This is the cashier's catalog item form. I use the description attribute to store the cashier's full name. I also added this "FullNameisChanged" boolean flag that turns on whenever a user it changes the description value manually. When the first or the last name is changed, this procedure is called. It checks the flag and if it's on, ask a user for the permission to change the full name. The second parameter here can be a value of this system enumeration containing the most commonly-used buttons combinations or any other set of buttons you manually pick yourself. Of course, this "DoQueryBox" opens a modal window. It works like this, I'm raising the flag by changing the full name or their name change in the last name and we are at the breakpoint. Execution this "DoQueryBox" guy and the application is completely stalled. Nothing's going on until user answers to the question. The user says "yes" and we are back in business. The code is running, so now we can process the answer and do what we need to do. You see the problem here, I cannot afford using "Do" because of its modality. But I also cannot just replace it with a "ShowQueryBox" because the code one stop executing at this line. It'll move on to the next line, long before a user can see a lateral and answer the question. How on earth am I supposed to catch and process the user's answer without the modality. This is how, I'm right-clicking to the "DoQuery" message call, selecting "refactor" "legacy calls" and "convert call." Let's agree to the default name of whatever the platform asks us to name and what just happened. Let's see. Changing the full name, changing the last name, we are at the breakpoint and the question is asked and the application just moves on minding its own business until everything is executed. Meanwhile, a user takes his time, makes his mind and clicks "Yes" here and all of a sudden we're back in designer inside of this "FillFullName" and procedure the platform created for us. But how did we get here? This is how, the first parameter of the "ShowQueryBox" procedure defines what method to call and where to call it from after a user answers the question asked, so this is how we get here. Now we can check the user's answer and fill out the cashier's full name if the answer is yes. This is how we talk to a user from the source code.
