> For all you seasoned VB programmers this is going to be a no brainer.
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!
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