Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > Visual Basic > VB 6 Visual Basic 6 > Beginning VB 6
Password Reminder
Register
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
Beginning VB 6 For coders who are new to Visual Basic, working in VB version 6 (not .NET).
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Beginning VB 6 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old April 26th, 2006, 08:54 AM
Friend of Wrox
Points: 660, Level: 9
Points: 660, Level: 9 Points: 660, Level: 9 Points: 660, Level: 9
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2005
Location: St. Louis, , .
Posts: 101
Thanks: 0
Thanked 1 Time in 1 Post
Default merging projects

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.


Reply With Quote
  #2 (permalink)  
Old April 26th, 2006, 04:58 PM
Friend of Wrox
 
Join Date: Nov 2004
Location: Port Orchard, WA, USA.
Posts: 1,621
Thanks: 1
Thanked 3 Times in 3 Posts
Default

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):
Code:
    Dim cnc As Boolean

    This.BeforeUpdate(cnc)

    If cnc = True Then
        AbortMyself()
    End If
    The part you will see wil be like:
Code:
Private Sub TheCtrl_BeforeUpdate(Cancel As Boolean)
Code:
    ' Do my stuff here
    If Me.TheCtrl.Text = "" Then
        Cancel = True
    End If

End Sub
You could re-write this to
Code:
Private Sub TheCtrl_BeforeUpdate(StopIt As Boolean)
    ' Do my stuff here
    If Me.TheCtrl.Text = "" Then
        StopIt = True
    End If

End Sub
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.
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C++ projects for beginners 132591 C++ Programming 5 September 2nd, 2011 02:41 AM
c# projects book sarbjitmultani C# 0 January 17th, 2006 02:53 AM
Multiple Projects ~Bean~ ASP.NET 1.x and 2.0 Application Design 3 October 17th, 2005 07:59 AM
C-projects abdul_owiusa C# 1 July 28th, 2004 07:15 AM
Access Projects VBAHole22 Forum and Wrox.com Feedback 0 June 4th, 2003 08:39 AM



All times are GMT -4. The time now is 04:36 AM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.