Question of syntax

[John Winterbottom]

Some time ago Steve Jorgenson, (I think it was he), wrote of possible
problems using the intellisense-friendly "Form_" syntax to refer to forms
and their controls. At the time I responded that I'd never seen any
problems - which was true until today.

Using Access XP on WinXP Pro with all service packs.

My code checks to see if a form, "frmMain", is dirty. So my options are::

a) If Form_frmMain.Di rty Then
b) If Forms("frmMain" ).Dirty Then
c) If Forms![frmMain].Dirty Then.

For some reason, using option a) above causes one of my combo boxes to lose
it's records. The combo box is populated, using a callback function, from a
sql server stored procedure. Several other combo boxes are unaffected. If I
requery the combo box I get my records back. The problem occurs whether or
not the form is actually dirty - simply the reference to Form_frmMain
apparently vaporizes the records.

At the risk of starting a syntax flame war I just thought I'd mention this
here and see if anyone has any comments.

Other than "well don't use a) then" :-).

[Albert D. Kallal]

Re: Question of syntax

That is quite interesting!

one question:

Any possibility that you have multiplate copies, or this is used in a
sub-form?

You see, if you direct reference the form object, and multiplate copies
exists (such as the INSTANT you use the form as a sub-form, the ms-access
will actually refer to the first instance of that sub-form..but after that,
it can't know!

So, in the case of a sub-form, or multiple instances of a form allowed, then
ms-access gets confused as to what form_Name is when more then one copy is
loaded.

Best not to do that!

If you don't have more then one instance loaded, and you are not using this
as a sub-form..then I am at a loss, but as always, using the base object can
cause problems...


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKa llal@msn.com

http://www.attcanada.net/~kallal.msn

[Terry Kreft]

Re: Question of syntax

John,
The obvious difference is that (b) and (c) refer to form instances in the
forms collection whereas (a) will create an instance of frmMain if one
doesn't exist.

Try running the following

Function wibble()
Debug.Print "Forms Count = " & Forms.Count
Form_frmMain.Wi dth = 200
Debug.Print "Forms Count = " & Forms.Count
Set Form_frmMain = Nothing
Debug.Print "Forms Count = " & Forms.Count
End Function

output
Forms Count = 0
Forms Count = 1
Forms Count = 0

interestingly replacing
Form_frmMain.Wi dth = 200

with
Form_frmMain.Di rty = False

generates an error but the form instance is still created.

IOW using the Form_frmMain is not a good idea, it's a bit like using the New
keyword when declaring an object variable and we all know that's bad don't
we ? <g>

--
Terry Kreft
MVP Microsoft Access


"John Winterbottom" <assaynet@hotma il.com> wrote in message
news:2kit83F2oj 9kU1@uni-berlin.de...[color=blue]
> Some time ago Steve Jorgenson, (I think it was he), wrote of possible
> problems using the intellisense-friendly "Form_" syntax to refer to forms
> and their controls. At the time I responded that I'd never seen any
> problems - which was true until today.
>
> Using Access XP on WinXP Pro with all service packs.
>
> My code checks to see if a form, "frmMain", is dirty. So my options are::
>
> a) If Form_frmMain.Di rty Then
> b) If Forms("frmMain" ).Dirty Then
> c) If Forms![frmMain].Dirty Then.
>
> For some reason, using option a) above causes one of my combo boxes to[/color]
lose[color=blue]
> it's records. The combo box is populated, using a callback function, from[/color]
a[color=blue]
> sql server stored procedure. Several other combo boxes are unaffected. If[/color]
I[color=blue]
> requery the combo box I get my records back. The problem occurs whether or
> not the form is actually dirty - simply the reference to Form_frmMain
> apparently vaporizes the records.
>
> At the risk of starting a syntax flame war I just thought I'd mention this
> here and see if anyone has any comments.
>
> Other than "well don't use a) then" :-).
>
>[/color]

[John Winterbottom]

Re: Question of syntax

"Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
news:0WednbQIA_ r77XjdSa8jmA@ka roo.co.uk...[color=blue]
> John,
> The obvious difference is that (b) and (c) refer to form instances in the
> forms collection whereas (a) will create an instance of frmMain if one
> doesn't exist.
>
> Try running the following
>
> Function wibble()
> Debug.Print "Forms Count = " & Forms.Count
> Form_frmMain.Wi dth = 200
> Debug.Print "Forms Count = " & Forms.Count
> Set Form_frmMain = Nothing
> Debug.Print "Forms Count = " & Forms.Count
> End Function
>
> output
> Forms Count = 0
> Forms Count = 1
> Forms Count = 0[/color]
[color=blue]
> interestingly replacing
> Form_frmMain.Wi dth = 200
>
> with
> Form_frmMain.Di rty = False
>
> generates an error but the form instance is still created.[/color]


Hi Terry, thanks for the reply. I understand a bit more about this now - and
about what is happening behind the scenes, This last point is interesting; I
changed my code to

If Form_frmMain.Wi dth > 0

and, surprise surprise, no problems. So something is up with the combination
of syntax a) and the forms' Dirty property.

[color=blue]
> IOW using the Form_frmMain is not a good idea, it's a bit like using the[/color]
New[color=blue]
> keyword when declaring an object variable and we all know that's bad don't
> we ? <g>
>[/color]

I started using the "Form_" syntax some time ago, primarily because it
allows you to take advantage of intellisense. It seems this wasn't such a
good move after all! Thanks again.

[John Winterbottom]

Re: Question of syntax

"Albert D. Kallal" <PleaseNOOOsPAM Mkallal@msn.com > wrote in message
news:SJ8Fc.9656 14$oR5.537248@p d7tw3no...[color=blue]
> That is quite interesting!
>
> one question:
>
> Any possibility that you have multiplate copies, or this is used in a
> sub-form?
>
> You see, if you direct reference the form object, and multiplate copies
> exists (such as the INSTANT you use the form as a sub-form, the ms-access
> will actually refer to the first instance of that sub-form..but after[/color]
that,[color=blue]
> it can't know!
>
> So, in the case of a sub-form, or multiple instances of a form allowed,[/color]
then[color=blue]
> ms-access gets confused as to what form_Name is when more then one copy is
> loaded.
>
> Best not to do that!
>
> If you don't have more then one instance loaded, and you are not using[/color]
this[color=blue]
> as a sub-form..then I am at a loss, but as always, using the base object[/color]
can[color=blue]
> cause problems...
>[/color]

Hi Albert, thanks for the reply. No, no multiple copies open - and it's not
a subform. As I said to Terry, it seems that accessing the Dirty property is
what is causing the problem. Other form props, like Width, are OK. Well,
I've spent enough time on this now. I will change my practices and move on.

[Terry Kreft]

Re: Question of syntax

John,
If you decalre a variable of type of the form you still get intellisense but
without the irritating creation of an unexpected instance.

e.g
Function wibble2()
Dim fM As Form_frmMain

' If the following line isn't included you get the dreaded error
' 91 - Object variable or With block variable not set
Set fM = New Form_frmMain

Debug.Print "Forms Count = " & Forms.Count
fM.Width = 200
Debug.Print "Forms Count = " & Forms.Count
Set fM = Nothing
Debug.Print "Forms Count = " & Forms.Count
End Function

--
Terry Kreft
MVP Microsoft Access


"John Winterbottom" <assaynet@hotma il.com> wrote in message
news:2knvd4F4ik 4aU1@uni-berlin.de...[color=blue]
> "Terry Kreft" <terry.kreft@mp s.co.uk> wrote in message
> news:0WednbQIA_ r77XjdSa8jmA@ka roo.co.uk...[color=green]
> > John,
> > The obvious difference is that (b) and (c) refer to form instances in[/color][/color]
the[color=blue][color=green]
> > forms collection whereas (a) will create an instance of frmMain if one
> > doesn't exist.
> >
> > Try running the following
> >
> > Function wibble()
> > Debug.Print "Forms Count = " & Forms.Count
> > Form_frmMain.Wi dth = 200
> > Debug.Print "Forms Count = " & Forms.Count
> > Set Form_frmMain = Nothing
> > Debug.Print "Forms Count = " & Forms.Count
> > End Function
> >
> > output
> > Forms Count = 0
> > Forms Count = 1
> > Forms Count = 0[/color]
>[color=green]
> > interestingly replacing
> > Form_frmMain.Wi dth = 200
> >
> > with
> > Form_frmMain.Di rty = False
> >
> > generates an error but the form instance is still created.[/color]
>
>
> Hi Terry, thanks for the reply. I understand a bit more about this now -[/color]
and[color=blue]
> about what is happening behind the scenes, This last point is interesting;[/color]
I[color=blue]
> changed my code to
>
> If Form_frmMain.Wi dth > 0
>
> and, surprise surprise, no problems. So something is up with the[/color]
combination[color=blue]
> of syntax a) and the forms' Dirty property.
>
>[color=green]
> > IOW using the Form_frmMain is not a good idea, it's a bit like using the[/color]
> New[color=green]
> > keyword when declaring an object variable and we all know that's bad[/color][/color]
don't[color=blue][color=green]
> > we ? <g>
> >[/color]
>
> I started using the "Form_" syntax some time ago, primarily because it
> allows you to take advantage of intellisense. It seems this wasn't such a
> good move after all! Thanks again.
>
>
>
>
>
>
>
>
>
>
>[/color]