Subform Madness

  • Thread starter Thread starter John S
  • Start date Start date
J

John S

Back again (can't stay away)

I was having a problem clearing a subform, which I have resolved by the
revelation that a subform is NOT a part of the forms collection, rather it
is a control on a form. But this control also has controls that can be
referenced. For example, I reference (to clear) my subform controls from
the main form thus:

[sfPet].Form.txt2003.Value = ""

Is is possible to cycle through all the subform controls, or must I
reference each by actual control name?

Second question / observation. After clearing each subform control, I wanted
to return to the first field in the main form. Didn't work: always tried to
go to the first field in the subform. On a pure hunch, I tried first
returning the focus to the main form, and then setting the focus on the
first field in the main form. Worked! Any idea why?

Perpetually Intrigued

J. Smith
Aylmer, PQ
 
John S said:
Back again (can't stay away)

I was having a problem clearing a subform, which I have resolved by
the revelation that a subform is NOT a part of the forms collection,
rather it is a control on a form. But this control also has controls
that can be referenced. For example, I reference (to clear) my
subform controls from the main form thus:

[sfPet].Form.txt2003.Value = ""

Is is possible to cycle through all the subform controls, or must I
reference each by actual control name?
Click to expand...

Sure, though (a) you have to limit your efforts to those controls
that have a Value property (excluding, e.g., labels, lines, etc.) and
(b) you would be safer to use Null rather than "", since controls that
are bound to number fields can't be set to "". Here's a quick example:

Dim ctl As Access.Control

For each ctl in Me!sfPet.Form.Controls
With ctl
Select Case .ControlType
Case acTextBox, acComboBox, acCheckBox
.Value = Null
Case acListbox
If .MultiSelect = 0 Then
.Value = Null
End If
Case Else
' do nothing
End Select
End With
Next ctl

A somewhat sloppy alternative to this approach is to just set the Value
property to Null for all controls without checking the type first, but
ignore the error that will be raised whenever there is no Value
property. And in fact you really should use error-handling logic
anyway, to catch those cases where the control's value can't be set
because it's bound to a read-only or auto-number field.
Second question / observation. After clearing each subform control, I
wanted to return to the first field in the main form. Didn't work:
always tried to go to the first field in the subform. On a pure
hunch, I tried first returning the focus to the main form, and then
setting the focus on the first field in the main form. Worked! Any
idea why?
Click to expand...

I'd have to see the code you were executing to return to the main form's
first field. You shouldn't have to set the focus to the parent first;
for example, this code, executed on the subform, should work to set the
focus to the field "ID" on the main form:

Me.Parent!ID.SetFocus

So you must have been doing something different. Interestingly, setting
the focus from the main form to a control on the subform *does* require
a two-step process: first setfocus to the subform, then setfocus to the
control on the subform. But that should not be necessary going upward,
rather than downward.
Perpetually Intrigued
Click to expand...

It's a good way top be.
 
Hi Dirk,

,As for setting focus to the form, and then the form control, I did this
after clearing subform fields one by one with "[sfPet].Form.txt2003.Value =
""", etc. Actually, your second comment answered the focus question: it
was the curse of trying to place a "" into a textbox attached to a numeric
field. When I changed the value to null, I was able to reset the focus
directly.

Thanks for the code snippet. Strange thinking about a control that is a form
on a form. And "just in time" (or a little late)learning continues: I
didn't realize you could set a value to null (i.e.. txt2003.value = null). I
don't know if you can in java (i.e.. set a value to null); there is a
logical contradiction: null is not a value. I've seen the problem you
mentioned about trying to place a "" into a number field, and in general I
resolved it by placing a 0 in the field. Never dawned on me to use null.

You can read the books, but it only sinks in when you have to apply it

Thanks again

John S
Aylmer, PQ.


Dirk Goldgar said:
John S said:
Back again (can't stay away)

I was having a problem clearing a subform, which I have resolved by
the revelation that a subform is NOT a part of the forms collection,
rather it is a control on a form. But this control also has controls
that can be referenced. For example, I reference (to clear) my
subform controls from the main form thus:

[sfPet].Form.txt2003.Value = ""

Is is possible to cycle through all the subform controls, or must I
reference each by actual control name?
Click to expand...

Sure, though (a) you have to limit your efforts to those controls
that have a Value property (excluding, e.g., labels, lines, etc.) and
(b) you would be safer to use Null rather than "", since controls that
are bound to number fields can't be set to "". Here's a quick example:

Dim ctl As Access.Control

For each ctl in Me!sfPet.Form.Controls
With ctl
Select Case .ControlType
Case acTextBox, acComboBox, acCheckBox
.Value = Null
Case acListbox
If .MultiSelect = 0 Then
.Value = Null
End If
Case Else
' do nothing
End Select
End With
Next ctl

A somewhat sloppy alternative to this approach is to just set the Value
property to Null for all controls without checking the type first, but
ignore the error that will be raised whenever there is no Value
property. And in fact you really should use error-handling logic
anyway, to catch those cases where the control's value can't be set
because it's bound to a read-only or auto-number field.
Second question / observation. After clearing each subform control, I
wanted to return to the first field in the main form. Didn't work:
always tried to go to the first field in the subform. On a pure
hunch, I tried first returning the focus to the main form, and then
setting the focus on the first field in the main form. Worked! Any
idea why?
Click to expand...

I'd have to see the code you were executing to return to the main form's
first field. You shouldn't have to set the focus to the parent first;
for example, this code, executed on the subform, should work to set the
focus to the field "ID" on the main form:

Me.Parent!ID.SetFocus

So you must have been doing something different. Interestingly, setting
the focus from the main form to a control on the subform *does* require
a two-step process: first setfocus to the subform, then setfocus to the
control on the subform. But that should not be necessary going upward,
rather than downward.
Perpetually Intrigued
Click to expand...

It's a good way top be.
J. Smith
Aylmer, PQ
Click to expand...

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)
Click to expand...
 
Back
Top