By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,986 Members | 2,030 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,986 IT Pros & Developers. It's quick & easy.

What's the default choice if Public/Private is ommited from the Sub statement?

P: n/a
MLH
What's the default declaration if Public/Private is ommited
from the Sub statement in an Access 97 procedure?
Nov 13 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
MLH <CR**@NorthState.net> wrote in
news:5q********************************@4ax.com:
What's the default declaration if Public/Private is ommited
from the Sub statement in an Access 97 procedure?


Easily tested. Paste this into a module:

Sub TestMe()
MsgBox "It worked!"
End Sub

and then see what happens when you call it from the Debug
window.

Now, paste the same sub into a form's module, open the form and call
it as:

Forms!frmMyForm.TestMe

You'll see that there's consistency of result between the two
contexts.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #2

P: n/a
For the code behind a Form, the default is "Private".
In a Module, the default is "Public".

MLH wrote:
What's the default declaration if Public/Private is ommited
from the Sub statement in an Access 97 procedure?


Nov 13 '05 #3

P: n/a
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in
news:11********************@g49g2000cwa.googlegrou ps.com:
MLH wrote:
What's the default declaration if Public/Private is ommited
from the Sub statement in an Access 97 procedure?


For the code behind a Form, the default is "Private".
In a Module, the default is "Public".


In what sense is that the case?

If you ran the test that I posted, you'd see that your answer is
misleading, as undeclared subroutines are public by default.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #4

P: n/a
David W. Fenton wrote:
In what sense is that the case?

If you ran the test that I posted, you'd see that your answer is
misleading, as undeclared subroutines are public by default.


Can someone (davis, Chuck, anyone) give an example of when a public
procedure in a FORM is necessary and works?

In the past, I've sometimes written a proc or two that would be nice to
be available to all other forms open at the same time a particular form
is open, with an error trap on the calling form to say ("you must have
such and such a screen open to perform this task") but I've never been
able to have a function/sub declared public on a form module accessible
by other forms. So anything I want accessible by more than one form, I
pop into a standard module.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Nov 13 '05 #5

P: n/a
rkc
Tim Marshall wrote:
David W. Fenton wrote: In the past, I've sometimes written a proc or two that would be nice to
be available to all other forms open at the same time a particular form
is open, with an error trap on the calling form to say ("you must have
such and such a screen open to perform this task") but I've never been
able to have a function/sub declared public on a form module accessible
by other forms. So anything I want accessible by more than one form, I
pop into a standard module.


Forms.Form1.methodCall()

or

dim f as access.form
set f = Forms.Form1
f.methodCall
The way I see things, a public method in a form should perform some
kind of operation on that form. If it doesn't it's not really a
member of that object so it belongs in a module.


Nov 13 '05 #6

P: n/a
rkc wrote:
have such and such a screen open to perform this task") but I've never
been able to have a function/sub declared public on a form module
accessible by other forms.
Forms.Form1.methodCall()

dim f as access.form
set f = Forms.Form1
f.methodCall


Ahhhhhh! I've simply just put the name of the proc down, without
reference to the form. There ya go! 8)
The way I see things, a public method in a form should perform some
kind of operation on that form. If it doesn't it's not really a
member of that object so it belongs in a module.


I'd agree with that.

Thanks!
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Nov 13 '05 #7

P: n/a
MLH
Based on a summarization of what I've read in
all your posts, I think it best that I begin explicitly
declaring them public or private as deemed
needed.

I have not been doing so. It appears to be good
programming practice.
Nov 13 '05 #8

P: n/a
MLH <CR**@NorthState.net> wrote in
news:ca********************************@4ax.com:
Based on a summarization of what I've read in
all your posts, I think it best that I begin explicitly
declaring them public or private as deemed
needed.

I have not been doing so. It appears to be good
programming practice.


It's always good programming practice to explicitly declare anything
at all.

And you should also make the scope/data types as narrow as possible
to get the job done.

Asking yourself the question "should this be public?" or "should
this be a variant or a string?" requires addressing a whole lot of
issues outside the narrowest scope of the problem you are addressing
with the code you're writing. Getting in the habit of asking
yourself what the narrowest definitions can be will help make your
code better.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.