[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.
[00:00] If you need to run some logic when your clients starts up or when the gateway is starting, you can use Startup Scripts. The Client Event Scripts has a Startup Script as does the Gateway Event Scripts. And of course, they run at very different times. So the Client Event Scripts version of the Startup Scripts will run every time a client is launched. This logic is run right after the login. So, right after the user logs successfully the Client Startup Script will run. Oftentimes we'll see people using this to open-up a custom set of windows, if maybe the opening set of windows should be different based on who logged in. The only thing to be really aware of for the Client Startup Script is that if you are trying to do something like logging back out or re-targeting, you should do that and then invoke later. For example, you will define what you wanted to do. Let's say under certain circumstances I wanted to log the user immediately back out. Here, I'm going to use system.security.logout but you can see I've put this call in a function definitions that I can use system.detail.invokelater. The reason to do this is because the Startup Script is run during the Client Startup it's better for the system to logout after all that startup stuff is finished. That's what invoke later does is it runs a function after the current event processing is finished. The Gateway Startup Script, of course, runs on the gateway and will run for each part that you have defined but it is important to remember that even though this script will run when the gateway first starts up, it may also run at additional times. For example, if you alter any of your Gateway Scopes Scripting or your Project Script Library, this script will get run again. So that every time any of the scripting for your project that affects the gateway changes, your project essentially restarts in the gateway. So, shut down and startup will be called. The reason this is required is that you may have made changes to scripts that this script references, so the dependencies of change, so you need to run it all again. It's really a Project Startup Script in the Gateway Scope rather than just a Gateway Startup Script. You need to remember that when you are writing this that this may run multiple times in the lifespan of a gateway.
Vision Client Launcher Download
Select a LogMeIn Product. All Products LogMeIn Backup LogMeIn Central LogMeIn Hamachi LogMeIn Pro RemotelyAnywhere LogMeIn Rescue Rescue Lens. Select an Article Type. All Article Types FAQ Documentation Downloads Product Guide Release Note Video. The Client Event Scripts has a Startup Script as does the Gateway Event Scripts. And of course, they run at very different times. So the Client Event Scripts version of the Startup Scripts will run every time a client is launched. This logic is run right after the login. So, right after the user logs successfully the Client Startup Script will run.
