So I'm trying to centralize the common functionalities like saving a
change, finding a record, deleting a record etc. In trying to do so, I
find myself clueless when it comes to handling the DoCmd object and its
properties which seem pretty ubiquitous in access,vb code.
The trick to doing the above type stuff is to learn the ms-access object
model, and in your case, the "Forms" object model.
Example:
1. The following code is at the form level. I want to put the main
functionality in a sub in Main()
First, the reference to "main()" don't apply here, and don't make sense.
However, you can certainly create standard code module, and in side of this
module create subroutines that you can call to do your work.
First, lets take the code:
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, ,
acMenuVer70
Sorry, but that above code is written by the wizard, and it really sucks. I
suppose since ms-access is well over ten years old, then you do get some
silly code written by the wizard. Not a big deal.
I would use the following code to force a record save:
if me.dirty = true then
me.dirty = false
gRecordSaved = True
end if
It should be noted that your code of gRecordSaved = true is likely not going
to be necessary here, and further use of global really is not a good idea,
as you might have multiple forms open (you do realize that you can have
multiple copies of the SAME form open). If that var is a form level variable
(note that forms all can have their "own" code module), then it could I
suppose be used to tell you that the save key has been used, but then again
you can always check the "dirty" property of a form to see if data has been
modified.
2. I see the usage of "Form" ( IsNull(Form.[conf_id]) ) to refer to
active form in certain places and "Me" in others. WHats the difference
between Form and Me?
Great question. You can see in my above code, that I used "me". ME simply
refers to the current form reference that the code is running under. Since
a good deal of code is written around a forms events, then this shortcut is
provided by ms-access. Note that this reference is ONLY VALID in forms code.
So, if you were to take that code and place it in a standard code module,
then you would have to use a qualified forms reference (eg
forms!yourformname)
Our code in the forms module could become:
Private Sub cmd_Save_Conf_Click()
Call MySave
End Sub
Now, in a standard public module, we can go:
Public Sub Mysave
if forms!frmCustomer.dirty = true then
forms!frmCustomer.dirty = false
gRecordSaved = True <???
end if
end sub
However, we don't want to have to write a new piece of code for every form.
So, what would even be better is to pass a forms reference to the sub
routine. We get:
Private Sub cmd_Save_Conf_Click()
Call MySave(forms!frmCustomer)
End Sub
Now, in a standard public module, we can go:
Public Sub Mysave(frm as form)
if frm.dirty = true then
frm.dirty = false
gRecordSaved = True <???
end if
end sub
Note how I hard coded the code of:
Private Sub cmd_Save_Conf_Click()
Call MySave(forms!frmCustomer)
End Sub
As I mentioned, "me" is equivalent of the current form (in form code
ONLY!!). So, I could use:
Private Sub cmd_Save_Conf_Click()
Call MySave(me)
End Sub
However, it should be pointed out that I don't think you really should pull
the "save" code out of your forms and put it in a general routine. You might
get away doing this for some forms, but likely you will need some
verification code, and other types of things like telling the user to fill
out some fields etc. BEFORE they can save. So, you might want to leave the
actual save code in the actual form.
In fact, if you decide to build a custom menu bar, then you likely will want
that menu bar to work for more then one form, and the best way to do that is
have the custom menu call "public" functions of the particular form. Note
that any function you define as public in a form becomes a method of that
form
Private Sub cmd_Save_Conf_Click()
me.MySave
End Sub
note that if you do have a valid form ref, you can go
frm.MySave
So, any public function of a form becomes a method of that form..
3. Whats the difference between the . and the ! used to refer to
members of a form?
In a nut shell, all "dot" references must be resolved at compile time (and,
this is why you get the handy dandy inteli-sense with .dot, but not with
bang).
Another point is that ! bang denotes a member of a collection, where as
"dot" references to properties and methods (and, those properties and
methods are thus checked at compile time). It turns out that often
properties and methods are them selves a collection, and that confuses
things. (properties = values, and methods = do some code thing)
References with a ! (bang) can be resolved at runtime. So, when you refer to
controls on the screen, you should use "dot" (and, if you delete the
control, then your code will not compile). (I assume you compile your code
before you run it). If you want to refer to just the data behind the form,
then use !. However, even in this case were you want to refer to just the
data, the form builds a collection of controls of the form. So, in fact, !
does work to refer to controls. For this reason, there is a good many
developers that actually NEVER name the controls on the form as the same as
the fields in the underlying database (and, that is the default). Myself am
too lazy to do this, and thus I just use the ! bang when grabbing data, and
not wanting to worry if the control may, or may not be on the screen. Thus,
my context of using ! means I am wanting to grab data, and not care about
the control. If I care about the control, then I use dot.
For the most part, you can get away using either one..but ! refers to "user
created" collections (that might be forms you build, controls you build
etc). The "dot" is for properties and methods of a form, or the object in
question. However, as mentioned, since ms-access add all controls as a
properties to a form, you can use "dot".
So, dot should be only used for built in things, and ! for stuff you make,
but that handy dany inti-sense while you write code makes it so easy to use
"dot"...so that is what most of us use....
