Hi Jim,
No, there is no need for a loop to check the state of a button. This is
where Windows events come into play. If you declare a button clicked
event in your application for a specific buttonyour application will
perform the correct action when it recieves an event notification from
Windows. Since you may or may not be aware of how Windows events works
here is a brief explanation of what they are.
Basically, Windows is what we call an event driven operating system.
What that means in normal language is that everything you do on your
computer such as using your keyboard, moving or clicking the mouse, etc
sends a message to Windows to perform some sort of action we call an
event. This message is then handled by Windows and then is passed on to
the application where the event was first recieved. The application will
recieve the event notification and perform whatever task was requested.
So if you pointed your mouse at an Ok button in application x and
pressed the left mouse button Windows would first trigger a left button
clicked event at position x and y. It would then compare that
information with the active window or application, and pass the message
on through the message pump to the active application. The active
application for its part would compare the clicked event with a list of
possible defined eventsin the application, and perform the one that
matches the event notification. That's an over simplification, but I
think enough to explain a bit how events work in general.
Anyway, I'm beginning to see why object oriented programming confuses
you. Most students, VB 6 or otherwise, usually get their first glimce at
object oriented programming by day 1 or day 2. I can remember my first
VB 6 program was a simple dialog with a text label that said "Hello
World!" and a Close button. After we created that program the prof then
had us open up the code editor where he explained how the code worked
line by line. That way as we programmed we were getting new terminology
as well as code examples in a logical progression. At that point we
didn't need to know what an object was as long as we could identify that
buttons and text labels were indeed objects, and tell them apart from
regular variables. After we mastered how to program a certain thing we
were then given a more in depth technical explanation of how and why it
worked with all the terminology for what we were looking at. In other
words we learned object oriented programming in a logical step by step
manner building idea upon idea, concept upon concept, principle upon
principle until it all became clear to us.
As you yourself have said you are self-taught by looking at code
examples on the web and elsewhere. That to me is like trying to look
through a telescope from the wrong end. What you got is the big picture
without actually learning all the little bits and pieces that make up
that big picture, and as a result you have assembled the pieces you
understood together the best you could. Unfortunately, object oriented
programming isn't something you can look at from the big picture point
of view and understand it fully. You really do need the step by step,
build idea upon idea, principle upon principle, type of training to
fully master the technique. You need to know each little step or
component in the process so that when you fully assemble them you get
that big picture.
I'm not saying any of your games are bad. I'm amazed how well Monopoly,
Football, and your other games run from someone who taught himself to
program. However, I figure there probably were easier and more practical
ways to create those games you didn't know about or missed simply
because you weren't aware of other design alternatives. I made plenty
of mistakes myself in the early days.
Not too long ago I found some text games I wrote in the early to mid
90's in C++. Back then I wasn't real familiar with object oriented
programming design concepts so I did it the hard way. I created
variables for every player, character, everything in the game even
though I didn't need to. Once I learned about classes and objects I
realized I could have created one class to store all of the
functions/variables, and been done with it. Instead of hundreds of
variables I may have only had 10 or 15 which could be cloned simply by
adding a new object to the game. This is why I'm in favor of an object
oriented design. It ultimately is a better design strategy once you
understand it fully.
Smile.
Jim Kitchen wrote:
Hi Thomas,
Actually, no, I have never made a button or even ever used the VB 6
toolbox. I have seen that button example and it just confused me.
Some of my programs do have the ok, cancel type buttons but they came
from me using the InputBox or MSGBox. You know like
g$ = InputBox(" Enter Last Name ", "")
But thank you very much for the button example. If I could see more
clear examples where it defines and uses such things, maybe I would
catch on. You know your example defined the button and then gave it
the text, now I imagine that you would put your program in a loop
until some variable of the button1 changed right?
TGIF and BFN
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
