Swatting Away at the Nasty Kink Gnats
An inevitable part of the Long Learning Curve (that of Learning Python, HTML, CSS, etc.) is that of getting rid of annoying bugs even when those bugs are not the fatal kind. I'm talking about the small ones that keep annoying you and annoying you until you can't stand them anymore.
In my case it is a "feature" of Python to echo back onto the screen whatever key press the user activated. This curtesy echo messes up the display I have set up on the screen. No thank you. I don't want it in my case.
Another annoyance is that of repeat printing out to the user an instruction after having already once printed the same out. The user does not need to be told twice. How do we suppress the second telling of those instructions?
What are we looking at here? (Meaning, the above image).
BTW, as usual, you can left click on the above image to see a bigger, clearer version of it. Better yet, right click on it and have your browser open it in a new tab or new window.
So here's the nitty gritty about the code.
(1) The name of the function (defined on line 191) is Wait_for the C Key(). It tells us we are waiting for user to strike one of the allowed keys, which by default are the : C key, Space key and M key.
(2) display_id identifies the "next" frame as indicated at line 194.
(3) Lines 201-202 are the critical ones.
(3a) As posted earlier, for unknown reasons, invoking the keyboard.read_... method twice somehow prevents the program from thinking the C key has been hit twice, causing a skip forward past the next frame.
(3b) I succumbed to vibing to learn that (suppress = True) is what blocks the echoing of the pressed key onto the console (typically in green color)
(3c) Skipping backwards to line, 195, when the first instruction (the outp_01x string) was printed out, we also sent out some escape codes. \033[A is supposed to do a feed up of the carriage. The \r escape code returns the cursor to the beginning of the line. This prevents a printout one line lower of the instruction to the user.
(3d) In the same print() execution we set the separator to null and the ending to not being an automatic new line (\n).
(1) The name of the function (defined on line 191) is Wait_for the C Key(). It tells us we are waiting for user to strike one of the allowed keys, which by default are the : C key, Space key and M key.
(2) display_id identifies the "next" frame as indicated at line 194.
(3) Lines 201-202 are the critical ones.
(3a) As posted earlier, for unknown reasons, invoking the keyboard.read_... method twice somehow prevents the program from thinking the C key has been hit twice, causing a skip forward past the next frame.
(3b) I succumbed to vibing to learn that (suppress = True) is what blocks the echoing of the pressed key onto the console (typically in green color)
(3c) Skipping backwards to line, 195, when the first instruction (the outp_01x string) was printed out, we also sent out some escape codes. \033[A is supposed to do a feed up of the carriage. The \r escape code returns the cursor to the beginning of the line. This prevents a printout one line lower of the instruction to the user.
(3d) In the same print() execution we set the separator to null and the ending to not being an automatic new line (\n).

Comments
Post a Comment