Function vs Sub /Public vs Private

[lauren quantrell]

Re: Function vs Sub /Public vs Private

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 =
"=RunSomeCoolCo de()" and avoid having a form code module whenever
possible.

[rkc]

Re: Function vs Sub /Public vs Private

lauren quantrell wrote:[color=blue]
> 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 =
> "=RunSomeCoolCo de()" and avoid having a form code module whenever
> possible.[/color]

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]

Re: Function vs Sub /Public vs Private

lauren quantrell wrote:[color=blue]
> 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 =
> "=RunSomeCoolCo de()" and avoid having a form code module whenever
> possible.[/color]

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]

Re: Function vs Sub /Public vs Private

rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
news:uCgDe.5276 1$0i3.48066@twi ster.nyroc.rr.c om:
[color=blue]
> lauren quantrell wrote:[color=green]
>> And to my original point, I use a lot of event procedures to call
>> code OnClick = "=RunSomeCoolCo de()" 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.[/color]
>
> To me, using OnClick = "=RunSomeCoolCo de()" 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.[/color]

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]

Re: Function vs Sub /Public vs Private

rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
news:ffpDe.5295 4$0i3.20115@twi ster.nyroc.rr.c om:
[color=blue]
> lauren quantrell wrote:[color=green]
>> 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 = "=RunSomeCoolCo de()" and avoid having a form code
>> module whenever possible.[/color]
>
> 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.[/color]

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]

Re: Function vs Sub /Public vs Private

David W. Fenton wrote:[color=blue]
> rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
> news:uCgDe.5276 1$0i3.48066@twi ster.nyroc.rr.c om:
>
>[color=green]
>>lauren quantrell wrote:
>>[color=darkred]
>>>And to my original point, I use a lot of event procedures to call
>>>code OnClick = "=RunSomeCoolCo de()" 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
>>>opportunitie s to use it repeatedly throughout the application.[/color]
>>
>>To me, using OnClick = "=RunSomeCoolCo de()" 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.[/color]
>
>
> 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.[/color]

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]

Re: Function vs Sub /Public vs Private

rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
news:NzzDe.3627 3$e%5.7316@twis ter.nyroc.rr.co m:
[color=blue]
> David W. Fenton wrote:[color=green]
>> rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
>> news:uCgDe.5276 1$0i3.48066@twi ster.nyroc.rr.c om:
>>[color=darkred]
>>>lauren quantrell wrote:
>>>
>>>>And to my original point, I use a lot of event procedures to
>>>>call code OnClick = "=RunSomeCoolCo de()" 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 = "=RunSomeCoolCo de()" 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.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

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]

Re: Function vs Sub /Public vs Private

David W. Fenton wrote:[color=blue]
> rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
> news:NzzDe.3627 3$e%5.7316@twis ter.nyroc.rr.co m:
>
>[color=green]
>>David W. Fenton wrote:
>>[color=darkred]
>>>rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
>>>news:uCgDe.5 2761$0i3.48066@ twister.nyroc.r r.com:
>>>
>>>
>>>>lauren quantrell wrote:
>>>>
>>>>
>>>>>And to my original point, I use a lot of event procedures to
>>>>>call code OnClick = "=RunSomeCoolCo de()" 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 = "=RunSomeCoolCo de()" 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.[/color]
>>
>>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.[/color]
>
>
> That's substantially more work for what seems to me to be very
> little benefit.[/color]

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]

Re: Function vs Sub /Public vs Private

rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
news:_lDDe.5598 2$0i3.19119@twi ster.nyroc.rr.c om:
[color=blue]
> David W. Fenton wrote:[color=green]
>> rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
>> news:NzzDe.3627 3$e%5.7316@twis ter.nyroc.rr.co m:
>>
>>[color=darkred]
>>>David W. Fenton wrote:
>>>
>>>>rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
>>>>news:uCgDe. 52761$0i3.48066 @twister.nyroc. rr.com:
>>>>
>>>>
>>>>>lauren quantrell wrote:
>>>>>
>>>>>
>>>>>>And to my original point, I use a lot of event procedures to
>>>>>>call code OnClick = "=RunSomeCoolCo de()" 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
>>>>>>throughou t the application.
>>>>>
>>>>>To me, using OnClick = "=RunSomeCoolCo de()" 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.[/color]
>>
>>
>> That's substantially more work for what seems to me to be very
>> little benefit.[/color]
>
> 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?[/color]

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]

Re: Function vs Sub /Public vs Private

David W. Fenton wrote:[color=blue]
> rkc <rkc@rochester. yabba.dabba.do. rr.bomb> wrote in
> news:_lDDe.5598 2$0i3.19119@twi ster.nyroc.rr.c om:
>
>[color=green]
>>David W. Fenton wrote:[/color][/color]
[color=blue]
> Plenty of people making their living as Access
> programmers wouldn't be able to figure out how it is accomplished.[/color]

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]

Re: Function vs Sub /Public vs Private


lauren quantrell wrote:[color=blue]
> 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[/color]

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]

Re: Function vs Sub /Public vs Private

"David W. Fenton" wrote
[color=blue]
> I've never seen any noticeable
> difference in peformance with
> module-less forms.[/color]

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]

Re: Function vs Sub /Public vs Private

"rkc" wrote
[color=blue]
> 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.[/color]

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]

Re: Function vs Sub /Public vs Private

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]

Re: Function vs Sub /Public vs Private

downwitch wrote:
[color=blue]
> 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.
>[/color]

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