Derived control - how to keep frozen during record edits?

Hello. I'm designing a form to be used for both editing existing records
and adding new ones. A textbox will contain a string derived from three
other (bound & in same table) controls. (It will be a catalog id; I don't
want to construct it on the fly. I want it in the table.)

After a new record is entered, I don't want the string to be altered by
subsequent edits of the fields from which it is derived. Is there a
preferred way to do this? My current plan is to trigger the string
construction in a routine called from each of the (progenitor) control
afterupdate methods, but only if the NewRecord property is true. Sound ok?

Many thanks, Ron

Hi ,

Why not put code in the Forms beforeupdate event; test that the three
feeding fields are filled in
and update the 4th (derived) field only if it is null?

Regards

Kevin


"Ron" wrote in message
...
Hello. I'm designing a form to be used for both editing existing records
and adding new ones. A textbox will contain a string derived from three
other (bound & in same table) controls. (It will be a catalog id; I don't
want to construct it on the fly. I want it in the table.)

After a new record is entered, I don't want the string to be altered by
subsequent edits of the fields from which it is derived. Is there a
preferred way to do this? My current plan is to trigger the string
construction in a routine called from each of the (progenitor) control
afterupdate methods, but only if the NewRecord property is true. Sound
ok?

Many thanks, Ron

Hi Kevin, thanks. The form update occurs only when the user *leaves* the
current record, no? I wanted the user to see the derived control value
appear as soon as all progenitor controls were filled, and then see it
change if they were edited again, but only for a new record - ie. before
moving to an old (or another new) record. The NZ test sounds like it'll fit
in there somewhere. Thx for reminding me about it.

I gotta learn event firing sequence.

I mean in my bones. ;-)

Thanks again, Ron

Why not put code in the Forms beforeupdate event; test that the three
feeding fields are filled in
and update the 4th (derived) field only if it is null?

Regards

Kevin


"Ron" wrote in message
...
Hello. I'm designing a form to be used for both editing existing records
and adding new ones. A textbox will contain a string derived from three
other (bound & in same table) controls. (It will be a catalog id; I
don't want to construct it on the fly. I want it in the table.)

After a new record is entered, I don't want the string to be altered by
subsequent edits of the fields from which it is derived. Is there a
preferred way to do this? My current plan is to trigger the string
construction in a routine called from each of the (progenitor) control
afterupdate methods, but only if the NewRecord property is true. Sound
ok?

Many thanks, Ron

Ron,
There may be several ways to do that.
I'd make all three "progenitor" controls disabled, and use
the OnCurrent event of the form to run a function called
something like ExamineControls...
Fld1.Enabled = Fld1 = Null
Fld2.Enabled = Fld2 = Null
etc...
Then. use the AfterUpdate event of each to concatenate
what values you have, and... ExamineControls again.
That way, you could return to an existing record, and
perhaps fill in the 3rd value that was missing, as well as handle
New records.
Might need some tweaking here and therem but it should
be do-able.
--
hth
Al Campagna
Microsoft Access MVP 2006-2009
http://home.comcast.net/~cccsolutions/index.html

"Find a job that you love... and you'll never work a day in your life."

"Ron" wrote in message
...
Hi Kevin, thanks. The form update occurs only when the user *leaves* the
current record, no? I wanted the user to see the derived control value
appear as soon as all progenitor controls were filled, and then see it
change if they were edited again, but only for a new record - ie. before
moving to an old (or another new) record. The NZ test sounds like it'll
fit in there somewhere. Thx for reminding me about it.

I gotta learn event firing sequence.

I mean in my bones. ;-)

Thanks again, Ron

Why not put code in the Forms beforeupdate event; test that the three
feeding fields are filled in
and update the 4th (derived) field only if it is null?

Regards

Kevin


"Ron" wrote in message
...
Hello. I'm designing a form to be used for both editing existing
records and adding new ones. A textbox will contain a string derived
from three other (bound & in same table) controls. (It will be a
catalog id; I don't want to construct it on the fly. I want it in the
table.)

After a new record is entered, I don't want the string to be altered by
subsequent edits of the fields from which it is derived. Is there a
preferred way to do this? My current plan is to trigger the string
construction in a routine called from each of the (progenitor) control
afterupdate methods, but only if the NewRecord property is true. Sound
ok?

Many thanks, Ron

Al thank you. I never intended to allow a new record to be entered unless
all progenitor controls, and the concatenated derived control, are entered -
and I'll probably have data validation on them - so I don't think the kind
of check you suggest is needed for existing records. I'll consider your
approach for "new record" mode, though I do want the user to be able to
change the progenitor controls before entering the record. (BTW, I love the
technique of setting a "two-way switch" - ie. an enabled/disabled property -
in an assignment statement the right side of which itself is a boolean
assignment. Appeals to my efficiency sensibility. Way cool. (You can tell
I'm a novice, right?))

First Access project, but some prior VFP experience at hobby level. Gotta
love the ability to use OOP principles without writing class code ;-) But
guess I should stop speculating and just try some event code. Thanks for
the suggestions, Ron

"Al Campagna" wrote in message
...
Ron,
There may be several ways to do that.
I'd make all three "progenitor" controls disabled, and use
the OnCurrent event of the form to run a function called
something like ExamineControls...
Fld1.Enabled = Fld1 = Null
Fld2.Enabled = Fld2 = Null
etc...
Then. use the AfterUpdate event of each to concatenate
what values you have, and... ExamineControls again.
That way, you could return to an existing record, and
perhaps fill in the 3rd value that was missing, as well as handle
New records.
Might need some tweaking here and therem but it should
be do-able.
--
hth
Al Campagna
Microsoft Access MVP 2006-2009
http://home.comcast.net/~cccsolutions/index.html

"Find a job that you love... and you'll never work a day in your life."

"Ron" wrote in message
...
Hi Kevin, thanks. The form update occurs only when the user *leaves* the
current record, no? I wanted the user to see the derived control value
appear as soon as all progenitor controls were filled, and then see it
change if they were edited again, but only for a new record - ie. before
moving to an old (or another new) record. The NZ test sounds like it'll
fit in there somewhere. Thx for reminding me about it.

I gotta learn event firing sequence.

I mean in my bones. ;-)

Thanks again, Ron

Why not put code in the Forms beforeupdate event; test that the three
feeding fields are filled in
and update the 4th (derived) field only if it is null?

Regards

Kevin


"Ron" wrote in message
...
Hello. I'm designing a form to be used for both editing existing
records and adding new ones. A textbox will contain a string derived
from three other (bound & in same table) controls. (It will be a
catalog id; I don't want to construct it on the fly. I want it in the
table.)

After a new record is entered, I don't want the string to be altered by
subsequent edits of the fields from which it is derived. Is there a
preferred way to do this? My current plan is to trigger the string
construction in a routine called from each of the (progenitor) control
afterupdate methods, but only if the NewRecord property is true. Sound
ok?

Many thanks, Ron

On Sun, 10 Jan 2010 09:39:27 -0500, "Al Campagna"
wrote:

Ron,
There may be several ways to do that.
I'd make all three "progenitor" controls disabled, and use
the OnCurrent event of the form to run a function called
something like ExamineControls...
Fld1.Enabled = Fld1 = Null
Fld2.Enabled = Fld2 = Null

Al, shouldn't that be

Fld1.Enabled = IsNull(Fld1)

since nothing is ever equal to NULL (not even NULL itself)?
--

John W. Vinson [MVP]

You're right John...
My mistake. Maybe I need a break for a while...
Thanks
Al

"John W. Vinson" wrote in message
...
On Sun, 10 Jan 2010 09:39:27 -0500, "Al Campagna"
wrote:

Ron,
There may be several ways to do that.
I'd make all three "progenitor" controls disabled, and use
the OnCurrent event of the form to run a function called
something like ExamineControls...
Fld1.Enabled = Fld1 = Null
Fld2.Enabled = Fld2 = Null

Al, shouldn't that be

Fld1.Enabled = IsNull(Fld1)

since nothing is ever equal to NULL (not even NULL itself)?
--

John W. Vinson [MVP]