Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

help with docmd, "Form"

Discussion in 'Information Technology' started by gurumum@email.uc.edu, Nov 10, 2005.

  1. gurumum@email.uc.edu

    gurumum@email.uc.edu
    Expand Collapse
    Guest

    Hi

    I am new to Access & VB and have a question I hope you can answer:

    I have around 10 forms that merely display current record contents and
    allow changing current values of fields or adding a new record. Each
    form represents a separate entity (user1, managers, rooms_and_equipment
    etc. )but in essence, the basic processing of data in the forms are
    pretty much the same.

    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.

    Example:
    1. The following code is at the form level. I want to put the main
    functionality in a sub in Main()
    and just call the corresponding function from this form. Can you please
    show me a sample of how I go about that?

    Private Sub cmd_Save_Conf_Click()

    On Error GoTo Err_cmd_Save_Conf_Click

    DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, ,
    acMenuVer70
    gRecordSaved = True


    Exit_cmd_Save_Conf_Click:
    Exit Sub

    Err_cmd_Save_Conf_Click:
    MsgBox Err.Description
    Resume Exit_cmd_Save_Conf_Click

    End Sub

    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?

    3. Whats the difference between the . and the ! used to refer to
    members of a form?

    Thank you,
    Madhu
     
  2. Loading...


  3. Albert D.Kallal

    Albert D.Kallal
    Expand Collapse
    Guest

    > 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....

    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    pleaseNOOSpamKallal@msn.com
    http://www.members.shaw.ca/AlbertKallal
     
  4. gurumum@email.uc.edu

    gurumum@email.uc.edu
    Expand Collapse
    Guest

    Thanks a lot for your help Albert. Apart from my question, you've even
    addressed several other aspects I wasn't clear about in Access. Your
    pointers have been very helpful.

    I really appreciate it.

    Thank you,
    Madhu
     

Share This Page