Un-Mapping Mapped Network Drives Andrew Coates - dFPUG-Portal

there’s now a container in the way, so there isn’t a
txtShoCol object on the form anymore. Instead it’s
contained in the cntChgCol, which is on the form, so the
reference now has to be THISFORM.cntChgCol.txtShoCol
instead.
Andy: Or even better, use THIS.Parent.txtShoCol instead.
In fact, that’s what you probably should have done the
first time, planning ahead in case the group of controls
was going to be reused in a container class, or you were
going to add them to a Page Frame to the form.
Paul: That reminds me—in MS Knowledge Base article
Q155013, there’s a text box in a column of a grid in a
container that’s doing an incremental search. In the
KeyPress event, there’s a line of code that seems a
little excessive:
THIS.Parent.Parent.Parent.Search( nKeyCode )
I can work out what it’s doing—the Search() method
is a method of the container, and this is passing the
keystroke to it, but that’s not very clear, is it? It’s unlikely
to be broken when it’s reused, because the article is about
building a custom control.
Andy: So what are you suggesting? In that particular case,
I don’t see that there’s any alternative. The referencing has
to be relative, because the text box can’t possibly know
what the name of the outermost container will be at
runtime. There’s no “THISCONTAINER” reference, and
anything relative to “THISFORM” is obviously not
applicable. It’s not pretty, but I don’t see what else you
can do.
Paul: Well, what I’d do is create a ThisContainer reference.
Either as a property if I’m using a class, which is set to
THIS.Parent.Parent.Parent in the INIT() method, or as a
LOCAL variable that has to be set every time the
KeyPress method is called (and therefore is of little
benefit). There’s a marginal benefit in the latter
approach, because the reference is also used in
THIS.Parent.Parent.Parent.Pop() in the same method
where the variable can be used as well.
Andy: I see. So you’re proposing to replace this:
IF nKeyCode = 13 && They hit the ENTER key
This.Parent.Parent.Parent.Pop()
ENDIF
IF (nKeyCode > 48 AND nKeyCode < 58) OR ;
(nKeyCode > 64 AND nKeyCode < 123)
** Calls the search method if you hit a
** letter or numeric key.
This.Parent.Parent.Parent.Search(nKeyCode)
ENDIF
with this:
LOCAL loThisContainer
loThisContainer = This.Parent.Parent.Parent
IF nKeyCode = 13 && They hit the ENTER key
loThisContainer.Pop()
ENDIF
IF (nKeyCode > 48 AND nKeyCode < 58) OR ;
(nKeyCode > 64 AND nKeyCode < 123)
** Calls the search method if you hit a
** letter or numeric key.
loThisContainer.Search(nKeyCode)
ENDIF
As you say, the speed benefit is marginal, but the
code is now much more readable and hence easier to
maintain. I’m wondering why use a LOCAL variable
if you can’t create a property, when you could use a
PUBLIC variable to simulate the property and initialize
it by placing goThisContainer = THIS in the container’s
INIT() method.
Paul: Aaargh! Splutter, cough . . . You’re playing devil’s
advocate, aren’t you? Well, since there can be only one
global variable, you’ll run into problems if your forms are
modeless and can have multiple instances open in the
application at a time—or even if you adopt this technique
in every container class and just have two or more
containers on the same form.
Andy: All right! I give in; even though my forms would
probably be modal anyway, the second reason is the
clincher. (Just testing .)
20 FoxTalk December 1998
http://www.pinpub.com