Public or Private

Another decision that you have to make when you create procedures is whether to make them Public or Private. By default, Access will make procedures you create Public, but that's not necessarily what you want.

If you are working in a Module, the rules are a little different than if you are working in code that resides in a form or report. Forms and reports are intrinsically encapsulated as class modules, so their Public procedures aren't as public as you might expect. Let's cover procedures in Modules first.

Public and Private Procedures in Modules

Public Functions and Subs in Modules are just that—public property. Every area of your application can see them and use them. In order to do that, Public procedures in Modules have to have a unique name. Otherwise, how would your code know which one to run? If you have two Public procedures with the same name, you'll get a compile error.

Private procedures in Modules are very shy—they can't be seen or referenced by any code outside their own Module. If you try to reference a Private procedure from a different module or another form or report, Access will insist (at compile time) that no such procedure exists.

This hidden nature of Private procedures is their best feature. Because they are hidden, only their names need to be unique within their own module. Therefore, you can name them whatever you want—you don't have to worry about them conflicting with other procedures in your application.

This feature reallycomes into play when you reuse code by importing modules into other databases, maybe even ones you didn't create. If most of your module procedures are Private, you'll have a minimum of naming conflicts, since the rest of the application can't even see them. The Public procedures will still need to have a unique name, which is why many procedures that are meant to be imported have interesting prefixes like the author's initials or the company name.

Public and Private Procedures in Forms and Reports

Private procedures in Form and Reports behave just like Private procedures in modules. They are very private—they can't be seen or referenced from outside the form or report. The event procedures that Access automatically builds behind your forms and reports are automatically set to Private. This makes sense, as Form_Open and OnClick events are useful only inside that particular form or report. Also, these procedures need to have standard names, so it would seem that there would be a big mess with duplicate names across all your forms and reports if they were Public.

In reality, this problem wouldn't occur. The code behind your forms and reports isn't like the code in a normal module. Under the covers, it is really a class module, which is covered later in this chapter. You can see this in the Visual Basic Editing window, as shown in Figure 8-1.

It turns out that even a Public procedure that you build in the code behind a form can be named the same as a procedure in another form. This is because class modules require that you specify the name of the class object (in this case, the form name) before the name of the procedure if you want to call it from outside the form. However, this is rarely done. One possible situation might be some form initialization code that you want to run from outside the form, such as InitializeForm. If you want to do it, here's the syntax:

Form_frmMyFormName.InitializeForm

Microsoft Visual Basic - Chamber Application - [FormfrmMenuReports (Code)]

^ File Edit View Insert Debug Run Tools Add-Ins Window Help

Cte x

Project - Chamber Application

B i^f Chamber Application (Chamber App ^

B Microsoft Access Class Objects [HI FormJrmBusmess [jD FormJrmBusinesses [jD Form_frmBusinesses_TwoWaySor HI Form_frmMenu_About [jU FormJrmMenuJIonfiguration [HI Form_frmMenu_Mam ËH] Form_frmMenu_Reports HI Form_frmMenu_Splash £f) FormJrmMenuJJserTips [jf) Form_l:rmReport5elector_Member ^ | 21

Properties - frmMenu_Reports

¡FrmMenu_RepQrts Form_frmMenu_Reports

Properties - frmMenu_Reports

¡FrmMenu_RepQrts Form_frmMenu_Reports

(Name)

frmMenu Reports

AfterDelConfirm

m

Afterlnsert

Aft er Update

AllowAdditions

True

AllowDeletions

True

AllowDesignChanges

False

Alio1,",'Edit s

True

AllowFilters

True

AutoCenter

True

AutoResize

True

d

P r ivat e S ub cmdP r ev i e w_C 1 i c k () On Error GoTo Error_Handler

If He!IstReport.Column(3) £ "" <> "" Then

DoCmd.OpenReport ReportName:=Me!IstReport.Column(3) , End If

1 Update the Last Run Date of the report DoCmd.Hourglass True DoCmd.SetWarnings False

DoCmd.RunSQL "UPDATE tsysReport SET tsysReport.DtLastRan "WHERE tsysReport.RptKey = " £ He.IstRep DoCmd.SetWarnings True DoCmd.Hourglass False

Exit_Procedure:

On Error Resume Next DoCmd.SetWarnings True DoCmd.Hourglass False Exit Sub

Error_Handler:

If Err.Number = 2501 Then

Resume Exit_Procedure Else

MsgBox "An error has occurred in this application. £ "Please contact your technical support person and £ vbCrLf £ vbCrLf £ "Error Number " £ Err.Number £ " Buttons:=vbCritical, title:="Hy Application"

Figure 8-1

Notice that the prefix Form_ and the name of the form qualifies the InitializeForm procedure name. Since many forms could have the same procedure name, you need to tell the code which form's procedure you want to run.

0 0

Post a comment