Changing a subform property (1 Viewer)

rdw456

Novice
Local time
Today, 10:38
Joined
Jul 20, 2012
Messages
43
Hi All Thanks in advance

I have a Main form on current event that checks a yes/no field and allows or disallows edits depending on the value. I have also subforms that do the same.

When I go to another record the main form works fine but the subforms allow edits no matter what the yes/no field value is on the main form.
I want to have the subforms AllowEdits property to False so it is in line with the main form.

Here is the code I have been using.

Code
-------------------------------------------------------------------------------------
If Me.txtLocked = -1 Then
Me.AllowEdits = False
Me.lblShiftClosed.Visible = True
Else
Me.AllowEdits = True
Me.lblShiftClosed.Visible = False
End If

Me.FsubShiftBar.Form.AllowEdits = False
 
Hi. In the code you posted above, you're not checking whether to allow edits to the subform or not. Does it always not allow edits in the subform, or are you saying it's always allowing edits to the subform?
 
You need to use the name of the control on the main form that contains the subform.

Another slightly more concise way of doing this is
Code:
Me.subformcontainername.Form.AllowEdits=Me.AllowEdits
 
Put it in the if structure then?

Code:
If Me.txtLocked = -1 Then
	Me.AllowEdits = False
	Me.lblShiftClosed.Visible = True
	Me.FsubShiftBar.Form.AllowEdits = Me.AllowEdits
Else
	Me.AllowEdits = True
	Me.lblShiftClosed.Visible = False
	Me.FsubShiftBar.Form.AllowEdits = Me.AllowEdits
End If

HTH
 
Hi Gasman
If the OP uses the more concise version of the code, as in my post and yours, place that line outside in the If..Else..End if section and only write it once
 
I'm too slow writing replies. :(

Yes, your idea is better. I'd only thought of using the Me.AllowEdits as I was moving it. :D

I never even realised there were two posts that got in before me. :banghead:
 
I tried to follow my own code logic compared to the goal and thought this untested snippet would be another way
Code:
Dim bolLocked as Boolean
bolLocked = Me.txtLocked
With Me
 .AllowEdits = Not bolLocked
 .lblShiftClosed.Visible = bolLocked
 .FsubShiftBar.Form.AllowEdits = Me.AllowEdits
End With
 
Last edited by a moderator:
Micron,

May I ask please?
Why use another variable and not the form control directly?


I tried to follow my own code logic compared to the goal and thought this untested snippet would be another way
Code:
Dim bolLocked as Boolean
bolLocked = Me.txtLocked
With Me
 .AllowEdits = Not bolLocked
 .lblShiftClosed.Visible = bolLocked
 .FsubShiftBar.Form.AllowEdits = Me.AllowEdits
End With
 
Does that mean the same in Canada then? ;)
 
Micron,
May I ask please?
Why use another variable and not the form control directly?
It's just another approach. Rather than repeatedly use the form control reference (which is longer than the variable name) I think it's shorter when it needs to be referred to several times. Maybe it also makes code easier to follow - maybe I'm just lazy? It's just my style, I guess. I also tend to use aliases in sql rather than repeating some 20-character table name 25 times - not that I use long object names anyway. Heck, in some ways I'm lazy yet too verbose - like with this answer!:)

The suggestion only saves maybe 2 lines of code (this time) so no biggie. BUT since a condition of the form or one if its involved controls is either True or False, you can set some needed properties to True and some to Not True in the same block, thus avoiding a block of code for False as well. If there is a triple state situation, then it wouldn't be as useful or even possible, I think.
 
I just asked as I seem to recall there was specific reason why someone would use

Set db = CurrentDB()

and use db instead of CurrentDB() each time.
I realise the above is with an object, but thought there might be a similar reason behind it.

It's just another approach. Rather than repeatedly use the form control reference (which is longer than the variable name) I think it's shorter when it needs to be referred to several times. Maybe it also makes code easier to follow - maybe I'm just lazy? It's just my style, I guess. I also tend to use aliases in sql rather than repeating some 20-character table name 25 times - not that I use long object names anyway. Heck, in some ways I'm lazy yet too verbose - like with this answer!:)

The suggestion only saves maybe 2 lines of code (this time) so no biggie. BUT since a condition of the form or one if its involved controls is either True or False, you can set some needed properties to True and some to Not True in the same block, thus avoiding a block of code for False as well. If there is a triple state situation, then it wouldn't be as useful or even possible, I think.
 
The reason for setting db=CurrentDb is that if Currentdb is used repeatedly in an app, Access has to interpret it each time which slightly increases processing time.

The triple state neutered comment was a joke that seems to have fallen flat based on your use of 'bollocked' as a variable name.

But a serious response - I don't see any advantage of using that instead of true /false. As those are native to Access, I believe program flow would be marginally faster than introducing a variable ...even one with a funny name
 
Ok - it's a UK thing. I should have realized that camel case wouldn't cut me any slack - not that the word is in my vocab. Not even sure I know the UK meaning of it, but can guess now. :o

As those are native to Access,
assigning the result of some thing = True or some thing = False to a variable isn't native but the test itself is? Not sure I'd agree with what I wrote being "non-native" to Access.

The CurrentDb thing is an entirely different matter. Put another way, each time you process a line such as Currentdb.Execute a copy of the current db is created and only persists until the command is processed. 5 of CurrentDb.something means 5 db copies created and destroyed (for lack of a better term).
Set db = CurrentDb means 1 copy persists until Set db = Nothing or the memory space is otherwise reclaimed.
 
need to clarify The main form has several sub forms in the interest of keeping it simple I am only dealing with one sub form for this as once i find the problem is for one i will do the rest when solved.

Two forms a Main and a sub

On the the same code on the current event of both main Form and sub Form.

Code
------
If Me.txtLocked = -1 Then
Me.AllowEdits = False
Me.lblShiftClosed.Visible = True
Me.FsubShiftBar.FsubShiftBar.Form.AllowEdits = False
Else
Me.AllowEdits = True
Me.lblShiftClosed.Visible = False
End If


I am on the active form fill in all the data. I have a command button that posts the entries. This populates TxtLocked with -1 then when you try to edit any field on either forms it will not allow you.

When I move to anew record that the field Txtlocked has -1

The Main form is locked but the subform is not can still edit?????


Any thoughts would be great

Thank Bob
 
Bob
Please use code tags in your posts to make it easier to read.
Can you see the error in line 4 of your code?

Also, use the code in the main form only
Did you try the suggestion I made instead? See post #3

If that still fails, try setting the subform control locked by default.
Then use code to set it unlocked when txtLocked is unhecked
 
Last edited:
Hi Micron

Regarding post #15, your explanation of using CurrentDb was what I meant but you explained it far better than I did.

As for the 'native to Access' comment, whilst using a Boolean variable would work, in this case I don't see any benefit in doing so when true/false will work just as well
 
Think cojones :D

However the variable name is slang for being told off/reprimanded in the UK.

Ok - it's a UK thing. I should have realized that camel case wouldn't cut me any slack - not that the word is in my vocab. Not even sure I know the UK meaning of it, but can guess now. :o

assigning the result of some thing = True or some thing = False to a variable isn't native but the test itself is? Not sure I'd agree with what I wrote being "non-native" to Access.

The CurrentDb thing is an entirely different matter. Put another way, each time you process a line such as Currentdb.Execute a copy of the current db is created and only persists until the command is processed. 5 of CurrentDb.something means 5 db copies created and destroyed (for lack of a better term).
Set db = CurrentDb means 1 copy persists until Set db = Nothing or the memory space is otherwise reclaimed.
 
I tend to use True and False, and I believe True is -1 or 1 and False = 0 ?

How about just using

Code:
Me.AllowEdits = NOT Me.txtLocked
Me.lblShiftClosed.Visible = Me.txtLocked
Me.FsubShiftBar.Form.AllowEdits = NOT Me.txtLocked
 

Users who are viewing this thread

Back
Top Bottom