Using the Stop Keyword

Quick reference

• 00:05 There's one more technique, that I want to show for
• 00:07 debugging that I think is important that you know.
• 00:10 Because one of things that could potentially happen to you is that
• 00:13 you're going to end up developing a Mac or you're going to send it to somebody else
• 00:17 in your organization and they're gonna work with it for awhile.
• 00:20 And it's gonna be four, five, six months before suddenly somebody hits a bug and
• 00:25 they can reproduce it.
• 00:26 And they send it back to you, and unfortunately it's in a massive project.
• 00:30 It's huge.
• 00:31 So you start working your way through things and
• 00:33 you're working on a debugging copy.
• 00:35 And well, the day runs out,
• 00:38 you go home because you want to spend time with your family and what not.
• 00:40 And this is part of the real life of what ends up happening in the development world
• 00:44 with these things.
• 00:45 So what I want to show you is a way that we can actually stop certain things or
• 00:50 a way that we can actually leave a trace so
• 00:52 that we can actually keep our debugging going.
• 00:54 Now, if I go and
• 00:55 take a look at the routine that we have in this particular case, remember,
• 00:59 we set this guy up so its got something that sets these particular things.
• 01:02 But I want you to pretend that this is like 800 long lines of code and
• 01:06 you've identified that there is an issue or
• 01:09 at least your testing this specific piece right here.
• 01:13 You say, there's something that's just not right about this.
• 01:15 I'm not happy about the way this is working,
• 01:17 this guy here looks like it's all going okay.
• 01:19 But there's something that's going wrong in here.
• 01:22 The challenge that we have in this ares is that when we go back and
• 01:26 we say, you know what?
• 01:26 I'm gonna save this file, and I'm going to minimize this, and I'm gonna close it.
• 01:33 And, of course, then I'm gonna go back and I'm going to reopen it.
• 01:38 And remember what happens when we do that, switch out back in all of our break points
• 01:42 have been cleared, but you were actively trying to figure out Where this is.
• 01:45 Remember, this is 800 lines of code.
• 01:47 And you come back on a Monday morning and after having to actually,
• 01:49 let's say Tuesday, after having a great, long weekend,
• 01:51 you've forgotten all about what was going on in here.
• 01:53 So there's a nice, little area or nice word that we can actually use that
• 01:57 actually replicates a breakpoint, but it saves between changes.
• 02:00 And that word is stop.
• 02:02 So what you'll see here is that if I go and
• 02:04 actually put this in place, When I go back and run my code.
• 02:10 Say roll forward.
• 02:13 You'll notice that the code stops and
• 02:14 it launches me directly into the Visual Basic editor at this point.
• 02:18 I can then go through and I can work with all the tools that I have from the watches
• 02:21 window and the locals immediate window.
• 02:22 And I can actually work through on my code and what not and run everything out and
• 02:26 see if I'm happy with the way it's all working.
• 02:29 Everything looks good.
• 02:30 Okay, cool.
• 02:31 Or maybe I'm going to make some changes for whatever reason.
• 02:33 But as long as this keyword is here, when I go back and try to rerun this macro,
• 02:38 it will stop just as if it's a break point.
• 02:40 The big difference between this and a break point though his when I do this.
• 02:45 Let's go file save as I'm going to call this one here we're going to call
• 02:51 this one stop and I'm just going to call this one stop complete because
• 02:56 I know that it's actually in here file closed and will reopen it again.
• 03:01 Here we go.
• 03:02 And now, when I hit my road full button it launches me directly and
• 03:06 so this is a break point that sticks around.
• 03:10 Where this becomes very very useful is not yet because I haven't told
• 03:14 you all of the decoding constructs that you might need to use in your work.
• 03:17 But if you have a branch something that could happen based on an if statement for
• 03:22 example You could have one branch that tests and everything works fine.
• 03:26 But could have another that says if you encounter this particular scenario, stop.
• 03:31 And that way if a user hits that particular piece, boom.
• 03:33 It's actually gonna hit that.
• 03:34 It's gonna trigger right into this particular area.
• 03:36 This is a way you can leave yourself some spots in your code that
• 03:40 you can actually break and stop when you need to
• 03:43 without having to remember it between long sessions and whatnot.
• 03:46 The other thing that I'll tell you that's useful when you're actually working with
• 03:50 these things.
• 03:50 Because we're in here and we have a little bit of time to work with this,
• 03:53 leave yourself some notes around this.
• 03:55 This is where you actually go in and you say, debugging at this point.
• 04:00 Not sure what is happening below, right, something along those lines.
• 04:05 And this is actually a good point, because you can actually use code
• 04:07 comments throughout your code as you work with these things.
• 04:10 We can actually put something in here that says setting the variables.
• 04:15 You can put something in here that says rolling schedule forward.
• 04:22 Something that leaves yourself a little bit of work.
• 04:25 This guy is supposed to be advancing the date and
• 04:30 then this one is return the user to home cell.
• 04:35 So it gives us something now as we're going through this that we can read and
• 04:39 we know that at this piece we've left ourselves a note.
• 04:42 Of course, when we're done with it we should probably clean out the note,
• 04:45 get rid of this particular piece as well but at least, it gives us something so
• 04:49 when we come back in on Tuesday morning.
• 04:50 We have an idea of what we were actually tracking.

Lesson notes are only available for subscribers.