Subform Acting Weird (again...)

[(PeteCresswell)]

Tabbed control with four subforms - one each tab.

When I have everything set to "Browse" mode (i.e. all controls in all subforms
locked), two of the subforms do not show on the screen.

As soon as I make all of the controls unlocked and set the subforms to be able
to add records, the forms appear in the two offending tabs - but they act like
there is nothing in their .RecordSource (i.e. they are positioned at the "New"
record). There is something in the .RecordSource and each form's .RecordSource
is pointing there.

One diff between these two tabs and the ones that seem to work is that each
subform is "Single" and not "Continuous".

I played around with "LinkChild"... but to no avail.

I've rebuilt this form from scratch twice because of other weirdnesses that I
suspect were introduced by a TreeView control on the same form - the weirdness
seems to start immediately after MS Access abends for some unknown reason.

Has anybody seen anything like this?

I *could* rebuild the form again - but I don't want to put something like this
into production until I have a handle on what's happening.

--
PeteCresswell

[Rich P]

With all due respect to Access, what I have notice from people who have
been coding in Access for a long time (5 or more years) the coding
becomes more sophisticated and it becomes harder to manage this code in
Access because Access is a fairly high level programming environment -
high level as in you can only tweak Access so much (as opposed to OOP
where you can tweak base procedures to your hearts content). It is kind
of like you can only manipulate a wizard so far. When it starts to act
in ways that you can't control - it is because you can't get down low
enough under the hood to do so. I guess for those people who must be
able to change the base behaviors of Access there is probably API code
(or for those people who are gurus of low level programming - can write
their own API code - but then you get into the Re-Inventing the wheel
syndrom - if a person is that good, they probably won't waste their
time).

I have been coding in Access for over 10 years now, and I have been
migrating more and more projects to the .Net environment because even
though the OOP learning curve is a little steeper than VBA, once you get
the hang of it, it is much easier to control stuff because you are at a
much lower level coding. Kind of like if you build a house with
pre-fabricated parts, you can only tweak those pre-fabricated parts so
much. If you can build the parts yourself, they are much easier to
customize.

So, on the subject of subforms, for the level of sophistication you are
describing, I would consider migrating to VB2005 and use a datagridview.
For example, to change datasources in a subform you must have
pre-existing fields for each datasource. In a datagridview (VB2005)
whatever you set the datasource to is how many columns/fields you are
going to get. In recent times I have had serious heartaches with
subform (against sql server tables).

So my suggestion is to look at the operation you are working on and
evaluate the tools you are using. For more sophisticated operations you
need more sophisticated tools.

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[(PeteCresswell)]

Per Rich P:

>I have been coding in Access for over 10 years now, and I have been
migrating more and more projects to the .Net environment because even
though the OOP learning curve is a little steeper than VBA, once you get
the hang of it

I've been flirting with the idea of going into .Net with the notion of creating
a template app that I can clone - but never seem to have found the time. However
it seems to me like I ought to get off my butt pretty soon and start working at
it.

What's your take on how many man hours it takes you do the same app in .Net vs
MS Access?
--
PeteCresswell

[(PeteCresswell)]

Per (PeteCresswell):

>I played around with "LinkChild"... but to no avail.

Now it seems tb something with LinkChild/Master.

In VBA, I set both to "", and one of the forms started working.

Poking and prodding, it looks like they weren't seeing any records in the
..RecordSource - even though there were.

The other form still wouldn't work. Then I just imported the work table it was
pointed to, and set it's .RecordSource to that table within the app... then it
worked. Then I changed it back to pointing to the work table, kept clearing
..LinkChild/MasterFields, and the Fushlurggener thing started working again.

I'm *really* running scared on this one.... maybe it'll be the one that pushes
me over to .NET... -)
--
PeteCresswell

[Tom van Stiphout]

On Mon, 17 Jul 2006 16:32:11 -0400, "(PeteCresswell)" <[e-mail]>
wrote:

In my mind it's difficult to compare. Depends on the complexity of the
app. The complexer the app, the less obvious Access' benefits are. If
you have to write 50 kloc to get things done, the benefit may be
minimal or negative. But if you can slap-slap an application together
using wizards, parent-child forms with all bound controls, using a lot
of Access' built-in strengths, then no .Net developer will be able to
beat you.

-Tom.

>Per Rich P:

>>I have been coding in Access for over 10 years now, and I have been
migrating more and more projects to the .Net environment because even
though the OOP learning curve is a little steeper than VBA, once you get
the hang of it

I've been flirting with the idea of going into .Net with the notion of creating
a template app that I can clone - but never seem to have found the time. However
it seems to me like I ought to get off my butt pretty soon and start working at
it.

What's your take on how many man hours it takes you do the same app in .Net vs
MS Access?

[David W. Fenton]

"(PeteCresswell)" <[e-mail] in
news:2r********************************@4ax.com:

The other form still wouldn't work. Then I just imported the
work table it was pointed to, and set it's .RecordSource to that
table within the app... then it worked. Then I changed it back
to pointing to the work table, kept clearing
.LinkChild/MasterFields, and the Fushlurggener thing started
working again.

When you change the recordsource of a parent form with a subform,
you have to reset the link fields on the child form. When you change
the form object embedded in the child form control, you have to
reset the link fields.

This is the way Access linked forms have always worked.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/