Cannot assign a value (1 Viewer)

alanm2007

Registered User.
Local time
Today, 09:40
Joined
Sep 22, 2011
Messages
10
Hi all,

We've just upgraded to Office 365 and I've had a puzzling error come up in one of my forms. There's a part of Form_Current routine that display an error only when a the form is first opened:

Private Sub Form_Current()

If Me.NewRecord = False Then

Me.cmbCustomer.SetFocus

Call ValidateForm(False, False)

If Me.Warn.Value = True Then
Me.Warn_Msg.Visible = True
MsgBox Me.Warn_Msg.Value, vbApplicationModal, "Customer warning"
Else
Me.Warn_Msg.Visible = False
End If

If Me!frmInvoices!txtTotalLice <> 0 Then
Me.MIL_Lic.Value = True <<<< ERROR 2448
Else
Me.MIL_Lic.Value = False <<<< ERROR 2448
End If

End If

End Sub


"You cannot assign a value to this object"

MIL_Lic is just a tick box, so is only True/False or -1/0 and I've tried both formats
Strangely enough, it only happen when the form first loads up - every other trigger for Form_Current does not display an error.
Does access do something different when Current runs for the first time?
It was working fine under access 2007

Help!
 

Minty

AWF VIP
Local time
Today, 09:40
Joined
Jul 26, 2013
Messages
10,355
2016 or in fact any later versions are syntactically "fussier" than previous versions. Just to check, is there anything in the forms load event that might influence those controls?

Also for simplicity you could replace all that section of code with

Code:
Me.MIL_Lic = Me!frmInvoices!txtTotalLice <> 0
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 05:40
Joined
Oct 17, 2012
Messages
3,276
Putting in code tags with appropriate indentation to make it easier to read.

Code:
Private Sub Form_Current()

    If Me.NewRecord = False Then
    
        Me.cmbCustomer.SetFocus
        
        Call ValidateForm(False, False)
        
        If Me.Warn.Value = True Then
            Me.Warn_Msg.Visible = True
            MsgBox Me.Warn_Msg.Value, vbApplicationModal, "Customer warning"
        Else
            Me.Warn_Msg.Visible = False
        End If
            
        If Me!frmInvoices!txtTotalLice <> 0 Then
            Me.MIL_Lic.Value = True '<<<< ERROR 2448
        Else
            Me.MIL_Lic.Value = False '<<<< ERROR 2448
        End If
    
    End If

End Sub
Also, what is Me!frmInvoices referring to? Me refers to the calling form, so what is frmInvoices supposed to be? The exclamation point tells Access to refer to the default property, which for all forms (including the one referenced by the Me object) is the controls collection. If that's a subform, then your syntax is off.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 04:40
Joined
Feb 28, 2001
Messages
27,001
Just for the record, when you have a control that HAS a value, then the default property IS .Value - and therefore need not be explicitly referenced. Note that sub-forms, tab controls, lines, sections, and rectangles have no value so have no .Value property. If you just name the control, you get its value if it has one.

A reason that might block you from performing the TRUE/FALSE assignment would be if you tried to set the value of a bound field on a form that either (a) does not allow edits (see .AllowEdit property of the form) or (b) is bound to a read-only recordset or (c) has been opened in read-only mode.
 

Solo712

Registered User.
Local time
Today, 05:40
Joined
Oct 19, 2012
Messages
828
Hi all,

We've just upgraded to Office 365 and I've had a puzzling error come up in one of my forms. There's a part of Form_Current routine that display an error only when a the form is first opened:

Private Sub Form_Current()

If Me.NewRecord = False Then

Me.cmbCustomer.SetFocus

Call ValidateForm(False, False)

If Me.Warn.Value = True Then
Me.Warn_Msg.Visible = True
MsgBox Me.Warn_Msg.Value, vbApplicationModal, "Customer warning"
Else
Me.Warn_Msg.Visible = False
End If

If Me!frmInvoices!txtTotalLice <> 0 Then
Me.MIL_Lic.Value = True <<<< ERROR 2448
Else
Me.MIL_Lic.Value = False <<<< ERROR 2448
End If

End If

End Sub


"You cannot assign a value to this object"

MIL_Lic is just a tick box, so is only True/False or -1/0 and I've tried both formats
Strangely enough, it only happen when the form first loads up - every other trigger for Form_Current does not display an error.
Does access do something different when Current runs for the first time?
It was working fine under access 2007

Help!

This error sometimes happens if your Control Source (on the Properties Data Tab) does not agree with the Name (on the Properties Other Tab). Specifically, you need to refer to the Mil_Lic field by its "Name" !

Don't know if this you problem but check anyhow!

Best,
Jiri
 

alanm2007

Registered User.
Local time
Today, 09:40
Joined
Sep 22, 2011
Messages
10
Thanks to all for you're input.
I've gone back into it and made some changes and noticed that when I click on the (linked) table, it will not allow me to make changes to the field 'MIL_Lic' and displays the same error message - but if I open the actual table itself, it can be changed with no error.

It seems to be a problem with the table and not the coding (or maybe the link?)

I think I might try and relink it to see if I can clear the problem

Thanks again for you're suggestions
 

theDBguy

I’m here to help
Staff member
Local time
Today, 02:40
Joined
Oct 29, 2018
Messages
21,358
Thanks to all for you're input.
I've gone back into it and made some changes and noticed that when I click on the (linked) table, it will not allow me to make changes to the field 'MIL_Lic' and displays the same error message - but if I open the actual table itself, it can be changed with no error.

It seems to be a problem with the table and not the coding (or maybe the link?)

I think I might try and relink it to see if I can clear the problem

Thanks again for you're suggestions
Hi. Pardon me for jumping in. Is it a linked table to SQL Server? Perhaps it is read only in Access. Do you have a primary key in the SQL Server table? Or, is the linked table in Access actually a View in SQL Server? Just curious...
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 05:40
Joined
Oct 17, 2012
Messages
3,276
Does the table have a primary key? If it doesn't have one and one isn't assigned as part of the linking process, then Access will treat it as read-only.
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 05:40
Joined
Oct 17, 2012
Messages
3,276
DBGuy:

 

Attachments

  • CatHissing.jpg
    CatHissing.jpg
    8.6 KB · Views: 249

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 05:40
Joined
Oct 17, 2012
Messages
3,276
LOL You're fine.

Just always a kick in the pants to answer a post, only to find someone else answered it while you typed!

The irony here is this just came up at work for a co-worker. It was the reason a form would not open correctly when opened in data entry mode.
 

Mark_

Longboard on the internet
Local time
Today, 02:40
Joined
Sep 12, 2017
Messages
2,111
One issue that I did notice is the following line;

Code:
If Me!frmInvoices![B]txt[/B]TotalLice <> 0 Then

Txt normally indicates that a control is being used for a string. Are you trying to see if this is a blank string, zero length string, or if it does not equal the character "0"?

Sometimes using the wrong validation can lead to intermittent issues. While not directly addressing your question it is something to think about for the future.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 04:40
Joined
Feb 28, 2001
Messages
27,001
Very good catch, Mark. If that prefix has any meaning at all, then the expression can never be 0 though it CAN be "0" if needed. But that should either compile as a type mismatch or should trigger a run-time type mismatch alert.
 

alanm2007

Registered User.
Local time
Today, 09:40
Joined
Sep 22, 2011
Messages
10
Thanks all for your suggestions - after spending a bit of time messing about with it and googling it, it turns out that I need to turn off the reference library for calendar control as it's no longer valid in 2016!
What that has to do with that bit of coding (which has no date reference in it) is beyond me!

Thanks again
 

Gasman

Enthusiastic Amateur
Local time
Today, 09:40
Joined
Sep 21, 2011
Messages
14,050
Oops,

I use that as a prefix for textbox controls after being advised not to use the same name as the source that Access uses when creating a form.


One issue that I did notice is the following line;

Code:
If Me!frmInvoices![B]txt[/B]TotalLice <> 0 Then

Txt normally indicates that a control is being used for a string. Are you trying to see if this is a blank string, zero length string, or if it does not equal the character "0"?

Sometimes using the wrong validation can lead to intermittent issues. While not directly addressing your question it is something to think about for the future.
 

Mark_

Longboard on the internet
Local time
Today, 02:40
Joined
Sep 12, 2017
Messages
2,111
While ACCESS cares little what you call controls (so long as the name isn't something it uses for something else), having a good naming convention can help you and others working on your code understand what you are using the control for.

I got in the habit of using Dt as a prefix for dates and Nu for Numbers. Since ACCESS sees it as "Enter text", you need to be reminded what you intended it for when your looking at your code six months later. From experience, having mis-named controls in code can be a real pain to resolve!
 

Gasman

Enthusiastic Amateur
Local time
Today, 09:40
Joined
Sep 21, 2011
Messages
14,050
Thanks Mark,

No one is going to see my code (for the most part) except me.
I've even just cobbled together some code to rename controls on a form after creation so as to keep to this txt, cbo etc format.
I do however hopefully give them meaningful names such as txtStartDate to indicate the type of data a control holds.
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 05:40
Joined
Oct 17, 2012
Messages
3,276
I disagree with Mark on control naming 100%.

You see, I go the other way around. If I can't tell from the name what a control is supposed to contain, then the name sucks and needs to be changed. However, it's just as important to know what kind of control you're working with.

I indicate the control type with the prefix, because that will tell me what special properties they have that others might not, such as Text for textboxes, RowSource for listboxes, etc. I took those prefixes straight from the Access Developer's Handbook:

*txt for textboxes
*cbo for comboboxes
*lst for listboxes
*cmd for command buttons
*etc

That makes it easy for me to know while coding both what kind of control it is and what data it contains. Examples are cboRecoveryIDNum, txtDOB, cmdQuit, and lstScreenName. Each makes it explicitly clear both what kind of control it is (and thus which properties are available), what data it contains (if any), and what general type that data is.
 

Gasman

Enthusiastic Amateur
Local time
Today, 09:40
Joined
Sep 21, 2011
Messages
14,050
That is the way I do it now, but my early attempts just used what Access generated, and I've seen since that it is advised to prefix them in someway to differentiate from the actual source fields, so that is what I do from now on, hence creating that routine to make life easier for me, should I create new forms.

Which reminds me, one for Reports would not go amiss. :)
 

Frothingslosh

Premier Pale Stale Ale
Local time
Today, 05:40
Joined
Oct 17, 2012
Messages
3,276
Yeah, for report objects the traditional prefix is rpt.

I actually wrote a procedure myself that goes through a given form and renames all of the default controls, including attached labels. Well, by all, I mean text boxes, combo boxes, check boxes, and labels. It won't touch objects that already use my convention.

I ended up writing it after inheriting an app that used ginormous numbers of controls on certain forms, some using field names as names, others using the default names Access provides when you just create a new text box manually. It was WAY faster to write that procedure than to rename every field on every form manually.
 

Users who are viewing this thread

Top Bottom