Results 1 to 15 of 15

Thread: 'Call' error

  1. #1
    Join Date
    Mar 2004
    Posts
    287

    Unanswered: 'Call' error

    The followingf is part of a public module that I am linking other forms to. On the main forms I have the fields DayxID, DayxHalf, DayxFull and this code works fine if I insert it into the actual form. But I have numerous forms the same and want to repeat this code by using the 'Call' command from each form linking to the public function in the module.

    Code:
    Dim i As Integer
    Dim did As String
    Dim dhalf As String
    Dim dfull As String
    For i = 1 To 31
         did = "[" & "Day" & CStr(i) & "ID]"      '[Day1ID]
         dhalf = "[" & "Day" & CStr(i) & "Half]"  '[Day1Half]
         dfull = "[" & "Day" & CStr(i) & "Full]"  '[Day1Full]
        
        Select Case did
        Case 11
            dhalf.BackColor = Col11
            dfull.BackColor = Col11

    It calls it but has the folloowing error:
    Invalid qualifier (= dhalf)

    I understand that this may due to the VBA in the public not recogniszing that the field on the form matches this, can anyone help please?

  2. #2
    Join Date
    Jan 2009
    Location
    Kerala, India
    Posts
    183
    If you have copy pasted the code from some text source then look closely the small letter l in dhalf could be 1. Change it and try again.
    www.MsAccessTips.com (Learn MS-Access Tips & Tricks)
    Learn Advanced MS-Access Programming with sample VBA Code.

    All responses are based on Access 2003/2007

  3. #3
    Join Date
    Mar 2004
    Posts
    287
    i have checked for that and it works fine if i put it back into the normal form rather than module (call).

  4. #4
    Join Date
    Mar 2009
    Posts
    5,442
    Provided Answers: 14
    A string variable does not have a BackColor property. You declare these variables as string:
    Code:
    Dim dhalf As String
    Dim dfull As String
    Then you try:
    Code:
            dhalf.BackColor = Col11
            dfull.BackColor = Col11
    Have a nice day!

  5. #5
    Join Date
    Mar 2004
    Posts
    287
    but that's what my code above has?

    Dim i As Integer
    Dim did As String
    Dim dhalf As String
    Dim dfull As String

    For i = 1 To 31
    did = "[" & "Day" & CStr(i) & "ID]" '[Day1ID]
    dhalf = "[" & "Day" & CStr(i) & "Half]" '[Day1Half]
    dfull = "[" & "Day" & CStr(i) & "Full]" '[Day1Full]

    Select Case did
    Case 11
    dhalf.BackColor = Col11
    dfull.BackColor = Col11

  6. #6
    Join Date
    Mar 2009
    Posts
    5,442
    Provided Answers: 14
    Said with other words: A string variable does not have a BackColor property, so you cannot use :
    Code:
    dhalf.BackColor = Col11
    While dhalf is declared as:
    Code:
    Dim dhalf As String
    Have a nice day!

  7. #7
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    as we don't know what dhalf and dfull are you need to declare these as object AND make certain you pass the relevant object to them when calling the function.

    my guess is they are controls on a form or report
    I'd rather be riding on the Tiger 800 or the Norton

  8. #8
    Join Date
    Mar 2004
    Posts
    287
    they are basically coloured boxes on a form. This code works on the form but not in the module though - that's my problem.

    so
    dhalf = "[" & "Day" & CStr(i) & "Half]" '[Day1Half]

    dhalf would equal [Day1Half] control - then it changes the back colour.

  9. #9
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    OK there's a basic concept here
    if you declare a variable of type string it can only accept values that are of type string, or string compatable. its not an object, so it doesn't have any properties or methds associated with it.

    backcolor is a property of various controls used on forms and reports, and thos objects themselves.

    therefore you cannot assign a value to anon existent property.

    you have two choices either you return a value from your common module (say a colour) and set the relevant property from within the form or report OR you pass the object tot eh function and allow the function to set the controls properties.

    Given you are trying to create a month calendar, I think you will be better off returning the data to a calling form or report and set the values there. However you could run your loop inthe calling form/report and pass an object(s) to the function.
    I'd rather be riding on the Tiger 800 or the Norton

  10. #10
    Join Date
    Mar 2004
    Posts
    287
    but this DOES work on the form VBA. Perfectly!

  11. #11
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    thats almost certainly because the Access runtime realises that there is a control as well as a variable called dhalf in the form, and determines that you cannot possibly be referring to a variable with any properties and that there is a valid object of that name so refers to the object, the control.

    when you try to run the same code in a code module, the runtime doesn't have that capability, it only knows the variable so it gives up in a hissy fit.
    I'd rather be riding on the Tiger 800 or the Norton

  12. #12
    Join Date
    Mar 2004
    Posts
    287
    I think I understand. But I thought the idea of modules was that they were like running the same pieces of code over and over (saving duiplication)?

  13. #13
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    yes they are / can be. however you need to pass the correct items into the module
    what you are doing in the module is not the same as you were doing in the form.

    in order for your code to work in the module you need to either pass it an object OR retrieve a value and use that value in the form. Making variables public / global (without good reason) is a recipie for disaster. also using the same name for multiple items is a recipie for disaster. I understand why Microsoft choose to use control names the same as variable names but it can cause confusion.

    one of the main reasons to use a module is where you can reuse code elsewhere, generally that means loosely coupled class / modules. IE you write modules which dont change any control / variable inside the module but return a value to calling forms / reports / modules.
    I'd rather be riding on the Tiger 800 or the Norton

  14. #14
    Join Date
    Sep 2001
    Location
    Chicago, Illinois, USA
    Posts
    601
    NeilMansell,

    There are a number of fundamental problems here, foremost is you use of the names "dhalf" and "dfull" to each refer to two different things.

    Apparently, they are controls on a form.

    Then, in your code, you have stated (using a dim declaration) that these are string variables.

    You can't use one name to refer to two different things. Either they are controls on the form or they are string variables--they can't be both at the same time.

    The code, apparently, does run because, when the code is on the form, Access sees that you are using these named objects with the backcolor property and assumes they are objects on the form. When the code is not on the form, Access does not make this assumption. Bottom line, you just lucked-out with the code running on the form, but the real character of this code is revealed when it is not on a form.

    Clean up the code.
    Ken

    Maverick Software Design

    (847) 864-3600 x2

  15. #15
    Join Date
    Mar 2004
    Posts
    287
    good point. Thanks. I will look into doing that.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •