Thank you for joining me for this video, Debugging. For Servoy University, I'm Bob Cusick. In this video, we're going to take a look at how to debug your methods. You will spend a lot of time writing your methods and getting them just right, but you'll spend almost an equal amount of time debugging them, because inevitably, they'll make some typo or something will go wrong someplace in your logic. The debug is just another perspective, so right now we're looking at the servoy design perspective, and if you don't already have a debug perspective open, you can use Open Perspective, choose Other, and choose the debug perspective. Click OK. This will open up a new perspective. Now notice that my script, my customers JS script, is still open in this debug perspective. I can go ahead and edit this script. I can make changes to it. I can make new scripts. Everything that I can do in the design perspective, I can also do here in the debug perspective. We'll get back to the debug perspective in just a minute. Let's switch back to our design perspective for just a moment. Now what I've done is I've set up a very simple customer's form that has a single button on it called Find, and this Find button will run this method here. It's called Button Perform. It says if the button's text has the word Find on it, tell the controller to do a Find, set the city equals London, and then perform the search. And then change the button text to show all. The else condition says, hey, just load all the records and change the button text to Find. Let's see how the example works. Here I'm looking at all 91 records in the customer's table. The button says Find. So I click it. And now there's only six records in the found set. Only those where the city equals London. And the button has changed its name to show all. Now when I click it again, I'm looking at all 91 records again. And if I click it again, the found says limited to those six records. Very simple script. Now let's close the client and come back to our method for just a minute. And let me show you ways that you can trigger the debugger. The first way is to use a breakpoint. To insert a breakpoint, simply come over to this left hand side of the line number and double click. And there'll be a little dot that appears there. So let's see what happens now when we run it in the client. When I click the find button, the debugger will stop here at the find, but it will keep the client forward. We can switch the debug perspective. And now you'll see that we have access to a whole lot of other things that are going on. We have access to which thread is running. We also have access to variables. So here we can see global variables. We can see what the value of the data in the current address field is in the city field, all of those kinds of things. So there's a lot of variables that are going on. We can go ahead and even expand these so we can take a look at the found set object. So the found set has 11 fields as data providers. There are 91 max records. And it will even show you all of the data for all of the records. So if I expand this one, record zero is all of this data in every column. We'll show me the data in every column. Record two has this data in it. And so on and so forth. Because it's paused at our breakpoint, we can now inspect all kinds of variables at this point in time. So to go through with our method, we can either step into step over or step return out of this running script. So we're going to say step into which will just do one step at a time. And as it goes one step at a time, you can then also have a look at how your variables change, how your data changes. So as it keeps going through, it's going to do show all and it's going to click and it's going to finish that method. And if I click it again, it's going to break. And in the debugger, it shows me the columns or variables or things that have changed since the last time the script is executed in yellow. So it will highlight it for you to say, hey, look, these have different values than the last time you ran it. To just go ahead and run your method, just click the play button. And it will just go to the next breakpoint. Because we only have one breakpoint in here, it just continues to run the method. Let's add a second one in here and see how that works. So here I click find. It stops on the first breakpoint. I'm going to hit play. It will jump to the second breakpoint. And then as I hit play, it will finish running the method. There are other things that you can set on a breakpoint. So if you come to a breakpoint and you right click on a breakpoint, you can toggle it, which means turning it on or off. You can temporarily disable the breakpoint. So you can keep it there, but it's not active. Also on the breakpoint, you can come down here to breakpoint properties. On the breakpoint properties, you can disable it. You can also do really cool things like break only when the hit count is greater than or equal to number of hits, equal to a number of hits or a multiple of number of hits. This is really handy when you're going through a long loop and maybe the first 15 of them work perfectly, but on number 16, it's really, you know, going wrong. So you can trigger a breakpoint when the hit count gets to 16 hits and it will break only at that point that you're interested in. So you don't have to step through manually 15 iterations of your whole method to get to the 16th one. So that's pretty cool. You can also break it on a condition. So you can break it on data so you can say city equals London, for example, or you can break it when you have another variable set to a value. So x equals 12 or anything that you want, any valid kind of JavaScript calculation you can put in here. And that's when the breakpoint will trigger. You can also see a list of your breakpoints using the breakpoints tab and the checkbox indicates whether it's active or not and how many hits have been done or how many times the debugger is run and hit that particular breakpoint disabling or enabling here is the same thing as right clicking on the actual line. So besides setting your own breakpoints manually, the debugger will also kick in when you do something like a typo. So for example, I'm going to go ahead and change find to fin. So that's an incorrect command. I'm going to save this with control s. And now when we go ahead and we run it in client, what's going to happen is there's going to be a syntactical error. So sure enough, in the client, Sir, what tells me, hey, look, there's a problem. If you watched the other video error handling, then you'll know that there are different ways you can handle errors. But in the debug client, it's really handy because it tells you that something went wrong and where it went wrong. Also if you notice down here in the debug perspective, there's the console. The console will tell you where something has gone wrong and it will give you a hyperlink so that if you click it, it will highlight the line in your method that has the problem. So here I can fix my error, save my method. Again, I can use control s or here and everything is fine again. There are a couple of other options that are really cool. So over here in the breakpoints tab, there are three icons here. And when is global exit break, global entry break and global exception break? So let's turn on entry break. Now what will happen here is as soon as you enter any method, when any method runs, it'll pop into the debugger. So let's go ahead and do that. So I click on find, notice it pops for me directly into the debugger, even though I don't have a breakpoint set. Now where would this be handy? Remember when we talked about working with forums, how you can set methods on the on show, on load, on hide. There's all kinds of events where you can set the method to. Well, one of these methods could be going haywire. And when you have this global entry break on, you can literally step through everything that happens whenever code is executed. So it comes in handy for finding those times when you just can't figure out what the heck is going on. You can use this global entry break. And likewise, you have a global exit break. So let's see how that works. I'm going to click find. And when it's done, it goes to the last step before it's going to leave this particular method. So that's the exit break. And finally, the exception break. So the exception break works the same way as when Sir Voethrows an error. So if we clear our console here and we take our fin example and save it and we run it, because there is going to be an exception of that line before Sir Voethrow even knows that there's an error before it gets reported to Sir Voethrow. The debugger knows that there's an error on this line. So you can either go ahead and continue. If you continue, then the normal Sir Voethrow error and the console error will be thrown. And if you look at it in the client here, you'll see that there is a error thrown. But the setting in the debugger here will catch it before it actually throws the error. Now when you're in a method and you're paused in the debugger, let's just set a break point here. Good or client and run it. So now we're in a pause data. I showed you how you could see variables and I showed you how you could see break points. And you can also do expressions and there's an interactive console. So this is pretty cool. So the interactive console allows you to do anything that you want at runtime when this thing is running. So for example, if you had a loop and if you said x equals one to a thousand and it's going to loop through this is going to increment x every time it goes through the loop, you could say simply x equals 999. Or if your method has a variable, you can reassign the variable live while the method is running so that you can try different things. You can also get and set data. Setting data can be a little tricky. So just be really, really careful here. You could say city and it will return the value in the current rows city field. Now you could also see that in the variables tab. You can also do things like say elements, button find, text. So you can see what the property of an object is on your form. So anything that you want to find out you can use this interactive console and it comes in really, really handy when you're trying to figure out what you've set where or what the state of other variables are or what the state of objects are, what the state of data is. It's something that you're going to use quite a bit. Let's go ahead and continue this script. And let me show you one more thing that's really cool with the debug perspective. And in particular, the console. There is a, I'm going to come back here to the design perspective so you can see the tree. In the applications node, there is a function called output. And this output will show stuff in the console. So rather than setting a bunch of breakpoints every place and having your method stop all over the place, sometimes you just want to output to the console what's happening at certain things. So what we're going to do is we're going to double click output. So there's two parameters, message and logging level. Message is required and logging level is optional. Logging level is a constant and that can be error. That can be one of these application constants. If we expand it and we come down to constants and we take a look at logging level, you can log it as debug, error, fatal info or warning and it will show up in the servoy server log as one of those severities or you can choose to not include it and not write it out to the log at all. So here we're going to output a message that says this is a find and we're going to copy this control C, come down over here, control V. This is a, and we're going to say this is a show all. Let's save our method and now when we come into the client, we can also show the console here. I just have mine hitting. So here's the console showing in the design perspective. I don't have any breakpoint set. Let's fix this piece of code, take it back to find. And when we run it, what's going to happen is here, down here in the console, because we were in find this application output, put this is a find. Now when we click show all, it puts this as a show all. So you can write messages, you can include anything that you want in these messages. They don't have to be a text string. They can be the number of records in a found set. They can be the state of objects. Anything that you want, you can put here. It's helpful to track down where you have something weird running. Just put an application output there and you can see the path of what's going on. Finally, in the debug perspective, you can rearrange all of these tabs, however you like. So for example, this variables tab, I want to be bigger. So you can simply take this variables tab and the outline will tell you where it's going to go and how it's going to be shown. I want to take this outline. I want to put it into this same section and I want to put my break points over here as well. So you can rearrange this, however makes sense for you. Give yourself the most amount of space. And if you ever get into something that's totally messed up, you can always right click on the perspective and say reset. Your voice debugger is extremely powerful and it allows you to get a handle on your code and hopefully make less errors. Thanks for watching.