UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> What caused Runtime-error 2115    
 
   
HuntsvilleMan
post Feb 13 2010, 11:52 PM
Post#1



Posts: 258
Joined: 8-September 09
From: Huntsville, Alabama


When I try to write to a text box on a form i get Runtime-error 2115 which states "The macro or function set to the BeforeUpdate or ValidationRule property for this field is preventing Microsoft Office Access from saving the data in the field."
The form has a listbox and a textbox. What I'm trying to do is write to the textbox from the listbox click event.
Below is the code where the error occurred.

Me.txtLine1.Locked = False
Me.txtLine1.SetFocus
Me.txtLine1.Text = " " ' <-------- debug shows error 2115 happened at this line
Me.txtLine1.Locked = True

Anyone have an idea for how to avoid this error.
Thanks
Mike
Go to the top of the page
 
projecttoday
post Feb 14 2010, 12:53 AM
Post#2


UtterAccess VIP
Posts: 8,604
Joined: 10-February 04
From: South Charleston, WV


I think Me.txtLine1.Text is Visual Basic. Try Me.txtLine1.Value or Me.txtLine1

Robert
Edited by: projecttoday on Sun Feb 14 0:54:26 EST 2010.
Go to the top of the page
 
missinglinq
post Feb 14 2010, 10:52 AM
Post#3



Posts: 4,384
Joined: 11-November 02



Given the error message, the pertinent questions would seem to be
That code do you have in the BeforeUpdate event or what do you have in the BeforeUpdate box in the Properties Pane?
Do you have a Validation Rule set up for this field?
The Text Property is valid in VBA, it just means something else than it does in straight VB. It can only be accessed when the given control has focus, as the OP has done here.
But, in point of fact, most of the above code is useless! In code you can assign a value to a Control, even if it's Locked! The single line
Me.txtLine1 = " "
will accomplish what the OP wants to do. But, once again, the line tripping the error isn't actually where the problem is, but rather where Access has pointed to.
Also, given the scenario presented, I fail to see the need for setting the txtLine1 control to an empty string to begin with.
Go to the top of the page
 
GroverParkGeorge
post Feb 14 2010, 01:58 PM
Post#4


UA Admin
Posts: 30,971
Joined: 20-June 02
From: Newcastle, WA


Agreed.
Here's what Help has to say on the subject (bold added for emphasis):
"While the control has the focus, the Text property contains the text data currently in the control; the Value property contains the last saved data for the control. When you move the focus to another control, the control's data is updated , and the Value property is set to this new value. The Text property setting is then unavailable until the control gets the focus again. If you use the Save Record command on the Records menu to save the data in the control without moving the focus, the Text property and Value property settings will be the same."
It depends, in part, on what ELSE is going on when the Before Upate event fires on the form. If, as it might appear, code is trying to update this control, and also trying to set its value in the Before Update event, the conflict will throw an error.
George
Go to the top of the page
 
HuntsvilleMan
post Feb 14 2010, 05:11 PM
Post#5



Posts: 258
Joined: 8-September 09
From: Huntsville, Alabama


Well, I have a fix but not a very good explanation for why I suddenly got a Runtime-error 2115 when I tried to access a text box on a form from a listbox event.
When used within other event code the line below works as expected:
Me.txtPhoneNumber1.Text = " "
When used within listbox event code the code above fails with the 2115 error, however, the following line of code works just fine.
[Forms]![MyForm1].[txtPhoneNumber1] = " "
Perhaps someone with more experience can offer some insight into why this would happen.
Thanks for all suggestions.
Mike
Go to the top of the page
 
missinglinq
post Feb 14 2010, 07:08 PM
Post#6



Posts: 4,384
Joined: 11-November 02



Me.txtPhoneNumber1.Text = " "
auses a problem, when used within listbox event code, because, as has been said, you can only use the Text property if that control has focus, and it can't have focus while you're in an event of the ListBox. I'm still confused as to why you'd want to set the textbox to an empty string at this time.
[Forms]![MyForm1].[txtPhoneNumber1] = " "
works because you're using the Value property (it's the default property and is assumed, when you don't actually add a property) and this property doesn't require that the textbox have focus.
Go to the top of the page
 
HuntsvilleMan
post Feb 15 2010, 07:55 AM
Post#7



Posts: 258
Joined: 8-September 09
From: Huntsville, Alabama


To answer why I use the code below I'll provide a few more details:
Forms]![MyForm1].[txtPhoneNumber1] = " "
This is how I clear a textbox on the form that no longer has valid data due to other selections the user has made. For example, the user may have canceled a request for any one of a number of reasons and rather than leave old data on the screen, I clear everything that had to do with the earlier (and now invalid) request.
Perhaps there is a better way to reset textboxes so they appear empty to a user. Since this textbox is only used for display (never for user input), I had assumed that settining it to any value that appeared to make the textbox look empty would be just fine. That's also why I momentarily unlock and relock the textbox, so that the user will not feel compelled to try entering data into it. There is probably a better way to signal this "display only" use to the user but that's the best I've figured out so far.
Being a novice at this, I certainly appreciate all suggestions.
Thanks for the comment.
Mike
Go to the top of the page
 
projecttoday
post Feb 15 2010, 02:27 PM
Post#8


UtterAccess VIP
Posts: 8,604
Joined: 10-February 04
From: South Charleston, WV


To make it look like it's been de-commisioned set enabled = no or change the color. A good choice is the same color as the form.
orms.thisform is same as Me.
Go to the top of the page
 
RiverKing
post Aug 5 2013, 12:47 PM
Post#9



Posts: 131
Joined: 5-August 13
From: North Texas (DFW)


I found this topic knowing why Err 2115 was raised and wondering how I could get around it. Having finally discovered a simple work-around, I felt I ought to let others in on it.
My situation is an unbound field that the user updates. After validation in a BeforeUpdate procedure, the new data is saved in a bound field that is hidden behind the unbound field. This is done because the data may be entered in a couple of different formats but is distilled so that it is saved and later processed in only one. For example, the user might have entered "2 d 495"; that would have been translated for storage to 3,375 (minutes). I wanted to expand the user's input to display "2 days 8:15" (another format the user could have used). That's when Err 2115 was raised.
My solution was to move the reformatting to an OnExit procedure. The user sees his entry expanded in a flash, visually confirming that his entry was received and understood. The same solution might work by putting the reformatting in an AfterUpdate procedure but, in my case, there was already a fairly complex procedure there that I didn't want to disturb.
Go to the top of the page
 
RiverKing
post Aug 7 2013, 06:06 PM
Post#10



Posts: 131
Joined: 5-August 13
From: North Texas (DFW)


Further update: I did some code-juggling and managed to move the reformatting from the On Exit to the After Update procedure. Time well spent. The user can now tab through all 10 of these days, hours, minutes fields without entering the reformatting code. That code was fairly efficient and quick but not near as quick as not executing it at all.
Go to the top of the page
 
gemmathehusky
post Aug 7 2013, 06:16 PM
Post#11


UtterAccess VIP
Posts: 4,432
Joined: 5-June 07
From: UK


i got this a couple of days ago, and eventually realised (after much wasted time) i was trying to change the control value again within the before update event. That may be the issue.
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    20th November 2017 - 02:54 AM