R
rkc
lyle said:
That'll be great.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
That'll be great.
D
David W. Fenton
[email protected] wrote in
"Me" is a reference to the CLASS MODULE of the object the code is
in. If you want to refer to a different object, you have to specify
it completely. Another form will be Form!frmOtherForm in place of
Me. A form that is embedded in the form you're coding in will be
Me!subFormControlName.Form.
That's all you need to know.
I wish one of them had a short section on globally accessing
things that don't happen to to pointed to my "Me."
"Me" is a reference to the CLASS MODULE of the object the code is
in. If you want to refer to a different object, you have to specify
it completely. Another form will be Form!frmOtherForm in place of
Me. A form that is embedded in the form you're coding in will be
Me!subFormControlName.Form.
That's all you need to know.
D
David W. Fenton
:
What are the limitations of subforms?
How do you use the form module-name syntax (which is what
Forms_FormName is) to refer to those different instances? It's
pretty easy to use the form's collection to figure out which one you
want to use by checking the caption. But how do you do that with
your suggested syntax?
I generally don't use subforms any more as the use of the syntax I
have suggested facilitates using full forms as sub forms ... with
none of the limitations of subforms.
What are the limitations of subforms?
When I use multiple instances of forms it is through code like:
How do you use the form module-name syntax (which is what
Forms_FormName is) to refer to those different instances? It's
pretty easy to use the form's collection to figure out which one you
want to use by checking the caption. But how do you do that with
your suggested syntax?
D
David W. Fenton
:
Huh? What about a single form with two copies of the same subform?
How do you distinguish those two subforms with your suggested
syntax? Adding a second form with a subform doesn't change the
problem space at all, though it might very well be more common.
I can't believe your applications have such poor UI that you don't
use subforms or that you're such a poor programmer that you'd not
re-use a form in more than one location if it were appropriate (as
it very often is).
Sometime when I consider it either worthwhile to have
two instances of a form open (with the form having a subform), or
likely that it will happen I'll check into it.
Huh? What about a single form with two copies of the same subform?
How do you distinguish those two subforms with your suggested
syntax? Adding a second form with a subform doesn't change the
problem space at all, though it might very well be more common.
I can't believe your applications have such poor UI that you don't
use subforms or that you're such a poor programmer that you'd not
re-use a form in more than one location if it were appropriate (as
it very often is).
L
lyle
[email protected] wrote innews:[email protected]:
"Me" is a reference to the CLASS MODULE of the object the code is
in.
Private Sub Form_Load()
Debug.Print Me Is Me.Module 'False
Debug.Print TypeName(Me), TypeName(Me.Module) 'Form_Issue List, Module
Debug.Print VarPtr(Me), VarPtr(Me.Module) '1297044,1296972
Debug.Print ObjPtr(Me), ObjPtr(Me.Module) '1563856, 55509776
End Sub
L
lyle
"Me" is a reference to the CLASS MODULE of the object the code is
in.
Private Sub Form_Load()
Debug.Print Me Is Me.Module 'False
Debug.Print TypeName(Me), TypeName(Me.Module) 'Form_Issue List, Module
Debug.Print VarPtr(Me), VarPtr(Me.Module) '1297044,1296972
Debug.Print ObjPtr(Me), ObjPtr(Me.Module) '1563856, 55509776
End Sub
L
lyle
Huh? What about a single form with two copies of the same subform?
TTBOMK VBA will search down the stack, so to speak, for the first
pointer to the subform; thus it will reference the last created
instance of the subform.
L
lyle
I can't believe your applications have such poor UI that you don't
use subforms or that you're such a poor programmer that you'd not
re-use a form in more than one location if it were appropriate (as
it very often is).
I can't think of any case where I have used the same form twice as a
subform (on the same parent form) so I can't say how I would deal with
that, but I expect it would be smoothly and efficiently, if I used
subforms, that is, but, of course, I don't. I think I stopped using
subforms five years ago or so; as I roll my own, users do not seem to
notice, except that they like to be able to move and size the "sub"
form.
I'm not sure if you were a regular here in CDMA when I posted in more
than one thread about exposing forms in library mdbs, making them
available for reuse not only within one application, but within many
at the same time. That must be almost ten years ago.
I really hope you won't bother yourself with my level of programming
expertise. It's been of sufficient quality over the past twenty-five
years that I have not had to seek clients actively during that time.
No need for you to miss your beauty sleep worrying about that.
I don't really expect to convert anyone to my position on this matter,
David, and arguing is tedious. So I'm checking out of this thread now.
R
rkc
David said:[email protected] wrote in
"Me" is a reference to the CLASS MODULE of the object the code is
in. If you want to refer to a different object, you have to specify
it completely. Another form will be Form!frmOtherForm in place of
Me. A form that is embedded in the form you're coding in will be
Me!subFormControlName.Form.
That's all you need to know.
I would say Me is a way to reference an instance of an object
from within the class module that defines the object. It's all
a bit fuzzy in Access since so much of the implementation of the
objects defined by the application is hidden.
R
rkc
lyle said:I don't really expect to convert anyone to my position on this matter,
David, and arguing is tedious. So I'm checking out of this thread now.
You're efforts are not wasted, Sir Lyle of Fairfield.
I learned of this from you previously, have investigated it
further, and am grateful to you for having enlightened me.
I just don't use it.
Take from that what you will.
N
Neil
lyle said:When I use multiple instances of forms it is through code like:
Dim ADetailForms(0 To 1) As [Form_Faculty Details]
Public Sub OpenSomeFormInstances()
Dim z As Long
For z = 0 To 1
Set ADetailForms(z) = New [Form_Faculty Details]
With ADetailForms(z)
.Visible = True
.Caption = "Look Ma Multiple Distinguishable Instances of
a Form " & z
End With
Next z
End Sub
Public Sub ZapAllThoseFormInstances()
Erase ADetailForms
End Sub
Hi, Lyle. I responded to this in a new thread I started here called "Working
With Multiple Form Instances." If you could take a look at it, I'd
appreciate it. Thanks!
Neil
D
David W. Fenton
m:
Me will be of type FORM when it's a form's class module, of type
REPORT when a report, and of type CLASS MODULE when in a standalone
class module. But this is because someone decided that the class
module reference should return an object of the type it is is part
of (or, put another way, of the subtype of class module).
It's very helpful, I think, to remember that it's the class module
that is referred to by Me simply because otherwise, it's hard to
explain why it works in a standalone class module but not in a
regular code module.
Private Sub Form_Load()
Debug.Print Me Is Me.Module 'False
Debug.Print TypeName(Me), TypeName(Me.Module) 'Form_Issue List,
Module Debug.Print VarPtr(Me), VarPtr(Me.Module) '1297044,1296972
Debug.Print ObjPtr(Me), ObjPtr(Me.Module) '1563856, 55509776
End Sub
Me will be of type FORM when it's a form's class module, of type
REPORT when a report, and of type CLASS MODULE when in a standalone
class module. But this is because someone decided that the class
module reference should return an object of the type it is is part
of (or, put another way, of the subtype of class module).
It's very helpful, I think, to remember that it's the class module
that is referred to by Me simply because otherwise, it's hard to
explain why it works in a standalone class module but not in a
regular code module.
D
David W. Fenton
m:
Yes, and then what? How do you utilize your syntax and act upon
something other than the default that is returned?
TTBOMK VBA will search down the stack, so to speak, for the first
pointer to the subform; thus it will reference the last created
instance of the subform.
Yes, and then what? How do you utilize your syntax and act upon
something other than the default that is returned?
D
David W. Fenton
:
I use it all the time for merging records during data cleanup
projects. That's both in my own maintenance work for clients as well
as in the applications my clients use (which very often need a
record merger form). Here's a screen shot:
http://dfenton.com/DFA/examples/DuplicateResolution.png
[that's actually a very early version of the design, so it's got
problems, but that was what was handy without logging onto a
terminal server and doing a screen capture there]
How do you use your syntax to refer to the two subforms on the
example form above? How do you distinguish the left one from the
right one? I do it because the subform controls on the form have
different names, delineating the difference between their functions.
How would you implement a record merger form like my example?
Yes. I think it's an excellent idea.
I think not using subforms is pig-headed and stupid, and costs your
clients a lot of money that they shouldn't have to pay.
I'd like to hear some kind of rational explanation of why you choose
to torture Access by avoiding its most powerful feature, i.e., the
subform (particularly the continuous one).
I can't think of any case where I have used the same form twice as
a subform (on the same parent form)
I use it all the time for merging records during data cleanup
projects. That's both in my own maintenance work for clients as well
as in the applications my clients use (which very often need a
record merger form). Here's a screen shot:
http://dfenton.com/DFA/examples/DuplicateResolution.png
[that's actually a very early version of the design, so it's got
problems, but that was what was handy without logging onto a
terminal server and doing a screen capture there]
so I can't say how I would deal with
that, but I expect it would be smoothly and efficiently, if I used
subforms, that is, but, of course, I don't.
How do you use your syntax to refer to the two subforms on the
example form above? How do you distinguish the left one from the
right one? I do it because the subform controls on the form have
different names, delineating the difference between their functions.
I think I stopped using
subforms five years ago or so; as I roll my own, users do not seem
to notice, except that they like to be able to move and size the
"sub" form.
How would you implement a record merger form like my example?
I'm not sure if you were a regular here in CDMA when I posted in
more than one thread about exposing forms in library mdbs, making
them available for reuse not only within one application, but
within many at the same time.
Yes. I think it's an excellent idea.
That must be almost ten years ago.
I really hope you won't bother yourself with my level of
programming expertise. It's been of sufficient quality over the
past twenty-five years that I have not had to seek clients
actively during that time. No need for you to miss your beauty
sleep worrying about that.
I think not using subforms is pig-headed and stupid, and costs your
clients a lot of money that they shouldn't have to pay.
I don't really expect to convert anyone to my position on this
matter, David, and arguing is tedious. So I'm checking out of this
thread now.
I'd like to hear some kind of rational explanation of why you choose
to torture Access by avoiding its most powerful feature, i.e., the
subform (particularly the continuous one).