The 9.7.4 Leash CodeHS Answers exercise isn’t about typing a lot of code. It’s mainly testing whether you understand mouse events and how to update objects on the canvas the right way. In simple words: you create a “leash” (a line) and a “pet/ball” (a circle or small object), and both should follow your mouse smoothly.
If you get this concept once, a bunch of later CodeHS graphics projects become easy—because many of them are “create objects once, then update them on events.”
The expected output (what you should see)
When your program runs, you should see a line starting from a fixed point (usually the center of the canvas) and extending to wherever your mouse is. At the endpoint of that line, you should also see a circle (or another small shape) that moves with the mouse.
The important detail: the leash’s start point stays fixed, but the endpoint follows the mouse.
The core idea: create once, update forever
Most students break this program because they treat mouse movement like a “draw everything again from scratch” situation. That’s not how these CodeHS graphics tasks are meant to be done.
The clean approach is:
- Create the line one time
- Create the ball one time
- Add both to the canvas one time
- On every mouse move event, only update positions
That’s it. If you follow that pattern, you avoid flickering, disappearing shapes, and lag.
Here’s a mental rule that helps:
If you’re calling
add()inside your mouse handler, you’re probably doing too much.
Step-by-step logic (the correct sequence)
Before you code, hold this sequence in your mind:
- Decide your anchor point (usually center:
width/2,height/2) - Build a line whose start is that anchor point
- Build a circle that will sit on the line endpoint
- Register a single mouse move handler
- Inside the handler, set:
- the line endpoint to mouse coordinates
- the ball position to mouse coordinates
That’s the full logic behind most 9.7.4 Leash CodeHS Answers write-ups. The difference between “it works” and “it doesn’t” is usually small mistakes.
A clean code structure (recommended)
Even if your code works, messy structure makes debugging painful. Try this layout:
- Global constants (radius, line width, etc.)
- Global variables (your line and ball references)
start()function:- create objects
- add objects
- register the event handler
- One function for mouse movement:
- update endpoint and ball
This structure isn’t just “style”—it prevents you from accidentally recreating objects repeatedly.
The most common mistakes (and the quick fixes)
Mistake 1: Recreating shapes on every mouse move
If you do this, your program may lag or visually glitch. Some people try to “remove old shapes” and “add new ones” every time the mouse moves. That’s unnecessary and error-prone.
Fix: Create once. Update only.
Mistake 2: Calling mouseMoveMethod() more than once
This can cause unpredictable behavior because you may be registering multiple handlers or confusing the runtime.
Fix: Register one mouse move method in start().
Mistake 3: Confusing “center” with “mouse”
Sometimes the line starts moving incorrectly because students set both endpoints to the mouse. That makes the “leash” look like it’s not anchored.
Fix: Your line’s start should be constant (center), and only the endpoint should change.
Mistake 4: Naming conflicts
This one is sneaky. If you name a variable and a function the same thing (like line), you can overwrite your object reference.
Fix: Use clear names like:
leashLinepetBallupdateLeash
How to debug fast when it “doesn’t move”
If your leash isn’t updating, don’t panic. Debug like a pro:
First, confirm the handler runs:
- Add a simple print/log inside the mouse move function (whatever your environment supports).
If you see output when you move the mouse, the event is working.
Then check your updates:
- Are you calling the right method to set the line endpoint?
- Are you setting the ball position from the event’s
xandy?
Also check the order:
- If you never added the objects to the canvas, updates won’t show.
- If you accidentally created objects inside the handler, the ones you’re updating might not be the ones on screen.
Make it look “better” (optional upgrades that still stay simple)
Once your basic program works, you can improve it in ways that still fit the assignment’s spirit.
Here are a few safe upgrades:
- Thicker leash so it’s visible
- Different ball size so it’s easy to track
- Change color when the leash gets long
Now a quick note before the next bullets: don’t add fancy features until the basic movement is perfect. Otherwise you’ll be debugging two problems at the same time.
- Add a “max leash length” so the ball doesn’t go too far
- Add smoothing (a tiny lag) so the ball follows like it’s attached by a real rope
- Keep the ball inside canvas boundaries (so it doesn’t disappear off-screen)
If you’re aiming for top marks, these upgrades can make your submission stand out—just keep them clean and readable.
What to write in comments (teachers love this)
A lot of students skip comments, but a couple of simple lines can make your work look more professional.
Good comment examples:
- “Create shapes once in start()”
- “Update leash endpoint on mouse move”
- “Ball position equals leash endpoint”
That shows you actually understand the event-driven model, which is the real goal of 9.7.4 Leash CodeHS Answers.
Quick checklist before you submit
Use this checklist right before you hit submit:
- The line’s start point stays fixed (usually center)
- The line endpoint follows the mouse
- The ball stays exactly at the endpoint
- You created objects once (not inside the handler)
- You only registered one mouse move handler
- No weird flickering, duplicates, or lag spikes
- Variable names are clear and not conflicting
If all those are true, your program is correct—even if your colors or sizes are different.
Final note on “answers” (what you should aim for)
When people search 9.7.4 Leash CodeHS Answers, they usually want a paste-ready solution. But the fastest way to actually succeed in CodeHS long-term is to learn the pattern behind it:

