Conveting to event driven thinking

**Rick Rothstein** · Jul 17 '05, 07:45 PM

Re: Conveting to event driven thinking

> For all you seasoned VB programmers this is going to be a no brainer.[color=blue]
> However, as a C programmer learning VB I'm having trouble getting my
> arms around the event-driven nature of VB.
>
> Suppose I have a form with a single command button (cmdPush).
> The form's code (including the cmdPush_Click() sub is between the
> dashed lines.
>
> --------------------------------------------------------------------
>
> Option Explicit
> Dim i As Integer
>
> Private Sub Form_Load()
> i = 0
> End Sub
>
> Private Sub cmdPush_Click()
> i = i + 1
> End Sub
>
> --------------------------------------------------------------------
>
> After cmdPush is pushed 10 times I want the program to end. HOWEVER,
> I do not want the cmdPush_Click() to test the value of i or to end the
> program. I want that done somewhere else. The way I would do this in
> C doesn't work in VB because of the event-driven natue of VB!
>
> How do I do this in VB?
>
> Multiple different answers will be greatly appreciated![/color]

I have to ask... why do you think you don't want the cmdPush_Click event to
test or end the program? It's the most logical place. Now, of course, you
could create a Function or Sub to do the actual work, but that procedure
will have to be called from this particular event. There is nothing else
watching what you are doing. In an event driven world, your components do
things when the **user** interacts with them. If the user is not interacting
with a component, it just sits there idle. If the user is not interacting
with **any** components of your program, then your whole program is just
sitting there idle. Yes, you can (sort of) defeat this by activating Timers
or Subclassing and/or Hooking components, but basically (pun intended), the
above is true.

In a non-event driven program, you have to create a gigantic loop and
continually look for things to react to on your own. An event driven
program, in effect, is automatically in a gigantic loop and the system is
automatically checking your components for you. If something happens on one
of your components, the system informs your program (invisible to you) and
your program reacts by executing the code (if any) in that particular
control's activated event(s). For this "automation ", you have to give
something up... the ability to control the **linear** flow of your code.
Trust me, this is a good trade-off; but you have to get used to it.
Basically, you have to stop thinking of your program flowing in a linear
fashion with you deciding what is happening each step of the way (your
individual event code still moves that way, but within the overall structure
of an event driven paradigm); instead you have to design it to react no
matter what the user chooses to do. For example, when you wanted input from
the user at a certain stage of an old linear program, you simply stopped the
program and waited for the user to enter something. The user could do
nothing else (unless you gave him/her an ESC key exit or something). In an
event driven program, you place a control, say a TextBox, and you have an
event in the TextBox wait for the user to do something. But, at the same
time, you might have other controls for the user to interact with (other
TextBoxes for other information), CheckBoxes for option selection, ListBoxes
for a different form of option selection, etc. And the user can visit these
in any order he/she decides. Hence, you need to be able to know when the
user thinks they have finished. A CommandButton designated as, say, OK could
be used for that purpose.

I don't know if any of the above ramblings has helped you or not; hopefully
it did.

Rick - MVP

**Asperamanca** · Jul 17 '05, 07:46 PM

Re: Conveting to event driven thinking

>[color=blue]
> So, when it's the human's turn two button choices are enabled: "Roll"
> and "Pass." When Roll is pressed a pair of dice are rolled and the
> sum is compared to the mark. If this sum equals the mark then the
> human's turn is over and the computer takes its turn. If Pass is
> pressed then the human's turn is ended and the points accumulated
> during the round are added to his cumulative score.
>
> Therefore, the computer's turn may be "started" in two different ways.
> What I'm having trouble with is how to implement this turn-based
> sequence in a loop for, say, ten rounds.
>[/color]

Okay, so you'll have two buttons (Roll and Pass), someplace to show
the current score ect.

I suggest that you, essentially, write three Subs or Functions, one
called "PlayerTurn ", the second "PlayerRoll " and the third
"ComputerTu rn" or so.

PlayerTurn initializes the player's turn, and is called when you start
a new game. It does nothing much really, maybe tell the player it's
his turn, and enable the buttons (see later why).

PlayerRoll is called when the player presses the "Roll" button. It
determines the roll and shows the result.
1) If the player succeeds with his roll, the buttons stay as they are,
the player can again choose to roll or pass (or quit, never forget
that).
2) If the player fails, ComputerTurn is called.

If the player presses the "Pass" button, the score is updated and
ComputerTurn is called as well.

In ComputerTurn, the player buttons are disabled (Enabled=False) , and
the computer does his turn. Once that is resolved, the score is
updated, the turn count is increased, ect. and PlayerTurn is called
again.

A bit more elegant would be to write a Function called "ComputerRo ll",
and add a timer (say "ComputerTurnTi mer"). Now the function
"ComputerTu rn" does nothing but disable the buttons and activate the
timer.
Inside the timer, "ComputerRo ll" is called. The whole logic is inside
that function. If the computer wants to pass, or fails, the timer is
stopped and the buttons are enabled again.
If you set the timer right, the player can actually watch the computer
make his move.

Hope that gives you a few suggestions

Robert

Conveting to event driven thinking

Conveting to event driven thinking

Comment

Comment