Dealing with two instances of the same form

[Amy Blankenship]

I have the following situation:

I have a form structure where in one place it is necessary to reverse the
LinkMaster>LinkChild relationship. In other words, the parent form contains
the foreign key, and the child form contains the primary key. What this
means is that when a new record is created in the child form it doesn't pass
its ID back up to the parent form, because Access expects the data to flow
the other direction. However, once the record exists, it can be edited just
fine.

So I've arrived at a sort of wonky solution to get around this problem. I
have code in the current event that checks to see if there is a value in the
FK ID field. If not, it hides the subform and shows a button. That button
just launches the same subform as a dialogue and captures the new ID on
return. The standard way you do this is to cancel the close event of the
dialogue form and then actually close the form in the procedure that calls
the dialogue form. The problem I have is that the form actually is open
twice, once invisibly as a subform and once visibly standalone.

How do I distinguish in code WHICH version of the form I'm referring to.

TIA;

Amy

 

[John Nurick]

Hi Amy,

This doesn't cover your exact situation, but explains how to handle
multiple instances of a form: http://www.allenbrowne.com/ser-35.html

But from this and what I've seen in other threads I get the impression
that for this subform you should forget about linking master and child
fields. Instead use the subform control just to hold the subform, not to
link it to the "parent" - which isn't a parent so much as a container.

Put code in the subform's Current event that moves the containing form
to the related record (if it's a 1:1 relationship between subform and
containing form) or filters its recordsource to display only related
records (if 1:M). And maybe also put code in the containing form's
Current event to display what you want in the subform.

On the other hand (a) I don't understand your data structure and (b) I'm
still don't know what your "RTF" entity is (I do know what Rich Text
Format is and what a RTF control is), so this message may not be worth
reading<g>.

 

[Amy Blankenship]

Hi Amy,

This doesn't cover your exact situation, but explains how to handle
multiple instances of a form: http://www.allenbrowne.com/ser-35.html

But from this and what I've seen in other threads I get the impression
that for this subform you should forget about linking master and child
fields. Instead use the subform control just to hold the subform, not to
link it to the "parent" - which isn't a parent so much as a container.

Yes, I did a google.groups search and came up with something similar to
that. I'm not really sure how you "clear" the linkmaster/linkchild fields.
Would it work to just delete it?

Put code in the subform's Current event that moves the containing form
to the related record (if it's a 1:1 relationship between subform and
containing form) or filters its recordsource to display only related
records (if 1:M). And maybe also put code in the containing form's
Current event to display what you want in the subform.

That doesn't handle insertion of a new record. However, an OnAfterInsert
event might work to store the ID in the container. That's what I'm doing
now, with the popup. Might be cleaner than what I have now, though what I
have now works.

On the other hand (a) I don't understand your data structure and (b) I'm
still don't know what your "RTF" entity is (I do know what Rich Text
Format is and what a RTF control is), so this message may not be worth
reading<g>.

It's just a memo field containing text that happens to be RTF encoded
(usually, it can also be plain text) and 4 coordinates (left, top, width,
height) that controls where the RTF goes on the screen. Would it help, for
the sake of argument, to say the table was called "HTML" and it had a memo
field containing HTML encoded text and coordinates controlling its display,
or "PlainText" and it contained, well, plain text and coordinates for
controlling where the plain text was displayed on the screen? Maybe the
part people are missing is that, though the data is being input through
Access forms, it is not consumed by Access at all, but by another
application that has the capability to display RTF formatted (or plain) text
anywhere on the screen? Not sure why that matters, but maybe the mental
block is people thinking the RTF will be used inside Access...?

Really, it's *not* a tough concept.

Thanks!

-Amy

 

[John Nurick]

Yes, I did a google.groups search and came up with something similar to
that. I'm not really sure how you "clear" the linkmaster/linkchild fields.
Would it work to just delete it?

I can't think why not.

That doesn't handle insertion of a new record. However, an OnAfterInsert
event might work to store the ID in the container. That's what I'm doing
now, with the popup. Might be cleaner than what I have now, though what I
have now works.

From the UI point of view, is it better to have a clear distinction
between ordinary operations and data entry (i.e. with what will be
perceived as a separate form opening to create a new record), or to have
the data entry on the same subform (perceived as part of the main form).

It's just a memo field containing text that happens to be RTF encoded
(usually, it can also be plain text) and 4 coordinates (left, top, width,
height) that controls where the RTF goes on the screen.

It makes sense when you explain it, but when out of the blue you mention
a database entity called "RTF" in a context of Programs and
CourseReports, that was not the first thing that came to mind.