Making a control with #Name? not visible

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

How do I determine if a control is displaying "#name?" ?

My front end needs to "turn off" any control that has an invalid control
source, but I can't seem to test an invalid control source until I try to use
the control.

I'd like to test each control in the OnOpen event, and if a bad control
source is detected, then make the field invisible.

I think I just solved my problem....

-- psuedocode start --

on error goto Error_Handler

for each control on the form
debug.print the .value
next

Error_Handler:

If Error 2432 then disable that control; resume
otherwise error report and exit

-- psuedocode end --


I think this will work. Other suggestions welcome.
 
David said:
How do I determine if a control is displaying "#name?" ?

My front end needs to "turn off" any control that has an invalid control
source, but I can't seem to test an invalid control source until I try to use
the control.

I'd like to test each control in the OnOpen event, and if a bad control
source is detected, then make the field invisible.

I think I just solved my problem....

-- psuedocode start --

on error goto Error_Handler

for each control on the form
debug.print the .value
next

Error_Handler:

If Error 2432 then disable that control; resume
otherwise error report and exit

-- psuedocode end --


I think this will work. Other suggestions welcome.
Click to expand...


That will probably work, but if not check the value for
"#Name".

I really have to wonder how can arrive at a situation where
you do not know the fields in the form's record source. Are
you letting users select any old data table/query and
assigning that as the record source? Sounds strange to me.
Maybe they are linking to some uncontrolled spreadsheets,
which implies to me that you need to establish more control
over the situation.
 
It's a version control nightmare. I'm all ears to improve this. I'll try
to be brief...

1. I'm working with pension plan valuations. Each plan varies from the next.

2. There is a single data model that will account for every pension plan
variation, but not all plans require every data element in the data model.

3. Each pension plan valuation starts by getting a copy of the "master"
back end MDB, which holds the entire data model.

4. Any front end MDB can attach (on-the-fly relinl) to any back end

5. Updates to the "master" data model are not promulgated to existing
pension plan valuation back end MDBs - unless the change is required to
complete the valuation.

6. We're trying to avoid (too much time and talent) involved with
customizing each front/back end. We've been doing this, and it's not working
very well. There is still customization involved, but the front end allows
most anyone to make the customizations quick and easy - not much talent
involved.
 
David said:
It's a version control nightmare. I'm all ears to improve this. I'll try
to be brief...

1. I'm working with pension plan valuations. Each plan varies from the next.

2. There is a single data model that will account for every pension plan
variation, but not all plans require every data element in the data model.

3. Each pension plan valuation starts by getting a copy of the "master"
back end MDB, which holds the entire data model.

4. Any front end MDB can attach (on-the-fly relinl) to any back end

5. Updates to the "master" data model are not promulgated to existing
pension plan valuation back end MDBs - unless the change is required to
complete the valuation.

6. We're trying to avoid (too much time and talent) involved with
customizing each front/back end. We've been doing this, and it's not working
very well. There is still customization involved, but the front end allows
most anyone to make the customizations quick and easy - not much talent
involved.
Click to expand...


Arrrgghh, I hope you're well paid for this mind numbing
aggravation ;-)

You may want to think about creating a query for each of the
back ends that aliases the field anmes to your "standard"
internal names. The queries can also supply default values
or Null for any missing data. This way the reports, forms,
etc. would not have to be concerned with these issues. The
one drawback is that you can not allow users to arbitrarily
link to any old mdb file. Instead they would only be
allowed to select from a list of the ones you support.
OTOH, adding a new one wouldn't require much more that
creating a new query.
 
Back
Top