I am working on a visual basic project that another group is also working on. At one time we had had identical copies of the same project. They have added some additional functionality and so have I.

Now has come the time for me to merge our codes together. I am concerned with some of the functions they have added to the frm file and I wonder if it is possible to just copy a function from one file into another without generating the function from the development environment.

On the other hand, is there something special just in the name of the function that makes it possible that it will be called whenever a text field is changed or clicked on?

How all this is handled in Visual Basic does not seem as clear as how it works in C++.

I have merged some code you have given with the code I have written.



I am wondering about some functions that are generated by the development environment and how we can expect the same files will be accessed at run-time if hey are not generated by the development environment in a merged project. In other words, if a function like this:



Private Sub txtModeTrigLevel_Change()

    TextChange Val(txtModeTrigLevel.Text), TRIG_LEV

End Sub



Is copied over from one FRM file to another FRM file in another project just by simply copying the ascii text, will this function be called at runtime as the first project operates? If so, how is this possible? There are a lot of functions like this in the Function Generator SFP that are accessed at runtime whenever a text field changes. But Visual Basic is not like C++ where we can see how the user interface handles calls to a variety of functions. In Visual Basic, the mechanics of this is handled by code that is not ascii files and is hidden from the developer.

The names of routines ending in _Click(), _Change(), _<etc>() preceded by the name of a control or other object are usually cast in stone.

You can see which names are reserved to a given object by using the 2 drop-down lists at the top of the VB code editing window when you are in the module of a form. One of the lists has all of the objects and named 'things' (one of which will be "Form") while the other gets its content changed as you select diferent named 'things' with the 1st drop-down list.

There is a predefined routine for every textbox which routine is named _Change(). If the box is named txtMyMy (for instance), the routine will be named txtMyMy_Change(). (Routines that are associated with things this way are called "events.")

The name of the event is crucial. If you are in the code window of a form with a textbox of that name, and you just start typing "Private Sub txtMyMy_Change()," when you hit the Enter key the "End Sub" will be generated for you, and the drop-down lists will change. One will have "txtMyMy" in it, the other "Change." The association of the event with the object will be automatic, strictly based on name. Rename a control, and all the events you have written for it will become orphaned...

If you copy as you indicated, and the control name is the same, the association will happen, and it is purely based on the name of the control. (There is not similar action in code modules that are not part of a form.)

When you get to VB.NET, the lash-up is more intentional. You can name an event anything you like, but you tack on "Handles . . ." at the end to name which events will turn to that routine for code. In this way one single routine can "handle" the events of more than one object. You could (if you were bored) write a routine that changes the background color of a form to pink for 0.25Secs everytime a control loses focus—any control. You could write one routine to do this, and specify in the Handles suffix each of the controls whose _LostFocus() event will call that routine.

But you're right, the association in VB is less clear.

The arguments in the events are predefined as well. If there is an argument which VB creates named "Cancel," setting that to True within the routine will cancel the action. (Of course, this variable will only be created for events that lend themselves to being canceled...) The name of the argument is [u]not</u> cast in stone—if you really want to you can change it.

Let's take the Cancel argument as an example. The behavior of the control—that is, the code that makes up the control but which you do not have access to: how to handle keystrokes, how to handle highlighting, etc.—will generate a Boolean before calling the cancelable event, then will pass a reference to that variable, and will finally test its value when the event routine has finished. Let's say it is _BeforeUpdate(). The intrinsic code will [u]behave</u> like this 9this is pseudo-code):     The part you will see wil be like: You could re-write this to without any change in behavior. Cancel is a local, routine-scope Boolean, and you can call it what you like; it still will modify the same memory location by reference under any name, and the calling routine will still be able to behave in accordance with that value.