Function vs Sub /Public vs Private

[lauren quantrell]

I'm hoping someone can tell me if there is any performance benefit in
my applications between distinguishing a code routine as a Function or
a Sub or if there is a performance benefit between identiying a
Function as a Function or a Private Function (or Sub as a Sub or a
Private Sub) in code modules.

I understand that using Private Functions or Private Subs limits the
scope from which it can be called, but I'm wondering if there is any
speed or overhead benefit in making the distinction.

I know I can't call a Sub using "=SubName()" in the event procedure of
a control, only = "=FunctionName()", so I just got in the habit of
labeling everything as a Function instead.

Thanks,
lq

[Steve Jorgensen]

On 18 Jul 2005 08:44:53 -0700, "lauren quantrell"
<la*************@hotmail.com> wrote:

I'm hoping someone can tell me if there is any performance benefit in
my applications between distinguishing a code routine as a Function or
a Sub or if there is a performance benefit between identiying a
Function as a Function or a Private Function (or Sub as a Sub or a
Private Sub) in code modules.
If a value is not being returned, a Sub should be a tiny bit more efficient
than a Function, but I doubt you'll ever notice the difference. Public vs
Private should not be expected to make any difference at all since it's only a
rule, checked at compile-time.
I understand that using Private Functions or Private Subs limits the
scope from which it can be called, but I'm wondering if there is any
speed or overhead benefit in making the distinction.
There shouldn't be.
I know I can't call a Sub using "=SubName()" in the event procedure of
a control, only = "=FunctionName()", so I just got in the habit of
labeling everything as a Function instead.

I consider that poor style (but that's a matter of taste), but I doubt there's
any noticeable performance penalty.

[lauren quantrell]

Steve,
Thanks for the reply.

Poor Style refering to labeling everything as a Function instead of a
Sub or Poor Style using =FunctionName() in the event procedure of a
control?

thanks,
lq

[David W. Fenton]

"lauren quantrell" <la*************@hotmail.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

Poor Style refering to labeling everything as a Function instead
of a Sub or Poor Style using =FunctionName() in the event
procedure of a control?

If it's a function, it should be a function.

If it's not, it should be a sub.

Sounds axiomatic, but making every code snippet you write a function
is abdicating your responsibility as a programmer for evaluating the
purpose and use of the code you are writing.

To me, the default is to make a SUB.

You only write a function when you *must*:

- if you must return a single value

- if the code needs to be called in contexts where only functions
work (i.e., macros, etc.).

If you write a sub and later need to use it as function, it's about
1 second's work to change it to a function.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[lauren quantrell]

David,
Thanks for that but I have to ask, is there any difference in overhead
or performance with having every code snippet a function vs. a sub and
how in evaluating the code will it make a difference? I'm not trying to
be difficult, just trying to decide why and to who it would make any
difference.
Thanks,
lq

[Rick Brandt]

lauren quantrell wrote:

David,
Thanks for that but I have to ask, is there any difference in overhead
or performance with having every code snippet a function vs. a sub and
how in evaluating the code will it make a difference? I'm not trying
to be difficult, just trying to decide why and to who it would make
any difference.
Thanks,
lq

Try it. Run a sub in a loop a few hundred times and then run the same code as a
function and see if there's a difference. My guess would be no, but it would
just be a guess.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Trevor Best]

Rick Brandt wrote:

lauren quantrell wrote:

David,
Thanks for that but I have to ask, is there any difference in overhead
or performance with having every code snippet a function vs. a sub and
how in evaluating the code will it make a difference? I'm not trying
to be difficult, just trying to decide why and to who it would make
any difference.
Thanks,
lq

Try it. Run a sub in a loop a few hundred times and then run the same code as a
function and see if there's a difference. My guess would be no, but it would
just be a guess.

sub is a second faster... after 10,000,000 calls :-)
as an aside, using "call" doesn't make a damn.

Output of code (code below sig)
***
Sub Direct Call: 1.5625
Func Direct Call: 2.671875
Sub Call: 1.625
Func Call: 2.671875

--
[OO=00=OO]

Sub testsubvfunction()
Dim s As Single
Dim i As Long
Const clngTimes As Long = 10000000

Debug.Print "***"

s = Timer
For i = 1 To clngTimes
testsub
Next
Debug.Print "Sub Direct Call: " & Timer - s

s = Timer
For i = 1 To clngTimes
testfun
Next
Debug.Print "Func Direct Call: " & Timer - s

s = Timer
For i = 1 To clngTimes
Call testsub
Next
Debug.Print "Sub Call: " & Timer - s

s = Timer
For i = 1 To clngTimes
Call testfun
Next
Debug.Print "Func Call: " & Timer - s
End Sub
Sub testsub()
Dim a As Long
a = 1
End Sub
Function testfun()
Dim a As Long
a = 1
End Function

[james.igoe]

Not being dogmatic, I've started running many procedures as functions,
returning a boolean or text. This has improved my program control and
error tracking, since, if the function procedure fails, it returns a
value to the originating routine, allowing me to code for errors, as
well as giving better programmatic control.

[Steve Jorgensen]

On 19 Jul 2005 04:53:50 -0700, "ja********@gmail.com" <ja********@gmail.com>
wrote:

Not being dogmatic, I've started running many procedures as functions,
returning a boolean or text. This has improved my program control and
error tracking, since, if the function procedure fails, it returns a
value to the originating routine, allowing me to code for errors, as
well as giving better programmatic control.

That's sort of a C coding style. Isn't that what exceptions are for, though?
To not clutter the main line of execution with If statements to handle
non-mainline cases?

[lauren quantrell]

And to my original point, I use a lot of event procedures to call code
OnClick = "=RunSomeCoolCode()" and these can't be called as subs but
they can be called as functions. In many cases the code called by an
event procedure on one form might also be called from an event
procedure or a command button on other forms. Codig it as a function in
one place streamlines the code and increases opportunities to use it
repeatedly throughout the application.
lq

[David W. Fenton]

"lauren quantrell" <la*************@hotmail.com> wrote in
news:11**********************@g43g2000cwa.googlegr oups.com:

And to my original point, I use a lot of event procedures to call
code OnClick = "=RunSomeCoolCode()" and these can't be called as
subs but they can be called as functions. In many cases the code
called by an event procedure on one form might also be called from
an event procedure or a command button on other forms. Codig it as
a function in one place streamlines the code and increases
opportunities to use it repeatedly throughout the application.

You seem to be arguing for an approach that I consider to be
brain-dead stupid. That is, you seem to suggest making every
subroutine a function *just in case* you should ever sometime
between now and the Apocalypse need to use it as a function.

That, to me, constitutes an abdication of one of the most important
jobs of a programmer: to fully consider the scope and use of code as
you're writing it. If you never ask yourself "should this be a sub
or a function?" you may end up not really considering important
issues regarding how the code you are writing is going to be needed,
in what contexts and for what purposes.

Secondly (to repeat myself). it's not like it's *hard* to convert a
subroutine to a function once the need to return a value comes up --
it takes all of one second.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[lauren quantrell]

I'm really trying to undertsnad this since others in this thread have
demonstrated how it makes no difference as far as speed or overhead.
So, how does limiting the scope of a bunch of code in a Sub make any
difference beween unlimiting it in a Function? I do make great use of
Private Functions vs. Public Functions to accomplish this.
lq

[David W. Fenton]

"lauren quantrell" <la*************@hotmail.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

I'm really trying to undertsnad this since others in this thread
have demonstrated how it makes no difference as far as speed or
overhead. So, how does limiting the scope of a bunch of code in a
Sub make any difference beween unlimiting it in a Function? I do
make great use of Private Functions vs. Public Functions to
accomplish this.

Because asking yourself "should this be a function or a sub?" frames
the whole issue of what purpose the code serves.

The performance issue has ZILCH to do with it.

If I were picking up someone else's code and found everything was a
function, I'd be severely puzzled trying to figure out why, until I
figured out that it was just a misguided (or incompetent)
programmer.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

lauren quantrell wrote:

And to my original point, I use a lot of event procedures to call code
OnClick = "=RunSomeCoolCode()" and these can't be called as subs but
they can be called as functions. In many cases the code called by an
event procedure on one form might also be called from an event
procedure or a command button on other forms. Codig it as a function in
one place streamlines the code and increases opportunities to use it
repeatedly throughout the application.

To me, using OnClick = "=RunSomeCoolCode()" in a property sheet is an
awful lot like using a lookup field in the design of a table. It
masks the fact that an event is triggering some action. I favour
Call RunSomeCoolCode() in the Event's Sub in the form's code module.
There a sub is a sub and a function is a function.

[lauren quantrell]

I agree with you 100% except that in MS Access forms load much faster
when they have no code module, so in general I choose to use OnClick =
"=RunSomeCoolCode()" and avoid having a form code module whenever
possible.

[lauren quantrell]

I agree with you 100% except that in MS Access forms load much faster
when they have no code module, so in general I choose to use OnClick =
"=RunSomeCoolCode()" and avoid having a form code module whenever
possible.

[rkc]

lauren quantrell wrote:

I agree with you 100% except that in MS Access forms load much faster
when they have no code module, so in general I choose to use OnClick =
"=RunSomeCoolCode()" and avoid having a form code module whenever
possible.

I can't argue with that if you have found it actually makes a noticeable
difference. A problem I would have with that personally is that I tend
to document a form's purpose in it's code module.

[Rick Brandt]

lauren quantrell wrote:

I agree with you 100% except that in MS Access forms load much faster
when they have no code module, so in general I choose to use OnClick =
"=RunSomeCoolCode()" and avoid having a form code module whenever
possible.

That was the hype when "light forms" were introduced, but I have never noticed a
difference.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:uC*******************@twister.nyroc.rr.com:

lauren quantrell wrote:

And to my original point, I use a lot of event procedures to call
code OnClick = "=RunSomeCoolCode()" and these can't be called as
subs but they can be called as functions. In many cases the code
called by an event procedure on one form might also be called
from an event procedure or a command button on other forms. Codig
it as a function in one place streamlines the code and increases
opportunities to use it repeatedly throughout the application.

To me, using OnClick = "=RunSomeCoolCode()" in a property sheet is
an awful lot like using a lookup field in the design of a table.
It masks the fact that an event is triggering some action. I
favour Call RunSomeCoolCode() in the Event's Sub in the form's
code module. There a sub is a sub and a function is a function.

Well, it's awfully handy to select a bunch of controls and type a
single function into the same event for all of them. It's much
harder to do the same in VBA.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:ff*******************@twister.nyroc.rr.com:

lauren quantrell wrote:

I agree with you 100% except that in MS Access forms load much
faster when they have no code module, so in general I choose to
use OnClick = "=RunSomeCoolCode()" and avoid having a form code
module whenever possible.

I can't argue with that if you have found it actually makes a
noticeable difference. A problem I would have with that personally
is that I tend to document a form's purpose in it's code module.

I've never seen any noticeable difference in peformance with
module-less forms.

Didn't someone benchmark this way back when A2K first came out (the
first version that allowed you to set the HasModule property to
False), and find that there was virtually no difference in load time
for these lightweight, module-less forms?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:uC*******************@twister.nyroc.rr.com:

lauren quantrell wrote:

And to my original point, I use a lot of event procedures to call
code OnClick = "=RunSomeCoolCode()" and these can't be called as
subs but they can be called as functions. In many cases the code
called by an event procedure on one form might also be called
from an event procedure or a command button on other forms. Codig
it as a function in one place streamlines the code and increases
opportunities to use it repeatedly throughout the application.

To me, using OnClick = "=RunSomeCoolCode()" in a property sheet is
an awful lot like using a lookup field in the design of a table.
It masks the fact that an event is triggering some action. I
favour Call RunSomeCoolCode() in the Event's Sub in the form's
code module. There a sub is a sub and a function is a function.

Well, it's awfully handy to select a bunch of controls and type a
single function into the same event for all of them. It's much
harder to do the same in VBA.

I almost mentioned that, then figured it was a given. I personally
have a tendency to wrap that type of behavior in a class instead.

[David W. Fenton]

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Nz******************@twister.nyroc.rr.com:

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:uC*******************@twister.nyroc.rr.com:

lauren quantrell wrote:

And to my original point, I use a lot of event procedures to
call code OnClick = "=RunSomeCoolCode()" and these can't be
called as subs but they can be called as functions. In many
cases the code called by an event procedure on one form might
also be called from an event procedure or a command button on
other forms. Codig it as a function in one place streamlines the
code and increases opportunities to use it repeatedly throughout
the application.

To me, using OnClick = "=RunSomeCoolCode()" in a property sheet
is an awful lot like using a lookup field in the design of a
table. It masks the fact that an event is triggering some action.
I favour Call RunSomeCoolCode() in the Event's Sub in the form's
code module. There a sub is a sub and a function is a function.

Well, it's awfully handy to select a bunch of controls and type a
single function into the same event for all of them. It's much
harder to do the same in VBA.

I almost mentioned that, then figured it was a given. I personally
have a tendency to wrap that type of behavior in a class instead.

That's substantially more work for what seems to me to be very
little benefit.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Nz******************@twister.nyroc.rr.com:

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:uC*******************@twister.nyroc.rr.com :
lauren quantrell wrote:
>And to my original point, I use a lot of event procedures to
>call code OnClick = "=RunSomeCoolCode()" and these can't be
>called as subs but they can be called as functions. In many
>cases the code called by an event procedure on one form might
>also be called from an event procedure or a command button on
>other forms. Codig it as a function in one place streamlines the
>code and increases opportunities to use it repeatedly throughout
>the application.

To me, using OnClick = "=RunSomeCoolCode()" in a property sheet
is an awful lot like using a lookup field in the design of a
table. It masks the fact that an event is triggering some action.
I favour Call RunSomeCoolCode() in the Event's Sub in the form's
code module. There a sub is a sub and a function is a function.

Well, it's awfully handy to select a bunch of controls and type a
single function into the same event for all of them. It's much
harder to do the same in VBA.

I almost mentioned that, then figured it was a given. I personally
have a tendency to wrap that type of behavior in a class instead.

That's substantially more work for what seems to me to be very
little benefit.

Suppose you have several textbox controls that you want to
1) change color on focus
2) change color on lost focus
3) validate input when changed
4) follow behaviour rules stored outside the code
5) react to certain events in other textbox controls

Would you write multiple functions and set event properties
or would you write a class, initialise the required number
of instances and manage them via a collection? Which is
more work? Which would be easier to modify? If you were
hit by a NYC bus which would make your successor happier?

[David W. Fenton]

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:_l*******************@twister.nyroc.rr.com:

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Nz******************@twister.nyroc.rr.com:

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:uC*******************@twister.nyroc.rr.co m:
>lauren quantrell wrote:
>
>
>>And to my original point, I use a lot of event procedures to
>>call code OnClick = "=RunSomeCoolCode()" and these can't be
>>called as subs but they can be called as functions. In many
>>cases the code called by an event procedure on one form might
>>also be called from an event procedure or a command button on
>>other forms. Codig it as a function in one place streamlines
>>the code and increases opportunities to use it repeatedly
>>throughout the application.
>
>To me, using OnClick = "=RunSomeCoolCode()" in a property sheet
>is an awful lot like using a lookup field in the design of a
>table. It masks the fact that an event is triggering some
>action. I favour Call RunSomeCoolCode() in the Event's Sub in
>the form's code module. There a sub is a sub and a function is
>a function.

Well, it's awfully handy to select a bunch of controls and type
a single function into the same event for all of them. It's much
harder to do the same in VBA.

I almost mentioned that, then figured it was a given. I
personally have a tendency to wrap that type of behavior in a
class instead.

That's substantially more work for what seems to me to be very
little benefit.

Suppose you have several textbox controls that you want to
1) change color on focus
2) change color on lost focus
3) validate input when changed
4) follow behaviour rules stored outside the code
5) react to certain events in other textbox controls

Would you write multiple functions and set event properties
or would you write a class, initialise the required number
of instances and manage them via a collection? Which is
more work? Which would be easier to modify? If you were
hit by a NYC bus which would make your successor happier?

Well, you've substantially upped the bar on the kind of
functionality I was thinking about.

And whether a future programmer likes it or not depends entirely her
level of expertise. Plenty of people making their living as Access
programmers wouldn't be able to figure out how it is accomplished.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:_l*******************@twister.nyroc.rr.com:

David W. Fenton wrote:

Plenty of people making their living as Access
programmers wouldn't be able to figure out how it is accomplished.

Plenty of people making their living as Access programmers don't
know how to sort "e;b;c;d;a;g" alphabetically. Hopefully any
client smart enough to hire ya'll would be smart enough to replace
ya'll with one who did.

[Bri]

lauren quantrell wrote:

I'm really trying to undertsnad this since others in this thread have
demonstrated how it makes no difference as far as speed or overhead.
So, how does limiting the scope of a bunch of code in a Sub make any
difference beween unlimiting it in a Function? I do make great use of
Private Functions vs. Public Functions to accomplish this.
lq

I'm not sure if this is true, but it seems logical (at least to me). It
may be faster to have the Function declared Public if it is called
frequently. I think that Public Functions (or Subs) are loaded into
memory on initial loading of the app and they stay in memory. Private
ones are only loaded when they are called. So it seams to be a case of
which overhead causes more/less performance; more memory consumed or
loading of private at runtime. With today's PCs with tons of RAM, it
might favour loading everything at the start

--
Bri

[Larry Linson]

"David W. Fenton" wrote

I've never seen any noticeable
difference in peformance with
module-less forms.

Mike Groh, Tech Editor of Access Advisor, tested Forms with the largest
possible Modules versus Forms without Modules when they were first released,
and highly hyped as "faster". He found, and published, that the difference
was in the range of 5 - 15 milliseconds. That is, of course, far to small to
be perceptible to the user looking at the Form opening on a display screen.

That kind of time difference would only be of consequence in a loop,
repeated many times, and that is not how Forms are opened.

To Microsoft's credit, I have not seen them hyping codeless Forms since that
was published.

Larry Linson
Microsoft Access MVP

[Larry Linson]

"rkc" wrote

Plenty of people making their living as
Access programmers don't know how
to sort "e;b;c;d;a;g" alphabetically.
Hopefully any client smart enough to
hire ya'll would be smart enough to
replace ya'll with one who did.

I'd warrant that my clients have all been smart enough to hire developers
whose talents and cost matched their needs. I've been in the computer
business since 1958 and have rarely run across a valid real-world
requirement to sort in anything other than "normal" sequences on maiframes,
minicomputers, or micros.

And, when I did, it was always "names of something" in the order that people
normally thought of them... trivially simple to handle. The few people I
ever worked with who were not smart enough to use a "sort order" field or
function didn't last long in the programming (or development) business,
anyway.

Larry Linson
Microsoft Access MVP

[downwitch]

I initially bought into the light-form hype, and have never gone back.
(When I ran my li'l tests years back, it made a huge difference, but I
sure don't consider "because I remember it that way" a benchmark.)

I stayed with it because I don't think assembling a bunch of VBA code
in a form module constitutes organization. (In fact, I *hate* forms'
modules, and avoid them like the plague, for many reasons which don't
bear mention here.) The events are all right there in the little
property sheet to look at. And as far as I can tell, clicking the
little Build button in the property sheet next to an event, jumping to
a well-structured public procedure in an appropriately grouped module
is a lot quicker than opening the #%!$%% module of the form and hitting
SHIFT+F2 a bunch of times. The user, of course, will never know the
difference. (Except my forms load a little faster ;).)

Furthermore, at the point at which you're building classes, you're
outside the form space anyway, logically and literally.

Does all this mean I have some Functions that should be Subs? Yep. And
I'm willing to bet you fifty bucks and a team of mules I've got some
Subs that could very easily become Functions, too. Doesn't mean I
don't think about it, but I enjoy sleep and leisure activities outside
of programming as well.

[rkc]

downwitch wrote:

Does all this mean I have some Functions that should be Subs? Yep. And
I'm willing to bet you fifty bucks and a team of mules I've got some
Subs that could very easily become Functions, too. Doesn't mean I
don't think about it, but I enjoy sleep and leisure activities outside
of programming as well.

What do you use the mules for? To set in your ways to buy a tractor?

[Larry Linson]

"lauren quantrell" wrote

I agree with you 100% except that
in MS Access forms load much faster
when they have no code module, . . .

No, they don't -- not unless you consider 5 - 15 milliseconds "much faster".
It was a good idea that just didn't prove out. See my response to David,
later in the thread, about Mike Groh's testing and published results.

[Trevor Best]

Larry Linson wrote:

Mike Groh, Tech Editor of Access Advisor, tested Forms with the largest
possible Modules versus Forms without Modules when they were first released,
and highly hyped as "faster". He found, and published, that the difference
was in the range of 5 - 15 milliseconds. That is, of course, far to small to
be perceptible to the user looking at the Form opening on a display screen.

Hey, my clients are drumming their fingers on the table well before that :-)

--
[OO=00=OO]

[downwitch]

rkc wrote:

downwitch wrote:

Does all this mean I have some Functions that should be Subs? Yep. And
I'm willing to bet you fifty bucks and a team of mules I've got some
Subs that could very easily become Functions, too. Doesn't mean I
don't think about it, but I enjoy sleep and leisure activities outside
of programming as well.

What do you use the mules for? To set in your ways to buy a tractor?

Counterstubbornness.

[lauren quantrell]

Larry,
Maybe I formed that opinion back in Access 97 and have it stuck in my
mind. I can remember loading forms with a couple of subforms and when I
removed all the OnLoad, OnOpen, populating and control formatting code
into a module named after the form (to keep it all in one place) I
could count the difference with the second hand on my watch.
Maybe it got changed but I kept the notion it makes a difference and
have stuck with that contruction since those dark days.

[David W. Fenton]

"lauren quantrell" <la*************@hotmail.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

Maybe I formed that opinion back in Access 97 and have it stuck in
my mind. I can remember loading forms with a couple of subforms
and when I removed all the OnLoad, OnOpen, populating and control
formatting code into a module named after the form (to keep it all
in one place) I could count the difference with the second hand on
my watch. Maybe it got changed but I kept the notion it makes a
difference and have stuck with that contruction since those dark
days.

Sounds like your forms weren't properly compiled and were
recompiling each time they were loaded.

That's a completely different set of problems that can be solved
without moving all the code out of the forms.

And it may be due to hidden corruption -- decompile (judiciously
used) is your friend.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[downwitch]

David W. Fenton wrote:

"lauren quantrell" <la*************@hotmail.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

Maybe I formed that opinion back in Access 97 and have it stuck in
my mind. I can remember loading forms with a couple of subforms
and when I removed all the OnLoad, OnOpen, populating and control
formatting code into a module named after the form (to keep it all
in one place) I could count the difference with the second hand on
my watch. Maybe it got changed but I kept the notion it makes a
difference and have stuck with that contruction since those dark
days.

Sounds like your forms weren't properly compiled and were
recompiling each time they were loaded.

That's a completely different set of problems that can be solved
without moving all the code out of the forms.

And it may be due to hidden corruption -- decompile (judiciously
used) is your friend.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Okay, I'll bite. I have never heard of a form being "compiled", in ten
years of (almost) pure Access development, across the wide web of the
world and numerous manuals. What, exactly, is a compiled form?

And I decompile _mdb files_ as often as you please--as do a number of
other scamps about these parts--with nary a side effect I could name.
So please, elaborate. With hyperlinked backup, de preférence.

[David W. Fenton]

"downwitch" <do*******@gmail.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

David W. Fenton wrote:

"lauren quantrell" <la*************@hotmail.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

> Maybe I formed that opinion back in Access 97 and have it stuck
> in my mind. I can remember loading forms with a couple of
> subforms and when I removed all the OnLoad, OnOpen, populating
> and control formatting code into a module named after the form
> (to keep it all in one place) I could count the difference with
> the second hand on my watch. Maybe it got changed but I kept
> the notion it makes a difference and have stuck with that
> contruction since those dark days.
Sounds like your forms weren't properly compiled and were
recompiling each time they were loaded.

That's a completely different set of problems that can be solved
without moving all the code out of the forms.

And it may be due to hidden corruption -- decompile (judiciously
used) is your friend.

Okay, I'll bite. I have never heard of a form being "compiled",
in ten years of (almost) pure Access development, across the wide
web of the world and numerous manuals. What, exactly, is a
compiled form?

Every form with code is compiled to be run. The code you type is
compiled into a p-code symbolic form that is interpreted by the
Access executables.

If a form's module has not been compiled when the form is opened,
Access does the compiling on the fly. But somehow it doesn't always
get flagged as compiled and then recompiles each time you open the
form. This is because there are a whole host of levels of
compilation in an Access project:

The real deal on the /Decompile switch
http://trigeminal.com/usenet/usenet004.asp?1033

Pay special attention to the discussion of the "11 states of of
compilation."
And I decompile _mdb files_ as often as you please--as do a number
of other scamps about these parts--with nary a side effect I could
name. So please, elaborate. With hyperlinked backup, de
preférence.

If you decompile regularly, and are doing it proberly, then you
shouldn't be having code corruption.

If you're still having problems (and I've seen them survive
decompiles, occasionally), you can use Application.SaveAsText and
Application.LoadFromText to rebuild all your code-bearing objects.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc