views:

56

answers:

2

I have a Microsoft Access 2003 file with various tables of data. Each table also has a duplicate of it, with the name '[original table name]_working'. Depending on the user's choices in the switchboard, the form the user choose to view must switch its recordsource table to the working table. I refactored the relevant code to do such a thing into the following function today:

Public Sub SetFormToWorking(ByRef frm As Form)
    With frm
        .RecordSource = rst![Argument] & "_working"
        .Requery

        Dim itm As Variant
        For Each itm In .Controls
            If TypeOf itm Is subForm Then
                With Item
                    Dim childFields As Variant, masterFields As Variant

                    childFields = .LinkChildFields
                    masterFields = .LinkMasterFields
                    .Form.RecordSource = .Form.RecordSource & "_working"
                    .LinkChildFields = childFields
                   .LinkMasterFields = masterFields
                   .Form.Requery
               End With
            End If
        Next
    End With
End Sub

The lines of code that call the function look like this:

SetFormToWorking Forms(rst![Argument])

and

SetFormToWorking Forms(cmbTblList)

For some reason, the above function doesn't change the recordsource for the form. I added the 'ByRef' keyword to the parameter just to be certain that it was passing by reference, but no dice. Hopefully someone here can tell me what I've done wrong?

+1  A: 

Try removing the parenthesis from your function calls.

SetFormToWorking Forms(rst![Argument])

SetFormToWorking Forms(cmbTblList)

more information

marg
Good catch, but my function still isn't changing the form.
Ski
I don't understand this answer. The code in it is the same as that in the original question, and the parens *can't* be removed, because they are part of the syntax for reference an item in a collection, e.g., Forms(0) or Forms("MyForm") or Forms(rst!Argument) where rst!Argument is a field that holds a string that is a form name. Indeed, it might be a good idea to put in more parens, Forms((rst![Argument])) and Forms((cmbTblList)) in order to force evaluation of the expressions before it's passed for evaluation as a name in the collection.
David-W-Fenton
He edited his question. Originally he called his functions using: `SetFormToWorking (Forms(rst![Argument]))` My answer suggested removing the outer parenthesis.
marg
+1  A: 

I found the problem. The variable on the third line

rst![Argument]

doesn't exist in the function's scope. I replaced it with

.RecordSource

Unfortunately I'm having another problem with the code but it's unrelated to this question.

Ski
Um, don't you ever COMPILE your code? Obviously not, or you'd have found out immediately that it was not within scope.
David-W-Fenton
Excuse me for offending you so! It's always been my understanding that VBA code doesn't need to be compiled before being run.
Ski
@Ski: compiling is not compulsory, but compiling (combined with systematic use of OPTION EXPLICIT in every module) is potentially a great help for the developer.
iDevlop
@Patrick My last comment was inaccurate. I should have said that I didn't *know* you could compile before running VBA code. I don't understand how I could have done so much Excel VBA coding in the past without noticing that menu item!
Ski