refering to subform from subform header

[silentwolf]

Hi guys,

just in the middle of getting some navigations right on my forms and like to set it up more general for Form Appearence and functionality.

What I did is created a sfmHeaderDetails which is in fact just a form with several buttons on it like shown in the Attachment

New Contact, Contact Details, Delete Contact, Edit Contact and another with Back To Main

However to be able to use this sfmHeader on all of my forms which need those buttons I like to create functions that refer to the underlaying
subforms.

For example if I use this sfmHeaderDetails in a form frmCustomerSearch,
I like to make sure that in the subform smfAllCustomers a contact is selected in order to delete him.

Basically to refere to any subform depanding on where the sfmHeaderDetails is includet on a Form.

What I did manage so far is to go back to the mainform.

In a standard module I got following code:

Public Sub CloseMeAndOpenMain(frmMe As Form)
        On Error GoTo CloseMeAndOpenMain_Error
            DoCmd.Close acForm, frmMe.Parent.Name
            DoCmd.OpenForm "frmDashboard"
        On Error GoTo 0
    Exit Sub
    
CloseMeAndOpenMain_Error:
    MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure CloseMeAndOpenMain of VBA Dokument Form_frmContactSearch"

End Sub

In the classmodule of sfmHeaderDetails I have a button called btnReturnToMain

Private Sub btnReturnToMain_Click()
    CloseMeAndOpenMain Me
End Sub

So if I would have a new form frmCustomerSearch where I put in the form Header my sfmHeaderDetails and pick a customer from sfmAllContacts within the
frmCustomerSearch.

Hope that is well enough explained that someone could give me a hand with that?

Many thanks

Albert

 

[Pat Hartman]

The delete part of this is extremely dangerous. So dangerous in fact that I would never use this method. PERIOD. When referencing a subform from the main form or any other form for that matter, focus will ALWAYS be to the Current record. Not the row your eyeballs are on but the row that Access determines is Current. When the form opens, the Focus will be on the first row of the subform and that row will be current. If the user scrolls the subform but doesn't click into any row, the original first row is still the current record, not the record currently visible at the top of the form. The user has to click into a row to make it current. You should have code that highlights the entire row so that the user has some strong visual indication of what row is current or you will be deleting random rows. I don't care if you ask the user if he is sure. I don't care if you ask the user if he is sure he wants to delete record 123434. He will 99.99% of the time say yes without looking.

Warning given.

You refer to the parent form as Me.Parent You don't need to know its name. However, if you want to put focus back into the parent form, you will need to know the name of some control. Since you want to use this code on multiple forms, I would suggest adding a tiny unbound control and giving it the name txtFormGetFocus. Make sure it is the first control in the tab order prior to the one you actually want to get the focus. Then in the on Enter event of this control, you have code to tab to the next control.

To have a generic way of referring to the subform, standardize the name of the subform control. Access usually defaults the subform control name to the name of the form it contains but you can make the control name different and probably should in any event. So, again, for EVERY subform you want to use this "header" for, name the subform control sfrmCommon. And that is how your code refers to it. use the same txtFormGetFocus control and tab to the control you want to have the focus from there.

So now you can add the "header" as a subform to any main form. Name its control sfrmCommonHeader just in case you ever need to reference it. And then below add the subform control named sfrmCommon on to the main form.

PS. Just because I told you how to do this, doesn't mean I think it is a good idea. It is OK except for the delete which is very dangerous and I do not recommend that at all.

If I wanted to standardize this, I would add the buttons and code behind them to a dummy form. Then rather than embedding the form, I would copy the controls and the code to the header of the subform. That gives me the option to customize the code or delete individual buttons. So, you get the benefit of standardization but can also accommodate differences. The code in the click event of a button should call a function in a standard module and pass in a reference to the subform. That way the control can refer to the methods and controls on the subform. Since I'm using only one line of code to call the actual code, I might actually use an embedded macro. That way copying the controls, copies the code as well.

It is possible to do this with class modules but they are not flexible and you won't be able to remove/add optional buttons easily. Class modules are best for "black boxes". Code that never has to be modified and that can be used in multiple places. This request probably satisfies both the black box and multi-use requirements but I see a need for flexibility that I doubt you can get from a class without a lot of complexity.

Remember, the Form itself is a class. Access is doing lots of stuff for you behind the scenes and it only interacts with your code where you use form and control events. The Access code has "hooks". At certain points in its own procedures it determines that something happened in the interface (i.e. focus moved from one control to another), it gives you the opportunity to add your own code and the result is that one of your form or control events runs.

 

[silentwolf]

Hi Pat,

thanks for your reply!
I just read through it and need a bit more time to get all what you explained right but many many thanks for this!

I will get back to you once I got it working as you suggested!

Cheers