why NO - "OnChange" for a "Check Box" ?!?!?!?

  • Thread starter Thread starter bobg
  • Start date Start date
B

bobg

running access 2k;

I would like a field to become visible when the check box infront of
it is true, and not visible when the checkbox is false.

WHY is there NO "onchange" available for a check box?!?!?!?!

How am I supposed to make this work without onchange????

Why does every other type of "box" have onchange, but not Check???

tia - REALLY confused w/ ms's [lack] of logic/consistancy.
 
Because you want to use the AfterUpdate event of the checkbox (which all
controls whose values can be edited have).
 
Change Event (for a TextBox / ComboBox happens on every character you type
in. For CheckBox you either set to True or False only.

For CheckBox, we mainly use the BeforeUpdate or AfterUpdate Event.
 
Van T. Dinh said:
Change Event (for a TextBox / ComboBox happens on every character you type
in. For CheckBox you either set to True or False only.

For CheckBox, we mainly use the BeforeUpdate or AfterUpdate Event.

--
HTH
Van T. Dinh
MVP (Access)


bobg said:
running access 2k;

I would like a field to become visible when the check box infront of
it is true, and not visible when the checkbox is false.

WHY is there NO "onchange" available for a check box?!?!?!?!

How am I supposed to make this work without onchange????

Why does every other type of "box" have onchange, but not Check???

tia - REALLY confused w/ ms's [lack] of logic/consistancy.
Click to expand...
Click to expand...

many thanks to both Ken & Van;

I appreciate your assistance.

I'm still confused with ms's logic on how this works... Mostly
because:

afterupdate DOES do what I want - BUT I ALSO have to use an
oncurrent sub, to update visibility as the records are scrolled
thru....

IF onchanged worked for checkmarks - I wouldn't need 2 complete
copies of [redundant] code.

yes, I realize in the big pic, we're not talking about alot of code -
but it just seems unnecessarily redundant. It seems to fly in the face
of pure logic.... I guess I should just learn to accept this from ms
:)

I'm sure someone in the marketing dept had a reason for this!! ;-)

tx again !
Bob
 
Even if the Change Event exists, it means (data) changes *performed by the
user* through the interface and not changes because the users move from one
Record to another. Thus you still need to use the Current Event when the
user moves from one Record to another ...
 
I see----

ok - I'll buy that.
Van - tx again VERY much for your help!!!
Bob

Van T. Dinh said:
Even if the Change Event exists, it means (data) changes *performed by the
user* through the interface and not changes because the users move from one
Record to another. Thus you still need to use the Current Event when the
user moves from one Record to another ...

--
HTH
Van T. Dinh
MVP (Access)


bobg said:
many thanks to both Ken & Van;

I appreciate your assistance.

I'm still confused with ms's logic on how this works... Mostly
because:

afterupdate DOES do what I want - BUT I ALSO have to use an
oncurrent sub, to update visibility as the records are scrolled
thru....

IF onchanged worked for checkmarks - I wouldn't need 2 complete
copies of [redundant] code.

yes, I realize in the big pic, we're not talking about alot of code -
but it just seems unnecessarily redundant. It seems to fly in the face
of pure logic.... I guess I should just learn to accept this from ms
:)

I'm sure someone in the marketing dept had a reason for this!! ;-)

tx again !
Bob
Click to expand...
Click to expand...
 
Back
Top