[AccessD] A couple of syntax questions

John Colby jwcolby at gmail.com
Sat Jan 15 17:50:17 CST 2022


Arthur, I think you are right... mostly.  You can declare things many
different places.  Inside of functions, it is private and cannot be
otherwise.  As for headers of modules, if not specifically labeled private
it is public.  Of course stuff in a class only exists when the class is
instantiated.

On Sat, Jan 15, 2022 at 6:39 PM Arthur Fuller <fuller.artful at gmail.com>
wrote:

> Rocky,
> I think that tiy are wrong about Point 1. You can declare a sub or function
> without the words Private/Public; that suggests that without the word
> Private it will default to Public. But I've wrong before. Aside from that,
> I'm pretty much aligned with your strategies. I have too many reusable subs
> and functions to house in a single module, but aside from that, I'm totally
> on board..
>
> On Sat, Jan 15, 2022 at 5:18 PM Rocky Smolin <rockysmolin2 at gmail.com>
> wrote:
>
> > 1/. AFAIK, Public or Private have to be used to declare what follows is a
> > sub of function.  It's either/or.
> >
> > 2. I have a module called Publics.  That's where I put all of the Public
> > subs and functions. Makes them easy to find. Keeps your code neater and
> > more maintainable. (What if you delete a form or report that's not needed
> > anymore that contains a public sub or function in the cbf and forget to
> > check for it? You won't know it until some other sub or function tries to
> > call it.). So the answer is it doesn't matter.  Until it does.
> >
> > 3. When I have to do this and there are lots of changes being built into
> > the new version, I import them as I need them. Keeps it clean and leaves
> > the garbage behind.
> >
> > HTH
> >
> > r
> >
> > On Sat, Jan 15, 2022 at 1:26 PM Arthur Fuller <fuller.artful at gmail.com>
> > wrote:
> >
> > > 1. If a procedure or function declaration is not declared Private, is
> it
> > > thus Public?
> > > 2. More a style question than a syntax question. Concerning the code
> > behind
> > > a form, it sometimes happens to me that I realize that the body of what
> > was
> > > a Private function could be extracted and turned into a public sub or
> > > function and reused elsewhere. Instinct tell me that this reusable sub
> or
> > > function should be moved outside the form's code and placed elsewhere.
> > > Correct, or doe it not matter?
> > > 3. Preamble: I have a collection of modules containing code that I'll
> > need
> > > in most if not all serious projects (by serious I mean 100+ tables, as
> > many
> > > basic forms to address the lookup tables etc., many more queries, and
> > then
> > > all the master-detail forms). I have gather all these into a a
> database.
> > > Beginning a new project, I typically import all these functions and
> subs.
> > > Is there a better way, such as creating a library and referencing it,
> > > similar to the #include and "Uses" statements in other languages
> > >
> > > On another note, when I converted an app to 64-bit, I discovered that
> > Rick
> > > Fisher's *Find and Replace* no longer worked. A little searching i
> Google
> > > led me to AccessDevTools' *Find and Replace. * They have a trial
> version,
> > > which I downloaded, tried for two days,and promptly bought a license.
> > This
> > > product far surpasses; this is not meant as a slam on Rick's original
> > > product, not at all. For years regarded it as an essential tool. But
> now
> > in
> > > the era of 64 and with the benefit of time, this product goes far
> beyond.
> > >
> > > --
> > > Arthur
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > https://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > https://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


-- 
John W. Colby
Colby Consulting


More information about the AccessD mailing list