CBF wipes out class based behavior? 
Author Message
 CBF wipes out class based behavior?

I think that this might be pretty hard to explain. Access 2000.

I have a subform that, when opens, is instaniated as a class. That class
uses WithEvents to sink some navigation behaviors to command buttons on
that subform. Normally everything works as expected.

However, I've just found that if I call a public CBF event in that
subform via the regular syntax, as in:

        Form_fsubRegister.cmdSave_Click

the class that controls navigation etc seems to go out of scope. None of
the class-based events etc work. Somehow calling that CBF code steps on
the class-based code associated with that subform. All of the CBF code
still works fine. There is no code that explictly sets the class code to
nothing, so I'm quite puzzled about what's going on here.

Hopefully someone who is familiar with these symptoms can get past the
poor description and shed some light on this seeming failure I'm seeing.
Is this a bug, or is there something obvious I'm missing?

Thanks



Tue, 19 Apr 2005 09:09:10 GMT  
 CBF wipes out class based behavior?
I've never seen this happen but I suspect that when you refer to the subform
via the default instance (Form_fSubRegister) the subform is reinitialized
which sends it out of scope and kills off your class. I personally don't
think it's a good idea to refer to a subform via the default instance.
Instead, try referring to the subform via the form and see if that works for
you

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

Quote:

> I think that this might be pretty hard to explain. Access 2000.

> I have a subform that, when opens, is instaniated as a class. That class
> uses WithEvents to sink some navigation behaviors to command buttons on
> that subform. Normally everything works as expected.

> However, I've just found that if I call a public CBF event in that
> subform via the regular syntax, as in:

> Form_fsubRegister.cmdSave_Click

> the class that controls navigation etc seems to go out of scope. None of
> the class-based events etc work. Somehow calling that CBF code steps on
> the class-based code associated with that subform. All of the CBF code
> still works fine. There is no code that explictly sets the class code to
> nothing, so I'm quite puzzled about what's going on here.

> Hopefully someone who is familiar with these symptoms can get past the
> poor description and shed some light on this seeming failure I'm seeing.
> Is this a bug, or is there something obvious I'm missing?

> Thanks



Tue, 19 Apr 2005 10:53:44 GMT  
 CBF wipes out class based behavior?
Thanks for responding Sandra.

Hmmm I've been referring to public proceedures in CBF via the following
format since Access 97:

Form_fsubRegister.cmdSave_Click

That's the way I thought we all did it. It never failed me before... but
it could be that you're right, although if so I'd sure like to hear more
about the why of it all. Oddly, earlier I discovered that if I
referenced that public proc in this manner:

Forms!frmRegister!subRegister.Form.cmdSave_Click

I couldn't believe it when it worked, I mean that the event fired at
all. It also doesn't mess with my class instantiation. Am I just
hallucinating or what? Are references to events supposed to be able to
be reached as above just like properties are? If so, did this happen
with Access 97 or later?

I think this style (Forms!frmRegister!subRegister.Form.cmdSave_Click) of
referencing the event is what you were pointing me at, yes?


Quote:
> I've never seen this happen but I suspect that when you refer to the subform
> via the default instance (Form_fSubRegister) the subform is reinitialized
> which sends it out of scope and kills off your class. I personally don't
> think it's a good idea to refer to a subform via the default instance.
> Instead, try referring to the subform via the form and see if that works for
> you

> --
> Sandra Daigle
> [Microsoft Access MVP]
> For the benefit of others please post all replies to this newsgroup.


> > I think that this might be pretty hard to explain. Access 2000.

> > I have a subform that, when opens, is instaniated as a class. That class
> > uses WithEvents to sink some navigation behaviors to command buttons on
> > that subform. Normally everything works as expected.

> > However, I've just found that if I call a public CBF event in that
> > subform via the regular syntax, as in:

> > Form_fsubRegister.cmdSave_Click

> > the class that controls navigation etc seems to go out of scope. None of
> > the class-based events etc work. Somehow calling that CBF code steps on
> > the class-based code associated with that subform. All of the CBF code
> > still works fine. There is no code that explictly sets the class code to
> > nothing, so I'm quite puzzled about what's going on here.

> > Hopefully someone who is familiar with these symptoms can get past the
> > poor description and shed some light on this seeming failure I'm seeing.
> > Is this a bug, or is there something obvious I'm missing?

> > Thanks



Tue, 19 Apr 2005 12:47:13 GMT  
 CBF wipes out class based behavior?
Yes - this is what I meant. I'm glad it's working for you. As I said I'm not
exactly sure why the other style destroys your class but my theory is that
it reinitializes the class.

References like Form_frmMyForm are direct references to the form's class and
are always refer to the default instance of the form. The only time I ever
use the actual form class name is when I want to instantiate multiple
instances of a specific form (set frm= new form_MyForm). I wouldn't say that
using the default instance is wrong but I think it can cause confusing
results - especially with subforms since it is fairly common to use a single
form as a subform on more that one main form (or multiple times on a single
main form). In these cases the default instance is only going to refer to
one of the subforms and it's not clear which one will be the default
instance. Using the forms!frmMyMain.sfrmMySub.form.MyFunction reference to a
method on the subform gaurantees that you're referencing a specific instance
of the subform. FWIW, most of my references use this style of reference
instead of the Form_MyForm reference (except of course when creating
multiple instances).

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

Quote:

> Thanks for responding Sandra.

> Hmmm I've been referring to public proceedures in CBF via the following
> format since Access 97:

> Form_fsubRegister.cmdSave_Click

> That's the way I thought we all did it. It never failed me before... but
> it could be that you're right, although if so I'd sure like to hear more
> about the why of it all. Oddly, earlier I discovered that if I
> referenced that public proc in this manner:

> Forms!frmRegister!subRegister.Form.cmdSave_Click

> I couldn't believe it when it worked, I mean that the event fired at
> all. It also doesn't mess with my class instantiation. Am I just
> hallucinating or what? Are references to events supposed to be able to
> be reached as above just like properties are? If so, did this happen
> with Access 97 or later?

> I think this style (Forms!frmRegister!subRegister.Form.cmdSave_Click) of
> referencing the event is what you were pointing me at, yes?


>> I've never seen this happen but I suspect that when you refer to the
>> subform via the default instance (Form_fSubRegister) the subform is
>> reinitialized which sends it out of scope and kills off your class. I
>> personally don't think it's a good idea to refer to a subform via the
>> default instance. Instead, try referring to the subform via the form and
>> see if that works for you

>> --
>> Sandra Daigle
>> [Microsoft Access MVP]
>> For the benefit of others please post all replies to this newsgroup.


>>> I think that this might be pretty hard to explain. Access 2000.

>>> I have a subform that, when opens, is instaniated as a class. That class
>>> uses WithEvents to sink some navigation behaviors to command buttons on
>>> that subform. Normally everything works as expected.

>>> However, I've just found that if I call a public CBF event in that
>>> subform via the regular syntax, as in:

>>> Form_fsubRegister.cmdSave_Click

>>> the class that controls navigation etc seems to go out of scope. None of
>>> the class-based events etc work. Somehow calling that CBF code steps on
>>> the class-based code associated with that subform. All of the CBF code
>>> still works fine. There is no code that explictly sets the class code to
>>> nothing, so I'm quite puzzled about what's going on here.

>>> Hopefully someone who is familiar with these symptoms can get past the
>>> poor description and shed some light on this seeming failure I'm seeing.
>>> Is this a bug, or is there something obvious I'm missing?

>>> Thanks



Tue, 19 Apr 2005 18:34:49 GMT  
 CBF wipes out class based behavior?

Quote:

> Thanks for responding Sandra.

> Hmmm I've been referring to public proceedures in CBF via the following
> format since Access 97:

> Form_fsubRegister.cmdSave_Click

> That's the way I thought we all did it.

No, and your approach is not workable (and you just found that out).

That approach can cause a lot of problems. First, when you reference the
form as above, if it is NOT loaded, then the form actually loads, and the
load event actually fires. This means that if for some reason the form you
are reference in code is closed, the above will fore it open again. This
means that you don't have any kind of control over what is going on here.

I find it very difficult that you "always" did it that way. You should note
that when you reference a sub form, you are fact not referencing a form, but
a form control. Remember, there is no such thing as a sub-form, but only a
sub-form control. You can place the same sub-form 5 times on the same
screen. Now, tell me, which one does your above format reference?

Answer: NONE!

You have no way of knowing which sub form is going to be referenced. What
happens if you have two forms opened, and the both use the same sub form?
Thus, you did not in the past reference sub forms this way, since it would
not have worked. Each sub-form is in fact a new and complete separate
instance of the form from the original. All of the variables, code and
values are in fact cloned from the original. References to the original will
do nothing to each of those instances.

Hence, you could have in the past been using the "form_myform" type of
reference for sub-forms. For example,the following can work:

form_SomeForm.Form.fsubRegister.cmdSave_click.

In the above example, we are referencing the SUB FORM CONTROL, and in fact
never did reference the sub form directly. Again, I think you are confusing
the two here, as you would have never had any programming success using the
first approach.

Regardless, even the last above example of mine that does work is a bad
practice.

Quote:
>It never failed me before.

No, you were not doing that in the past. You *may* have been doing the last
example format..but never the first "wrong" way.

In addition:

Quote:

> Forms!frmRegister!subRegister.Form.cmdSave_Click

That will work, but you have to declare the sub (or function) as public.

--
Albert D. Kallal
Edmonton, Alberta Canada



Tue, 19 Apr 2005 19:20:07 GMT  
 CBF wipes out class based behavior?

Quote:
> FWIW, most of my references use this style of reference instead
> of the Form_MyForm reference (except of course when creating multiple
> instances).

Upon re-reading - I realized that I didn't word this very well. What I was
trying to say was that I've not seen any documentation (Microsoft or
otherwise) that uses the Form_MyForm reference to an open form. I never use
this. I will use the class name form_MyForm to open multiple instances of a
form but that's it.

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

Quote:

> Yes - this is what I meant. I'm glad it's working for you. As I said I'm
> not exactly sure why the other style destroys your class but my theory is
> that it reinitializes the class.

> References like Form_frmMyForm are direct references to the form's class
> and are always refer to the default instance of the form. The only time I
> ever use the actual form class name is when I want to instantiate multiple
> instances of a specific form (set frm= new form_MyForm). I wouldn't say
> that using the default instance is wrong but I think it can cause
> confusing results - especially with subforms since it is fairly common to
> use a single form as a subform on more that one main form (or multiple
> times on a single main form). In these cases the default instance is only
> going to refer to one of the subforms and it's not clear which one will
> be the default instance. Using the
> forms!frmMyMain.sfrmMySub.form.MyFunction reference to a method on the
> subform gaurantees that you're referencing a specific instance of the
> subform. FWIW, most of my references use this style of reference instead
> of the Form_MyForm reference (except of course when creating multiple
> instances).


>> Thanks for responding Sandra.

>> Hmmm I've been referring to public proceedures in CBF via the following
>> format since Access 97:

>> Form_fsubRegister.cmdSave_Click

>> That's the way I thought we all did it. It never failed me before... but
>> it could be that you're right, although if so I'd sure like to hear more
>> about the why of it all. Oddly, earlier I discovered that if I
>> referenced that public proc in this manner:

>> Forms!frmRegister!subRegister.Form.cmdSave_Click

>> I couldn't believe it when it worked, I mean that the event fired at
>> all. It also doesn't mess with my class instantiation. Am I just
>> hallucinating or what? Are references to events supposed to be able to
>> be reached as above just like properties are? If so, did this happen
>> with Access 97 or later?

>> I think this style (Forms!frmRegister!subRegister.Form.cmdSave_Click) of
>> referencing the event is what you were pointing me at, yes?


>>> I've never seen this happen but I suspect that when you refer to the
>>> subform via the default instance (Form_fSubRegister) the subform is
>>> reinitialized which sends it out of scope and kills off your class. I
>>> personally don't think it's a good idea to refer to a subform via the
>>> default instance. Instead, try referring to the subform via the form and
>>> see if that works for you

>>> --
>>> Sandra Daigle
>>> [Microsoft Access MVP]
>>> For the benefit of others please post all replies to this newsgroup.


>>>> I think that this might be pretty hard to explain. Access 2000.

>>>> I have a subform that, when opens, is instaniated as a class. That
>>>> class uses WithEvents to sink some navigation behaviors to command
>>>> buttons on that subform. Normally everything works as expected.

>>>> However, I've just found that if I call a public CBF event in that
>>>> subform via the regular syntax, as in:

>>>> Form_fsubRegister.cmdSave_Click

>>>> the class that controls navigation etc seems to go out of scope. None
>>>> of the class-based events etc work. Somehow calling that CBF code
>>>> steps on the class-based code associated with that subform. All of the
>>>> CBF code still works fine. There is no code that explictly sets the
>>>> class code to nothing, so I'm quite puzzled about what's going on here.

>>>> Hopefully someone who is familiar with these symptoms can get past the
>>>> poor description and shed some light on this seeming failure I'm
>>>> seeing. Is this a bug, or is there something obvious I'm missing?

>>>> Thanks



Tue, 19 Apr 2005 20:28:48 GMT  
 CBF wipes out class based behavior?
Sandra,

I tend to use the Form_MyForm reference when when instantiating the form as
a user class (as in "Set frm = New Form_MyForm"), or when referring to a
form's procedures (but not when that form has already been instantiated as a
user class).

If I was to refer to a subform that was brought to life by the
user-instantiation of the parent form, I would use the following syntax
(after Set frm = New Form_MyForm):
    frm.MySubForm.Form

Just my $0.02.

Graham R Seach
Microsoft Access MVP
Sydney, Australia


Quote:
> > FWIW, most of my references use this style of reference instead
> > of the Form_MyForm reference (except of course when creating multiple
> > instances).

> Upon re-reading - I realized that I didn't word this very well. What I was
> trying to say was that I've not seen any documentation (Microsoft or
> otherwise) that uses the Form_MyForm reference to an open form. I never
use
> this. I will use the class name form_MyForm to open multiple instances of
a
> form but that's it.

> --
> Sandra Daigle
> [Microsoft Access MVP]
> For the benefit of others please post all replies to this newsgroup.


> > Yes - this is what I meant. I'm glad it's working for you. As I said I'm
> > not exactly sure why the other style destroys your class but my theory
is
> > that it reinitializes the class.

> > References like Form_frmMyForm are direct references to the form's class
> > and are always refer to the default instance of the form. The only time
I
> > ever use the actual form class name is when I want to instantiate
multiple
> > instances of a specific form (set frm= new form_MyForm). I wouldn't say
> > that using the default instance is wrong but I think it can cause
> > confusing results - especially with subforms since it is fairly common
to
> > use a single form as a subform on more that one main form (or multiple
> > times on a single main form). In these cases the default instance is
only
> > going to refer to one of the subforms and it's not clear which one will
> > be the default instance. Using the
> > forms!frmMyMain.sfrmMySub.form.MyFunction reference to a method on the
> > subform gaurantees that you're referencing a specific instance of the
> > subform. FWIW, most of my references use this style of reference instead
> > of the Form_MyForm reference (except of course when creating multiple
> > instances).


> >> Thanks for responding Sandra.

> >> Hmmm I've been referring to public proceedures in CBF via the following
> >> format since Access 97:

> >> Form_fsubRegister.cmdSave_Click

> >> That's the way I thought we all did it. It never failed me before...
but
> >> it could be that you're right, although if so I'd sure like to hear
more
> >> about the why of it all. Oddly, earlier I discovered that if I
> >> referenced that public proc in this manner:

> >> Forms!frmRegister!subRegister.Form.cmdSave_Click

> >> I couldn't believe it when it worked, I mean that the event fired at
> >> all. It also doesn't mess with my class instantiation. Am I just
> >> hallucinating or what? Are references to events supposed to be able to
> >> be reached as above just like properties are? If so, did this happen
> >> with Access 97 or later?

> >> I think this style (Forms!frmRegister!subRegister.Form.cmdSave_Click)
of
> >> referencing the event is what you were pointing me at, yes?


> >>> I've never seen this happen but I suspect that when you refer to the
> >>> subform via the default instance (Form_fSubRegister) the subform is
> >>> reinitialized which sends it out of scope and kills off your class. I
> >>> personally don't think it's a good idea to refer to a subform via the
> >>> default instance. Instead, try referring to the subform via the form
and
> >>> see if that works for you

> >>> --
> >>> Sandra Daigle
> >>> [Microsoft Access MVP]
> >>> For the benefit of others please post all replies to this newsgroup.


> >>>> I think that this might be pretty hard to explain. Access 2000.

> >>>> I have a subform that, when opens, is instaniated as a class. That
> >>>> class uses WithEvents to sink some navigation behaviors to command
> >>>> buttons on that subform. Normally everything works as expected.

> >>>> However, I've just found that if I call a public CBF event in that
> >>>> subform via the regular syntax, as in:

> >>>> Form_fsubRegister.cmdSave_Click

> >>>> the class that controls navigation etc seems to go out of scope. None
> >>>> of the class-based events etc work. Somehow calling that CBF code
> >>>> steps on the class-based code associated with that subform. All of
the
> >>>> CBF code still works fine. There is no code that explictly sets the
> >>>> class code to nothing, so I'm quite puzzled about what's going on
here.

> >>>> Hopefully someone who is familiar with these symptoms can get past
the
> >>>> poor description and shed some light on this seeming failure I'm
> >>>> seeing. Is this a bug, or is there something obvious I'm missing?

> >>>> Thanks



Wed, 20 Apr 2005 20:38:29 GMT  
 CBF wipes out class based behavior?
Your posts are super helpful. I've been using

Form_fsubRegister.cmdSave_Click

type code for years, but those days are over. Since I basically never
use forms in subform controls in more than one place, I'd not run into
the ambiguous reference issue.


Quote:
> > FWIW, most of my references use this style of reference instead
> > of the Form_MyForm reference (except of course when creating multiple
> > instances).

> Upon re-reading - I realized that I didn't word this very well. What I was
> trying to say was that I've not seen any documentation (Microsoft or
> otherwise) that uses the Form_MyForm reference to an open form. I never use
> this. I will use the class name form_MyForm to open multiple instances of a
> form but that's it.

> --
> Sandra Daigle
> [Microsoft Access MVP]
> For the benefit of others please post all replies to this newsgroup.


> > Yes - this is what I meant. I'm glad it's working for you. As I said I'm
> > not exactly sure why the other style destroys your class but my theory is
> > that it reinitializes the class.

> > References like Form_frmMyForm are direct references to the form's class
> > and are always refer to the default instance of the form. The only time I
> > ever use the actual form class name is when I want to instantiate multiple
> > instances of a specific form (set frm= new form_MyForm). I wouldn't say
> > that using the default instance is wrong but I think it can cause
> > confusing results - especially with subforms since it is fairly common to
> > use a single form as a subform on more that one main form (or multiple
> > times on a single main form). In these cases the default instance is only
> > going to refer to one of the subforms and it's not clear which one will
> > be the default instance. Using the
> > forms!frmMyMain.sfrmMySub.form.MyFunction reference to a method on the
> > subform gaurantees that you're referencing a specific instance of the
> > subform. FWIW, most of my references use this style of reference instead
> > of the Form_MyForm reference (except of course when creating multiple
> > instances).


> >> Thanks for responding Sandra.

> >> Hmmm I've been referring to public proceedures in CBF via the following
> >> format since Access 97:

> >> Form_fsubRegister.cmdSave_Click

> >> That's the way I thought we all did it. It never failed me before... but
> >> it could be that you're right, although if so I'd sure like to hear more
> >> about the why of it all. Oddly, earlier I discovered that if I
> >> referenced that public proc in this manner:



Thu, 21 Apr 2005 02:46:55 GMT  
 CBF wipes out class based behavior?
Albert -

Thanks that was a very helpful post. Some of the issues you raised with

Form_fsubRegister.cmdSave_Click

didn't trip be up before, becuase, for instance, I never have the same
subform open more than once in the app, so the reference was
unambiguous. But the point is well taken. I pretty much used this
technique to access code that was form oriented and needed to be called
from various other forms. Each time I used it I could have called a
global proceedure in a separate module. In fact that's what I used to
do.

Thanks again.



Quote:


> > Thanks for responding Sandra.

> > Hmmm I've been referring to public proceedures in CBF via the following
> > format since Access 97:

> > Form_fsubRegister.cmdSave_Click

> > That's the way I thought we all did it.

> No, and your approach is not workable (and you just found that out).

> That approach can cause a lot of problems. First, when you reference the
> form as above, if it is NOT loaded, then the form actually loads, and the
> load event actually fires. This means that if for some reason the form you
> are reference in code is closed, the above will fore it open again. This
> means that you don't have any kind of control over what is going on here.

> I find it very difficult that you "always" did it that way. You should note
> that when you reference a sub form, you are fact not referencing a form, but
> a form control. Remember, there is no such thing as a sub-form, but only a
> sub-form control. You can place the same sub-form 5 times on the same
> screen. Now, tell me, which one does your above format reference?

> Answer: NONE!

> You have no way of knowing which sub form is going to be referenced. What
> happens if you have two forms opened, and the both use the same sub form?
> Thus, you did not in the past reference sub forms this way, since it would
> not have worked. Each sub-form is in fact a new and complete separate
> instance of the form from the original. All of the variables, code and
> values are in fact cloned from the original. References to the original will
> do nothing to each of those instances.

> Hence, you could have in the past been using the "form_myform" type of
> reference for sub-forms. For example,the following can work:

> form_SomeForm.Form.fsubRegister.cmdSave_click.

> In the above example, we are referencing the SUB FORM CONTROL, and in fact
> never did reference the sub form directly. Again, I think you are confusing
> the two here, as you would have never had any programming success using the
> first approach.

> Regardless, even the last above example of mine that does work is a bad
> practice.

> >It never failed me before.



Thu, 21 Apr 2005 02:43:00 GMT  
 CBF wipes out class based behavior?
Hi Graham - I'm not sure what you mean by instantiating the form as a user
class - unless you are talking about being able to instantiate multiple
copies of it which is what I was also referring to above. IOW, is there a
reason why you would open only one instance of a form and use 'Set frm = New
Form_MyForm' instead of 'docmd.openform MyForm'?

I also refer to the subform via the parent form's subform control. I was
rather surprised to find that using the class name instead would work as a
valid reference to a subform if it was the only open instance of that form.
I still wouldn't use it though :-)

--
Sandra Daigle
[Microsoft Access MVP]
For the benefit of others please post all replies to this newsgroup.

Quote:

> Sandra,

> I tend to use the Form_MyForm reference when when instantiating the form
> as a user class (as in "Set frm = New Form_MyForm"), or when referring to
> a form's procedures (but not when that form has already been instantiated
> as a user class).

> If I was to refer to a subform that was brought to life by the
> user-instantiation of the parent form, I would use the following syntax
> (after Set frm = New Form_MyForm):
>     frm.MySubForm.Form

> Just my $0.02.

> Graham R Seach
> Microsoft Access MVP
> Sydney, Australia



>>> FWIW, most of my references use this style of reference instead
>>> of the Form_MyForm reference (except of course when creating multiple
>>> instances).

>> Upon re-reading - I realized that I didn't word this very well. What I
>> was trying to say was that I've not seen any documentation (Microsoft or
>> otherwise) that uses the Form_MyForm reference to an open form. I never
>> use this. I will use the class name form_MyForm to open multiple
>> instances of a form but that's it.

>> --
>> Sandra Daigle
>> [Microsoft Access MVP]
>> For the benefit of others please post all replies to this newsgroup.


>>> Yes - this is what I meant. I'm glad it's working for you. As I said I'm
>>> not exactly sure why the other style destroys your class but my theory
>>> is that it reinitializes the class.

>>> References like Form_frmMyForm are direct references to the form's class
>>> and are always refer to the default instance of the form. The only time
>>> I ever use the actual form class name is when I want to instantiate
>>> multiple instances of a specific form (set frm= new form_MyForm). I
>>> wouldn't say that using the default instance is wrong but I think it
>>> can cause confusing results - especially with subforms since it is
>>> fairly common to use a single form as a subform on more that one main
>>> form (or multiple times on a single main form). In these cases the
>>> default instance is only going to refer to one of the subforms and it's
>>> not clear which one will be the default instance. Using the
>>> forms!frmMyMain.sfrmMySub.form.MyFunction reference to a method on the
>>> subform gaurantees that you're referencing a specific instance of the
>>> subform. FWIW, most of my references use this style of reference instead
>>> of the Form_MyForm reference (except of course when creating multiple
>>> instances).


>>>> Thanks for responding Sandra.

>>>> Hmmm I've been referring to public proceedures in CBF via the following
>>>> format since Access 97:

>>>> Form_fsubRegister.cmdSave_Click

>>>> That's the way I thought we all did it. It never failed me before...
>>>> but it could be that you're right, although if so I'd sure like to
>>>> hear more about the why of it all. Oddly, earlier I discovered that if
>>>> I referenced that public proc in this manner:

>>>> Forms!frmRegister!subRegister.Form.cmdSave_Click

>>>> I couldn't believe it when it worked, I mean that the event fired at
>>>> all. It also doesn't mess with my class instantiation. Am I just
>>>> hallucinating or what? Are references to events supposed to be able to
>>>> be reached as above just like properties are? If so, did this happen
>>>> with Access 97 or later?

>>>> I think this style (Forms!frmRegister!subRegister.Form.cmdSave_Click)
>>>> of referencing the event is what you were pointing me at, yes?


>>>>> I've never seen this happen but I suspect that when you refer to the
>>>>> subform via the default instance (Form_fSubRegister) the subform is
>>>>> reinitialized which sends it out of scope and kills off your class. I
>>>>> personally don't think it's a good idea to refer to a subform via the
>>>>> default instance. Instead, try referring to the subform via the form
>>>>> and see if that works for you

>>>>> --
>>>>> Sandra Daigle
>>>>> [Microsoft Access MVP]
>>>>> For the benefit of others please post all replies to this newsgroup.


>>>>>> I think that this might be pretty hard to explain. Access 2000.

>>>>>> I have a subform that, when opens, is instaniated as a class. That
>>>>>> class uses WithEvents to sink some navigation behaviors to command
>>>>>> buttons on that subform. Normally everything works as expected.

>>>>>> However, I've just found that if I call a public CBF event in that
>>>>>> subform via the regular syntax, as in:

>>>>>> Form_fsubRegister.cmdSave_Click

>>>>>> the class that controls navigation etc seems to go out of scope. None
>>>>>> of the class-based events etc work. Somehow calling that CBF code
>>>>>> steps on the class-based code associated with that subform. All of
>>>>>> the CBF code still works fine. There is no code that explictly sets
>>>>>> the class code to nothing, so I'm quite puzzled about what's going
>>>>>> on here.

>>>>>> Hopefully someone who is familiar with these symptoms can get past
>>>>>> the poor description and shed some light on this seeming failure I'm
>>>>>> seeing. Is this a bug, or is there something obvious I'm missing?

>>>>>> Thanks



Fri, 22 Apr 2005 05:23:10 GMT  
 CBF wipes out class based behavior?
Hi Sandra,

<<...unless you are talking about being able to instantiate multiple...>>
Yes, that's exactly what I meant (I just couldn't think of a more
appropriate term to describe it).

<<is there a reason why you would open only one instance of a form and use
'Set frm = New Form_MyForm' instead of 'docmd.openform MyForm'?>>
Yes, there is a very good reason. If you want to use the form as a dialog,
and you want to return values from that dialog to the form that called it,
regardless of *which* form called it. I think this is what the OP is trying
to do, and I use this method quite often.

<<...rather surprised to find that using the class name instead would
work...>>
Me too, and I wouldn't use it on the subform either. It seems to me that
there'd be no way to determine which subform you're working on if more than
one parent form was open, unless the reference was used from within that
parent.

Graham R Seach
Microsoft Access MVP
Sydney, Australia


Quote:
> Hi Graham - I'm not sure what you mean by instantiating the form as a user
> class - unless you are talking about being able to instantiate multiple
> copies of it which is what I was also referring to above. IOW, is there a
> reason why you would open only one instance of a form and use 'Set frm =
New
> Form_MyForm' instead of 'docmd.openform MyForm'?

> I also refer to the subform via the parent form's subform control. I was
> rather surprised to find that using the class name instead would work as a
> valid reference to a subform if it was the only open instance of that
form.
> I still wouldn't use it though :-)

> --
> Sandra Daigle
> [Microsoft Access MVP]
> For the benefit of others please post all replies to this newsgroup.


> > Sandra,

> > I tend to use the Form_MyForm reference when when instantiating the form
> > as a user class (as in "Set frm = New Form_MyForm"), or when referring
to
> > a form's procedures (but not when that form has already been
instantiated
> > as a user class).

> > If I was to refer to a subform that was brought to life by the
> > user-instantiation of the parent form, I would use the following syntax
> > (after Set frm = New Form_MyForm):
> >     frm.MySubForm.Form

> > Just my $0.02.

> > Graham R Seach
> > Microsoft Access MVP
> > Sydney, Australia



> >>> FWIW, most of my references use this style of reference instead
> >>> of the Form_MyForm reference (except of course when creating multiple
> >>> instances).

> >> Upon re-reading - I realized that I didn't word this very well. What I
> >> was trying to say was that I've not seen any documentation (Microsoft
or
> >> otherwise) that uses the Form_MyForm reference to an open form. I never
> >> use this. I will use the class name form_MyForm to open multiple
> >> instances of a form but that's it.

> >> --
> >> Sandra Daigle
> >> [Microsoft Access MVP]
> >> For the benefit of others please post all replies to this newsgroup.


> >>> Yes - this is what I meant. I'm glad it's working for you. As I said
I'm
> >>> not exactly sure why the other style destroys your class but my theory
> >>> is that it reinitializes the class.

> >>> References like Form_frmMyForm are direct references to the form's
class
> >>> and are always refer to the default instance of the form. The only
time
> >>> I ever use the actual form class name is when I want to instantiate
> >>> multiple instances of a specific form (set frm= new form_MyForm). I
> >>> wouldn't say that using the default instance is wrong but I think it
> >>> can cause confusing results - especially with subforms since it is
> >>> fairly common to use a single form as a subform on more that one main
> >>> form (or multiple times on a single main form). In these cases the
> >>> default instance is only going to refer to one of the subforms and
it's
> >>> not clear which one will be the default instance. Using the
> >>> forms!frmMyMain.sfrmMySub.form.MyFunction reference to a method on the
> >>> subform gaurantees that you're referencing a specific instance of the
> >>> subform. FWIW, most of my references use this style of reference
instead
> >>> of the Form_MyForm reference (except of course when creating multiple
> >>> instances).


> >>>> Thanks for responding Sandra.

> >>>> Hmmm I've been referring to public proceedures in CBF via the
following
> >>>> format since Access 97:

> >>>> Form_fsubRegister.cmdSave_Click

> >>>> That's the way I thought we all did it. It never failed me before...
> >>>> but it could be that you're right, although if so I'd sure like to
> >>>> hear more about the why of it all. Oddly, earlier I discovered that
if
> >>>> I referenced that public proc in this manner:

> >>>> Forms!frmRegister!subRegister.Form.cmdSave_Click

> >>>> I couldn't believe it when it worked, I mean that the event fired at
> >>>> all. It also doesn't mess with my class instantiation. Am I just
> >>>> hallucinating or what? Are references to events supposed to be able
to
> >>>> be reached as above just like properties are? If so, did this happen
> >>>> with Access 97 or later?

> >>>> I think this style (Forms!frmRegister!subRegister.Form.cmdSave_Click)
> >>>> of referencing the event is what you were pointing me at, yes?


> >>>>> I've never seen this happen but I suspect that when you refer to the
> >>>>> subform via the default instance (Form_fSubRegister) the subform is
> >>>>> reinitialized which sends it out of scope and kills off your class.
I
> >>>>> personally don't think it's a good idea to refer to a subform via
the
> >>>>> default instance. Instead, try referring to the subform via the form
> >>>>> and see if that works for you

> >>>>> --
> >>>>> Sandra Daigle
> >>>>> [Microsoft Access MVP]
> >>>>> For the benefit of others please post all replies to this newsgroup.


> >>>>>> I think that this might be pretty hard to explain. Access 2000.

> >>>>>> I have a subform that, when opens, is instaniated as a class. That
> >>>>>> class uses WithEvents to sink some navigation behaviors to command
> >>>>>> buttons on that subform. Normally everything works as expected.

> >>>>>> However, I've just found that if I call a public CBF event in that
> >>>>>> subform via the regular syntax, as in:

> >>>>>> Form_fsubRegister.cmdSave_Click

> >>>>>> the class that controls navigation etc seems to go out of scope.
None
> >>>>>> of the class-based events etc work. Somehow calling that CBF code
> >>>>>> steps on the class-based code associated with that subform. All of
> >>>>>> the CBF code still works fine. There is no code that explictly sets
> >>>>>> the class code to nothing, so I'm quite puzzled about what's going
> >>>>>> on here.

> >>>>>> Hopefully someone who is familiar with these symptoms can get past
> >>>>>> the poor description and shed some light on this seeming failure
I'm
> >>>>>> seeing. Is this a bug, or is there something obvious I'm missing?

> >>>>>> Thanks



Fri, 22 Apr 2005 07:09:36 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. derive class from protected class in base class

2. StatusBarPanel Collection containing panels based on different classes derived from StatusBarPanel class

3. Using Class Builder Utility to create a base class (VB6)

4. Class to control subform behavior - worth it?

5. Change in Class Public Variable behavior in VB5

6. Change in Class Public Variable behavior in VB5

7. Weird behavior of procedures within classes

8. OLE Problems getting CBF code to execute

9. Converting CBF from 2.0 to 97

10. Calling Function in CBF from Toolbar via a Public Function

11. university EMR send outs

12. Get name of base class?

 

 
Powered by phpBB® Forum Software