toggle button nightmare

J

johnlute

I use Access 2003. This problem is relative to a continuous form.

I have a subform with toggle buttons. The concept is to click them
when their associated attributes are considered "critical". For
example, I have a field called [IDLength]. It has an "associated"
field called [IDLCritical] which is used to capture the toggle
button's value.

I want the toggle button to be enabled only IF there's a value in
[IDLength] so I devised this AfterUpdate Event:
Private Sub IDLength_AfterUpdate()
Me.tglIDLCritical.Enabled = IsNull(Me.IDLength = True)
Me.tglIDLCritical.Enabled = False = IsNull(Me.IDLength = False)
End Sub

The toggle button's Control Source is [IDLCritical] and here's its
Click Event:

Private Sub tglIDLCritical_Click()
If tglIDLCritical.Value = -1 Then
Me.tglIDLCritical.ForeColor = vbRed
Me.tglIDLCritical.Caption = "YES!"
Me.lblIDL.ForeColor = vbRed
End If
If tglIDLCritical.Value = 0 Then
Me.tglIDLCritical.ForeColor = vbBlack
Me.tglIDLCritical.Caption = "No"
Me.lblIDL.ForeColor = vbBlack
End If
End Sub

All of this works perfectly *when I have the subform opened
independently of its parent form* however when I add it to its parent
form and then open the parent form - it pukes. What happens is that
the toggle buttons are all disabled and only become enabled after I
edit the values in their associated fields. I suppose this makes sense
as they're enabled/disabled according to AfterUpdate Events HOWEVER
why does it all work when the subform's opened independently of the
parent form?

Also, with the parent form opened I will update the value in
[IDLength] for example, and its toggle button will become enabled -
what I want - however if I click the toggle button and then navigate
form the parent record then the toggle button stays depressed! This
does NOT occur with the subform opened independently of the parent
form.

Does anyone have any ideas what I've done wrong?

Thanks for your time and consideration!
 
J

Jeff Boyce

Not sure if this is germane, but the controls embedded in a form need to be
referred to differently than the controls embedded in a form which is itself
embedded in another form (i.e., a "subform").

Something like "Me!IDLength" that works when you are only opening the form
directly would be an incomplete reference if you were referring to the
control "IDLength" that lives in form "XXXXX", which is embedded in form
"YYYYY".

Check on:

Forms!YourFormName!YourSubformControlName.Form!IDLength

By the way, the use of "." in something like "Me.Requery" may be handled by
Access differently than the use of "!" in "Me!IDLength". The bang ("!")
refers to user-defined objects, where the dot (".") refers to Access'
built-ins, like Methods.

Yes, in some versions, in some situations, you can get away with referring
to a control you've added in a form with Me.IDLength ... but I've noticed
that more recent versions of Access are more particular about the above
distinction.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

johnlute said:
I use Access 2003. This problem is relative to a continuous form.

I have a subform with toggle buttons. The concept is to click them
when their associated attributes are considered "critical". For
example, I have a field called [IDLength]. It has an "associated"
field called [IDLCritical] which is used to capture the toggle
button's value.

I want the toggle button to be enabled only IF there's a value in
[IDLength] so I devised this AfterUpdate Event:
Private Sub IDLength_AfterUpdate()
Me.tglIDLCritical.Enabled = IsNull(Me.IDLength = True)
Me.tglIDLCritical.Enabled = False = IsNull(Me.IDLength = False)
End Sub

The toggle button's Control Source is [IDLCritical] and here's its
Click Event:

Private Sub tglIDLCritical_Click()
If tglIDLCritical.Value = -1 Then
Me.tglIDLCritical.ForeColor = vbRed
Me.tglIDLCritical.Caption = "YES!"
Me.lblIDL.ForeColor = vbRed
End If
If tglIDLCritical.Value = 0 Then
Me.tglIDLCritical.ForeColor = vbBlack
Me.tglIDLCritical.Caption = "No"
Me.lblIDL.ForeColor = vbBlack
End If
End Sub

All of this works perfectly *when I have the subform opened
independently of its parent form* however when I add it to its parent
form and then open the parent form - it pukes. What happens is that
the toggle buttons are all disabled and only become enabled after I
edit the values in their associated fields. I suppose this makes sense
as they're enabled/disabled according to AfterUpdate Events HOWEVER
why does it all work when the subform's opened independently of the
parent form?

Also, with the parent form opened I will update the value in
[IDLength] for example, and its toggle button will become enabled -
what I want - however if I click the toggle button and then navigate
form the parent record then the toggle button stays depressed! This
does NOT occur with the subform opened independently of the parent
form.

Does anyone have any ideas what I've done wrong?

Thanks for your time and consideration!
 
J

johnlute

Hi, Jeff!

Thanks for the response. I was hoping that you were wrong because I
would be faced with LOTS of editing! As it turns out you weren't wrong
but you may be right. Ultimately, I made a major oversight.

The subform that was giving me trouble was a copy of another more
complicated subform that I use as a template. In this instance, I
removed several controls from the copy BUT NEGLECTED TO REMOVE THEIR
EVENTS! I realized this after I wrote some lines according to your
suggestion. I ran the debugger and BOINK! "NOT FOUND". So I deleted
all of the "rogue" events and BINGO! I opened the parent form and the
subform behaved like a good son.

WHEW! I'm so glad you were wrong! However you may be right about your
other comments. In my configuration there's no issues but to your
point - that may not be the case with other configurations. Come to
think of it - I vaguely recall running into the (.) vs. (!) issue
before and had to use one or the other when I thought that I was using
the "right" one!

Thanks for your time and thoughts!

Not sure if this is germane, but the controls embedded in a form need to be
referred to differently than the controls embedded in a form which is itself
embedded in another form (i.e., a "subform").

Something like "Me!IDLength" that works when you are only opening the form
directly would be an incomplete reference if you were referring to the
control "IDLength" that lives in form "XXXXX", which is embedded in form
"YYYYY".

Check on:

    Forms!YourFormName!YourSubformControlName.Form!IDLength

By the way, the use of "." in something like "Me.Requery" may be handled by
Access differently than the use of "!" in "Me!IDLength".  The bang ("!")
refers to user-defined objects, where the dot (".") refers to Access'
built-ins, like Methods.

Yes, in some versions, in some situations, you can get away with referring
to a control you've added in a form with Me.IDLength ... but I've noticed
that more recent versions of Access are more particular about the above
distinction.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.




I use Access 2003. This problem is relative to a continuous form.
I have a subform with toggle buttons. The concept is to click them
when their associated attributes are considered "critical". For
example, I have a field called [IDLength]. It has an "associated"
field called [IDLCritical] which is used to capture the toggle
button's value.
I want the toggle button to be enabled only IF there's a value in
[IDLength] so I devised this AfterUpdate Event:
Private Sub IDLength_AfterUpdate()
   Me.tglIDLCritical.Enabled = IsNull(Me.IDLength = True)
   Me.tglIDLCritical.Enabled = False = IsNull(Me.IDLength = False)
End Sub
The toggle button's Control Source is [IDLCritical] and here's its
Click Event:
Private Sub tglIDLCritical_Click()
   If tglIDLCritical.Value = -1 Then
       Me.tglIDLCritical.ForeColor = vbRed
       Me.tglIDLCritical.Caption = "YES!"
       Me.lblIDL.ForeColor = vbRed
   End If
   If tglIDLCritical.Value = 0 Then
       Me.tglIDLCritical.ForeColor = vbBlack
       Me.tglIDLCritical.Caption = "No"
       Me.lblIDL.ForeColor = vbBlack
   End If
End Sub
All of this works perfectly *when I have the subform opened
independently of its parent form* however when I add it to its parent
form and then open the parent form - it pukes. What happens is that
the toggle buttons are all disabled and only become enabled after I
edit the values in their associated fields. I suppose this makes sense
as they're enabled/disabled according to AfterUpdate Events HOWEVER
why does it all work when the subform's opened independently of the
parent form?
Also, with the parent form opened I will update the value in
[IDLength] for example, and its toggle button will become enabled -
what I want - however if I click the toggle button and then navigate
form the parent record then the toggle button stays depressed! This
does NOT occur with the subform opened independently of the parent
form.
Does anyone have any ideas what I've done wrong?
Thanks for your time and consideration!- Hide quoted text -

- Show quoted text -
 
J

Jeff Boyce

Glad you got it working...

Yup, the "!" v. "." doesn't show up everywhere, every time ... don't that
just make it harder to diagnose!

Jeff B.

Hi, Jeff!

Thanks for the response. I was hoping that you were wrong because I
would be faced with LOTS of editing! As it turns out you weren't wrong
but you may be right. Ultimately, I made a major oversight.

The subform that was giving me trouble was a copy of another more
complicated subform that I use as a template. In this instance, I
removed several controls from the copy BUT NEGLECTED TO REMOVE THEIR
EVENTS! I realized this after I wrote some lines according to your
suggestion. I ran the debugger and BOINK! "NOT FOUND". So I deleted
all of the "rogue" events and BINGO! I opened the parent form and the
subform behaved like a good son.

WHEW! I'm so glad you were wrong! However you may be right about your
other comments. In my configuration there's no issues but to your
point - that may not be the case with other configurations. Come to
think of it - I vaguely recall running into the (.) vs. (!) issue
before and had to use one or the other when I thought that I was using
the "right" one!

Thanks for your time and thoughts!

Not sure if this is germane, but the controls embedded in a form need to
be
referred to differently than the controls embedded in a form which is
itself
embedded in another form (i.e., a "subform").

Something like "Me!IDLength" that works when you are only opening the form
directly would be an incomplete reference if you were referring to the
control "IDLength" that lives in form "XXXXX", which is embedded in form
"YYYYY".

Check on:

Forms!YourFormName!YourSubformControlName.Form!IDLength

By the way, the use of "." in something like "Me.Requery" may be handled
by
Access differently than the use of "!" in "Me!IDLength". The bang ("!")
refers to user-defined objects, where the dot (".") refers to Access'
built-ins, like Methods.

Yes, in some versions, in some situations, you can get away with referring
to a control you've added in a form with Me.IDLength ... but I've noticed
that more recent versions of Access are more particular about the above
distinction.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.




I use Access 2003. This problem is relative to a continuous form.
I have a subform with toggle buttons. The concept is to click them
when their associated attributes are considered "critical". For
example, I have a field called [IDLength]. It has an "associated"
field called [IDLCritical] which is used to capture the toggle
button's value.
I want the toggle button to be enabled only IF there's a value in
[IDLength] so I devised this AfterUpdate Event:
Private Sub IDLength_AfterUpdate()
Me.tglIDLCritical.Enabled = IsNull(Me.IDLength = True)
Me.tglIDLCritical.Enabled = False = IsNull(Me.IDLength = False)
End Sub
The toggle button's Control Source is [IDLCritical] and here's its
Click Event:
Private Sub tglIDLCritical_Click()
If tglIDLCritical.Value = -1 Then
Me.tglIDLCritical.ForeColor = vbRed
Me.tglIDLCritical.Caption = "YES!"
Me.lblIDL.ForeColor = vbRed
End If
If tglIDLCritical.Value = 0 Then
Me.tglIDLCritical.ForeColor = vbBlack
Me.tglIDLCritical.Caption = "No"
Me.lblIDL.ForeColor = vbBlack
End If
End Sub
All of this works perfectly *when I have the subform opened
independently of its parent form* however when I add it to its parent
form and then open the parent form - it pukes. What happens is that
the toggle buttons are all disabled and only become enabled after I
edit the values in their associated fields. I suppose this makes sense
as they're enabled/disabled according to AfterUpdate Events HOWEVER
why does it all work when the subform's opened independently of the
parent form?
Also, with the parent form opened I will update the value in
[IDLength] for example, and its toggle button will become enabled -
what I want - however if I click the toggle button and then navigate
form the parent record then the toggle button stays depressed! This
does NOT occur with the subform opened independently of the parent
form.
Does anyone have any ideas what I've done wrong?
Thanks for your time and consideration!- Hide quoted text -

- Show quoted text -
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top