problems with subforms on tab control

  • Thread starter Thread starter CristianTCDM
  • Start date Start date
C

CristianTCDM

Hello Everybody ,

I placed a subform on a tab control ; the subform has a query as
recordsource and I requery it using OnEnterEvent .
The problem is that I can't introduce data in textboxes or comboboxes on
that subform . Also I cannot use the scroll bars .
I checked the properties of subforms but I didn't find anything "suspect"

Thanks in advanced for anyone who can help .
 
suggest you start by checking the query underlying the subform. open the
query directly from the database window, and make sure the data is editable.
if not, there's your problem. if it is, then the RecordSource is okay in
itself, move on to checking the form.

there are a number of reasons you might not be able to enter/edit data via
the subform, but not being able to use the scroll bars sounds strange. do
you mean you can see them but clicking or dragging them has no effect? you
might check the Enabled property of the subform control *within the main
form*; it should be set to Yes. if you can't see the scroll bars at all,
open the subform itself in Design view and check the ScrollBars setting, it
should be set to Horizontal Only, Vertical Only, or Both.

for the add/edit data issue, i'd check the Locked property of the subform
control within the mainform first, it should be set to No. next, open the
subform in Design view again, and check the RecordsetType property - s/b
Dynaset. check the AllowAdditions and AllowEdits properties, both s/b Yes.
if all is well there, i'd next check those properties in the mainform as
well.

if you're still having no joy, suggest you post the relevant
tables/relationships, and the SQL of both the query underlying the subform,
and the RecordSource underlying the mainform, as well as the
LinkMasterFields and LinkChildFields properties of the subform control
within the mainform - maybe there's some referential integrity or
record-locking problem caused by the data setup within and/or between the
mainform and subform.

hth
 
The subform is a control of the main form

well, the subform is a form object, *held* in a "container" control within
the mainform. the subform object is not the container control, or vice
versa. think of the container control within the mainform as an embedded
window that displays the subform set by its' SourceObject property - much
like the screen-in-screen concept of television sets.
the "allow"
properties of a subform are ruled by how they are set on the main form
Click to expand...

actually, i found that to be *almost* completely incorrect. i testing my own
working database, in A97 (where it was built), and a copy converted to A2000
(and running in A2003). i found the behavior of the subforms, regarding the
topic we're discussing, to be identical in both versions.

the RecordsetType, AllowAdditions, and AllowDeletions properties worked
independently in the mainform and subform. The AllowEdits property worked
independently when it was set to Yes in the mainform and No in the subform,
*but* when set to No in the mainform, it prevented edits in the subform. i
suspect that's the case because setting the AllowEdits property to No seems
to have the same effect as setting all controls' Locked property to Yes -
and setting the container control's Locked property to Yes prevents changes
in the subform, regardless of AllowEdits/AllowAdditions settings in either
mainform or subform.

deleting a record in the mainform will cause a cascade delete of related
subform records, when CascadeDelete is enabled in the Relationships window -
and regardless of the AllowDeletions setting in the subform. and that makes
sense because the cascade delete is, i imagine, carried out via a Delete
query, which runs automatically and independently of the open form.

and, finally, the DataEntry setting works independently when it's set to No
in the mainform and Yes in the subform. i didn't test the reverse, because
my mainform subform data are properly related, so i couldn't add subform
records without an existing mainform record anyway. and i didn't want to
bother setting up a test using *unrelated* mainform/subform data, though i
suspect that when the data is not related, the setting will work
independently in each object.

hth
 
Actually , the scroll bars are visible but they are not "usable" .

I have more subforms placed on pages on a tab control some of them work ,
but some of them don't , in the same way : controls cannot be edited and
scroll bars and record navigator are "blocked" .
In fact they worked fine initially (I tested a combo with afterupdate event
) but suddenly they blocked .
I checked the main form and the subform properties as you suggested and
everything is OK : recordset - dynaset , allowadd , allowedit - yes , record
locking-no .

Any further help will be very appreciated

Thanks for your time
 
well, that sounds pretty strange. do you have some code running that
locks/unlocks controls on the form, at runtime? and for that matter, have
you checked the Locked property of the subform controls within the mainform?
and btw, what version of Access is this database?

hth
 
I use Access2007 , I don't have any code that locks/unlocks controls on the
form , the Locked property is set to No ewerywhere . I don,t know what btw is
..
I am sorry for this 'time gap' , but if you have any suggestion it would be
very appreciated
 
hmm, well, i'm stumped. i don't have A2007, and have never used it, so i
can't do what i'd usually do at this point, which is offer to look at a copy
of the db to see if i could find the problem. my only other suggestions are
to 1) check Name Autocorrect setting, if it's still available in A2007. if
it is, and if it's turned on, try creating a new blank db, turning the
option *off*, then importing all objects from the working db into the new
one. if that's not an option, or if doing the above doesn't work, then 2)
you might test for a corrupted mainform/subform. create a new "bare bones"
mainform, and a new bare bones subform - no code or fancy settings in either
one - then put the new sub into the new main as usual, and see if the sub
works. if so, start adding back settings/functionality slowly, testing as
you go, until you either encounter the problem or have a "good" setup.

btw means by the way. and i don't mind the time gap, if you don't. ;)

seriously, if you get no joy after trying the above option(s), i can only
suggest that you start a new thread in this newsgroup. in the first post,
state your version of Access, and give a synopsis of what was covered in
this thread, so you're not plowing old ground again. and you might include a
link to this thread, in case anyone helping you wants to read it - but don't
expect anyone to do that, in lieu of including a synopsis in the new thread.
sorry i couldn't be more help, and good luck with it. tina
 
Back
Top