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.


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?


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
All messages are archived and can be searched and read at
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.

Reply via email to