Declaring Public Const

[Robert]

Hello

I want if possible declare a constant like this :

Public Const T_PATH As String = CatchParam("P_PATH", 0)


CatchParam("P_PATH", 0) will return "C:\Access\"
What I want to do is that all paths are stored in an external DB (not linked
in currentDB) and with a function i retrieve the value over SQL.

Sure I can call CatchParam("P_PATH", 0) each time I need it but wanted to do
this 1 time to reduce performance. But the Public Const T_PATH As String =
CatchParam("P_PATH", 0) is not working

Thanks for any ideas and helps

 

[Alex Dybenko]

hi,
no, you can’t declare it that way, you have to declare public variable, set
it to CatchParam("P_PATH", 0) at strartup and then use it

Public T_PATH As String

sub main()
T_PATH = CatchParam("P_PATH", 0)
....

--
Best regards,
___________
Alex Dybenko (MVP)
http://accessblog.net
http://www.PointLtd.com

 

[Stuart McCall]

Hello

I want if possible declare a constant like this :

Public Const T_PATH As String = CatchParam("P_PATH", 0)


CatchParam("P_PATH", 0) will return "C:\Access\"
What I want to do is that all paths are stored in an external DB (not
linked
in currentDB) and with a function i retrieve the value over SQL.

Sure I can call CatchParam("P_PATH", 0) each time I need it but wanted to
do
this 1 time to reduce performance. But the Public Const T_PATH As String =
CatchParam("P_PATH", 0) is not working

Thanks for any ideas and helps

CatchParam is a user defined function and as such it must be evaluated at
runtime. Constants are just that - they remain constant throughout the life
of the application, and must be set before the 'program' runs, therefore you
can only assign literal values to them.

Public Const T_PATH As String = "C:\Access\"

would work (but I'm aware that's not what you want.

Instead of a Const, declare T_PATH to be a public variable.

 

[vanderghast]

Declare a property with a Get accessor, without Let/Set Accessor.


======= In a module, all of its own========
Option Explicit
Option Compare Database

Private m_TPath As String

Public Property Get TPath() As String
If 0 = Len(m_TPath) Then
m_TPath = CatchParam("P_PATH", 0)
End If
TPath = m_TPath
End Property
================================



The disavantage, over a public variable, is more (explicit) code (although a
public variable is implemented, for you, by COM, as a Let/Get property).

The advantage is that it is read only, I mean, elsewhere in your code, you
CAN'T assign TPath, so it appears as a constant. Note, though, that in the
same module, you can change the variable behind the property, whcih is the
same as modifying TPath, but that variable is only accessible in THAT same
module.



Vanderghast, Access MVP

 

[Douglas J. Steele]

Can you do that in a module, Michel? I thought it had to be a Class Module.
which would mean you'd have to instantiate the class in order to use the
value.

If it can be done in a module, how do you refer to the property?

 

[vanderghast]

It can be done in a standard module, indeed.

You call it as if it was a method.



Vanderghast, Access MVP

 

[vanderghast]

Note that someone can also simply use a standard function, instead of the
property. The difference between a Read Only property and a function is
rather thin.


Vanderghast, Access MVP

 

[David W. Fenton]

Note that someone can also simply use a standard function, instead
of the property. The difference between a Read Only property and a
function is rather thin.

It seems to me that it's confusing in a standalone module, as it
raises the question: property of what?

 

[vanderghast]

Technically, you can see it as a property of the 'library'.

Note that a global module variable in a module *IS* a Get/Let property once
COM exposes it to other modules.




Vanderghast, Access MVP

 

[David W. Fenton]

Technically, you can see it as a property of the 'library'.

Where? In the Object Browser? Yes, that's how it shows up, but it's
completely indistinguishable from a function. I can't see the point
of using a property.

Note that a global module variable in a module *IS* a Get/Let
property once COM exposes it to other modules.

Er, no, public variables are *members* not properties at all.

 

[vanderghast]

'Variables' are members (or fields) of a class, and probably by extension we
can say the same for modules, that is OO terminology, but what I pointed out
was that COM, on which is based Access-VBA since at least 2000, does NOT
expose 'variables' and so, COM, TECHNICALLY, uses properties to handle
module public variables.


A writeable property is clearly different than a function. So I assume you
meant read only properties. A read only property is indeed quite similar to
a function, and generally to choose between a read only property and a
function is a matter of 'relation' and sometimes about the 'amount of
computation'. As example, in general, a random number generator would sound
strange for a property, because the randomness is hardly owned by anything;
and a name is probably better as a property than as a function. But in the
end, it is a matter of preference, I agree.


Vanderghast, Access MVP

 

[David W. Fenton]

A writeable property is clearly different than a function.

I thought the only thing we were discussing was read-only
properties.

So I assume you
meant read only properties. A read only property is indeed quite
similar to a function,

I see no reason to use a property Get for a read-only return value
in a standalone module. In a class module, whether standalone or
not, yes, it makes perfect sense, as it is a property of the object.
In a standalone module, it's publicly available (if it's public; if
it's not it's available only in that module, and that makes even
less sense to me).

and generally to choose between a read only property and a
function is a matter of 'relation' and sometimes about the 'amount
of computation'. As example, in general, a random number generator
would sound strange for a property, because the randomness is
hardly owned by anything; and a name is probably better as a
property than as a function. But in the end, it is a matter of
preference, I agree.

I write a lot of functions that initialize from some value looked up
or supplied from literal values, and stick the looked up value in a
static variable inside the function. Here's an example:

Public Function Workstation() As String
Static strWorkstation As String

If Len(strWorkstation) = 0 Then
strWorkstation = fstrGetWorkstation()
End If
Workstation = strWorkstation
End Function

This is not something that needs to be queried from the OS each
time, as it can't possible change within a single Access session.
Also, while I'm coding in an MDB, this kind of code is self-healing,
whereas something that depends on a module-level variable getting
assigned and staying assigned will not work as well.

I also like having the variable defined inside the function that
uses it, instead of in the module-level variables. That has two good
side effects:

1. it's internal to the function and quite clearly associated with
it.

2. it can't be changed from outside the function, accidentally or
otherwise, unless you have an argument for your function that allows
you to do that.

To me, these are functions, returning values looked up from
elsewhere, not properties of an object within your application.
Thus, they should be defined as functions, not as properties (even
though defining as properties would have exactly the same effect in
terms of use in code).