You can help by commenting or suggesting your edit directly into the transcript. We'll review any changes before posting them. All comments are completely anonymous. For any comments that need a reply, consider emailing email@example.com.
We are experiencing playback issues from our video hosting provider. Please check back shortly.
This lesson is part of the Scripting in Ignition course. You can browse the rest of the lessons below.
5:12Vision Event Scripts Overview
7:34Accessing Component Properties
4:30Component Extension Functions
3:29Component Custom Methods
Take topic challenge
Take topic challenge
When writing component event handlers, the event object gives your script a handle into the rest of the window.
Video recorded using: Ignition 7.7
Transcript(open in window)
[00:00] Whenever you use component event scripting, and you pick an event, the script that you write has a special variable that's available to it called the event object. Every different kind of event has an event object associated with it. And the event objects for different kinds of events contain different kinds of information. This panel down here, Event Object Properties, tells you what variables the event object will have on it. The event object always has a variable on it called source, which is the component itself. So for example in an action performed event on a button you can type in print event.source.text. So this grabs the source out of the event, which is the button itself, that's always what the source is, is the component itself that fired the event. And then once you have that you can pull any of the properties off of that button. So this will just, every time a button is clicked, it'll print out its own text. The types of information available in the event object varies by event type so for example, a keyTyped event is going to have a keyCode for the key that was typed, a keyChar for the key that was typed in case it was a character key, location codes to differentiate between the Left Control key and the Right Control key, things like that. The mouse events object will have things like what button was pushed on the mouse, and the x and y-coordinates of the mouse when it was pushed. Whether or not this event object should be considered a pop-up trigger for things like right-clicking, things like that. The event object for the propertyChange event is especially important because it contains not only the value that was changed but more importantly, the name of the property that was changed. This is a common mistake that we see beginners make. So for example, let's say that we had a numeric text field, and we wanted to run a script every time the value of this text field changed. So we're going to run this thing in integer mode, so it's intValue is the name of the property that we expect to change. But, oftentimes what we see beginner scripters do is they come in here and they say, "Okay, I want to write a propertyChange script "when my value changes." So here I am, I'm going to write my script, and let's just print a new value. Okay, so here I'm printing the new value for my text field, right? Well, the problem here, is that if you start running this in preview mode, you're going to start seeing all sorts of strange things coming into the console. And that's because, the propertyChange event itself gets fired for a lot of different properties, properties that really have nothing to do with the user space workings in Ignition. And so it's very important, whenever you're writing a propertyChanger script, to first check to see if it's the property you want to handle, and the way you do that is with an if. So you say if event.propertyName is equal to, in this case, intValue, then I want to print out the new value. So if you ever find yourself writing a propertyChange script without the first line looking something like this you know you're probably doing something wrong. And so now if I change the value we'll see the correct entries coming into the console without any unexpected strange things going on.