Here, you'll find text file documents containing cut 'n paste copies of the code we've developed in class, with
additional comments and notes added to help provide context, or further explain something we did. This is as close
to a substitute for attending lectures as you can get.
Here is the
Form1.cs and
Form1_Designer.cs
files from the more or less completed Solar System Simulation project.
Here is the
Form1.cs and
Form1_Designer.cs files
from the UI/UX lecture on 4/5, covering things like MenuStripItems and Focus events. Here is the
Form1.cs and
Form1_Designer.cs files from the Solar System Simulation project.
As we saw at the end of lecture, the class implementation of component allocation created a non-start situation, which
I am hoping to get corrected before we return to this on Tuesday and finish it up.
Update: I initially thought the problem was passing "this" Form to the PlanetaryDisplay class, leading
to a copy of it being created and passed to another object of the class, on and on forever. So use the "ref" keyword and
I'll be golden? Nope — I made the classic mistake of declaring reference type attributes (like
Label) and
not setting them to a new instance of that type! Sort of frustrating that
it didn't simply crash the problem instead of stalling, which lead me to initially theorize the recursive scenario.
Here is the
Form1.cs and
Form1_Designer.cs
v0.2 files from the Get Rhythm project in class. As we saw towards the end of lecture, there is currently some work
that needs to be done in order for the Hold : Note implementation to be complete but (1) I'm already very satisified
with the progress we've been able to make so far and (2) I have a couple of other projects/lecture topics we need to
cover before the end of the semester.
Here is the
Form1.cs and
Form1_Designer.cs files from
the Get Rhythm project in class.
Here is the
Form1.cs and
Form1_Designer.cs files from
the Reflexes project in class.
Here is the final version of our Tic-Tac-Toe project, including Resize functionality, two simple KeyBoardEvents, and
win-check functionality:
Form1.cs and
Form1_Designer.cs.
I realized as I was typing this up though that we never implemented a check for instances of a draw! Which should
realistically be common enough if I wasn't forcing a victory to check code. To implement this, I would likely include a
Boolean variable to keep track of whether a victory state was achieved. Then at the end of the win-checks, include one
final nested-loop that examines if all of the available cells are non-space characters. If we don't have space characters
(i.e. they're all occupied with X's and O's)
and a victory hasn't been achieved in the previous win-checks,
then announce a draw and clear the grid.
Another thought comes from how we could probably abort checking for wins if we've discovered one early on, so perhaps
a return statement after win-announcement to reduce redundant code instruction. This could also lead into the draw-examination
code, since we could only get that far down
if no one had achieved victory. Then we'd only need to check if the
grid was fully occupied.
Here is the
Form1.cs and
Form1_Designer.cs files from our Intro to MouseEvents and Graphics project, as well as v0.1 of the Tic-Tac-Toe
project that we began:
Form1.cs and
Form1_Designer.cs.
Here is the
Form1.cs and
Form1_Designer.cs files
from our Midterm Study Guide project. Additionally, there are
Green Check Mark and
Red X Mark image files that I've configured the Designer.cs file to use for the Right/Wrong
buttons. There's also a
Cards file populated with Q/A combinations, delimited with a simple # symbol.
To include these files, place both image files into the same directory as the executable for your re-created project.
As was discovered after class, the ReadOnly == true property of the Score_TextBox component was what was prohibiting the
modified ForeColor from being utilized, which I found to be personally annoying. And as another student pointed out, the
Boolean variable used to control transitions from Q to A was initially being skipped on the first click with the way the
true/false values were being used relative to the if-statement in "Response_Button". Both of these issues have been
resolved in the uploaded files.
And finally: I modified te Form1.cs and Form1_Designer.cs file without checking it against the compiler, so feel free to
call me out if it has compilation issues. The two modifications were (1) setting the Image property of the two Buttons and
(2) writing a loop that reads an input file of Flash Cards.
Here is the
Form1.cs and
Form1.Designer.cs files
from today's lecture, demonstrating some basics in LINQ usage.
The "complete" Dark Calculator app's
Form1.cs and
Form1_Designer.cs files.
We could continue adding functionality up to and including real number formatting but I think it would be more useful
to pivot into one of the other projects I want us to complete this semester instead.
The in-progress Dark Calculator app's
Form1.cs file and
Form1_Designer.cs files. I can't yet upload simple .zip files of the entire project but you can re-create them
by simply cut 'n pasting into the Form1.cs and Form1_Designer.cs files. Additionally, as a student pointed out after
lecture, the issue with the while loop that soft-locked VS in lecture was the fact that OutputText.Text wasn't being
updated after the comma was removed -- it was just infinitely being removed. The solution (as included in this upload)
was simply to re-assign to Text the new string content, which will include one less comma then before.
Extended the classes demo to include IComparable implementation
CompareTo,
along with the notes I wrote in
Notepad that day.
Basic classes demo from
1/25's lecture, as well as Notepad notes used
from that same day.
