[00:00] In this video, we'll take a look at the differences between client and gateway event scripts. We'll start off in the designer, and under the project section, there's a scripting section, and inside of there you'll see we have client event scripts as well as gateway event scripts. We're going to start by double clicking on client event scripts and you can see that there are several options available to us, we'll talk about these more in depth in later videos. But all you need to know for right now is that client event scripts are scripts that trigger based off of something that happens within the client. So for example, if I wanted something to run on a timer, so I could use a timer event script, so every five seconds I could do something on timer within the client. Now, it's important to understand that each running instance of the client will basically have another execution of this script or this event running. So if I had five clients open, I would have five executions of this timer script. One running in each client every five seconds. Additionally, if I closed all of the clients, the script wouldn't run anywhere. So actually, leads us to the gateway event script. So I'm going to open up the gateway event scripts. And these are very similar in concept to the client event scripts, except that they are scripts that run on the gateway itself. So using that same scenario, if I had a five second timer script defined on my gateway event scripts, I would have one single execution of that running at any given time, regardless of how many clients I had open or not. As long as the gateway's up, there will be one execution of that timer script. So you can see that this concept of a simple timer just running the script at some rate yields wildly different results based on the scope. Now I'm going to bring my client event scripts back up here. Now, if we compare the two, you'll notice that there are more events on the client event script side than there are on the gateway event script side. The reason for this is that some of the events on the client event side don't really make much sense on the gateway. So, for example, the keystroke and the menu bar, these are both constructs of the client. So it doesn't really make much sense for them to be running in the gateway. So that's why there's a difference between the number of available events within each scope. Now, another big difference is how print statements are handled. So let's say in my client event scripts I'll type print hello. So when the user logs into a client, we'll print this hello message here. Whatever we print here would be viewable from the clients console. However, if I take this same print statement, I'll copy it and paste it over to the gateway start up script here, this will appear in the wrapper log file that's located inside of the ignition installation directory. So if you wanted to see this print statement, you'd have to log into the server that ignition's installed on. In a lot of cases, this might not be an easy task, as you'll have to have direct access to the server. Instead, we recommend you use one of our system functions, and specifically system, dot, util, dot, get, logger. There's a logging function you can call, this returns a logging object that we can name. I'll call this gateway logger, we can then invoke it, and then pass it a message. So when you call this get logger system function here, you're actually injecting a message that will appear within the diagnostic logs on the gateway. This is typically a little bit easier to troubleshoot with since you only really need to have access to the gateway's web console. Since we're talking about system functions, it's important to remember the scope or where you're writing the script. Is this a client or a gateway event script? Some system functions are available in both the gateway as well as the client scope. My system util get logger here is actually a very good example of that. You can call the system function in a client event script as well as a gateway event script. However, if you take a look at the system gui, or GUI functions, confirm for example, shows a little confirmation message box the user can click on. This makes sense at the client scope but not so much at the gateway scope. So you can't call the GUI functions in the gateway scope. If you try, they'll throw an exception. Because of this, it's important you pay attention to the scope that the system functions you're using run at. If you're ever curious, you can check the user manual within the scripting appendix. Not only do we list the system functions, we describe the scope that they run in. The last thing I want to cover before we end the video here, is I want to take a look back at my designer here and I want to point out that these gateway event scripts, even though it says gateway here, this is, in fact, a resource of the project. So, for example, if I were to export this project, a copy of any gateway event scripts could potentially be in that export. Additionally, if I wanted to view gateway scripts and other projects on the same gateway, I would have to open those projects up in the designer. I can't view them from here. Lastly, if I duplicate this project, the duplicate will also have the exact same gateway event script. So I could have two scripts running simultaneously on the same triggers doing the same work. This could potentially cause a number of problems.