C
Chris Nebinger
As I understand it, you are trying to close one form from
another. The DoCmd.Close with no arguments closes the
active window. DoCmd.Close acForm, "FormName" will close
that form name.
DoCmd.Close acForm, Me.Name will close the form the code
is placed in.
As to why you are adding "Form_1" and Form_2 is closing
sounds like a bug.
Chris Nebinger
data input to the calling form then a form/sub-form pair
is generally not an appropriate way of engineering this
requirement.
a subsequent DoCmd.Close command, issued from Form_1 will
close Form_2, rather than, or as well as, Form_1. The
reason for this appears to be that, if the form to be
closed is not specified, DoCmd.Close closes the last
object opened, in typical LIFO stack management manner.
This may be understandable but, when the specific close
command, DoCmd.Close acForm, â?oForm_1â?, is substituted
for the shortened version, it is still Form_2 which is
closed.
is invoked. This allows the short form of the close
command to be used but suffers the drawback that, for
obvious reasons, after Form_1 has been closed, no
reference can be made to any of its fields, unless the
field values are first copied into â?~place-holdingâ?T
variables with wider scope. Public, or Global, variables
are perhaps the most obvious choice but this solution is
not ideal because it tends to undermine the principles of
OOP, or structured, programming and can lead to some
pretty arcane coding in certain circumstances. Can anyone
throw some light on this and, perhaps, suggest a more
satisfactory strategy?
another. The DoCmd.Close with no arguments closes the
active window. DoCmd.Close acForm, "FormName" will close
that form name.
DoCmd.Close acForm, Me.Name will close the form the code
is placed in.
As to why you are adding "Form_1" and Form_2 is closing
sounds like a bug.
Chris Nebinger
If the identity of the called form varies according to the-----Original Message-----
It is often necessary to 'call' one form from another.
data input to the calling form then a form/sub-form pair
is generally not an appropriate way of engineering this
requirement.
say - is used to open the called form â?" Form_2 â?" thenIf VBA code associated with the calling form - Form_1,
a subsequent DoCmd.Close command, issued from Form_1 will
close Form_2, rather than, or as well as, Form_1. The
reason for this appears to be that, if the form to be
closed is not specified, DoCmd.Close closes the last
object opened, in typical LIFO stack management manner.
This may be understandable but, when the specific close
command, DoCmd.Close acForm, â?oForm_1â?, is substituted
for the shortened version, it is still Form_2 which is
closed.
from the Form_1 VBA code, before the open Form_2 commandOne way around this is to issue the close Form_1 command,
is invoked. This allows the short form of the close
command to be used but suffers the drawback that, for
obvious reasons, after Form_1 has been closed, no
reference can be made to any of its fields, unless the
field values are first copied into â?~place-holdingâ?T
variables with wider scope. Public, or Global, variables
are perhaps the most obvious choice but this solution is
not ideal because it tends to undermine the principles of
OOP, or structured, programming and can lead to some
pretty arcane coding in certain circumstances. Can anyone
throw some light on this and, perhaps, suggest a more
satisfactory strategy?