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

Eval error 2431

P: n/a
ray
I am calling a function using eval. It runs in a form module, in
response to a button OnClick.

strCall = "Forms!frmSchedule.eval" & strSName(0) & "()"
On Error Resume Next
n = Eval(strCall)
For the purposes of testing, strSName(0) is always = "LoanType"

The function evalLoanType runs ok, and doesn't generate an error.

However, when control return to the calling routing above, n is always
Empty and Err.Number = 2431, that is, "The expression you entered
contains invalid syntax."

Could anybody help me resolve this so that it returns the correct value
of the function, and doesn't produce an error? The error value is a
problem because I still need to trap situations where a function named
by the variable doesn't exist.

Thanks,

Ray


Function evalLoanType() As Integer
On Error GoTo eLT_Err
If Not PositiveInteger(Me!ScheduleNoOfParties) Then
MsgBox "Please enter the Number of Parties.", vbInformation, "Data
Entry"
evalLoanType= -1
Else
evalLoanType= 0
End If
eLT_Exit:
Exit Function
eLT_Err:
MsgBox Err.Description & vbCrLf & vbCrLf & "Cannot evaluate number
of parties." Resume eLT_Exit
End Function

May 29 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a
OTTOMH

Public Function evalLoanType() As Integer

n = Form_frmSchedule.evalLoanType()

May 29 '06 #2

P: n/a
ray
Thanks Lyle!

Sadly though, it didn't woik. Eval seems to run the function only if
you have it referenced as Forms!FormName.functionname().

If you have anything else OTTOYH I would be glad to hear it. Or
OTTOAE'sH for that matter,

Ray

May 30 '06 #3

P: n/a
I appreciate that you have tired and reported but I did not write about
Eval. I wrote about

1.ensuring the function is Public

2. setting the value of n to that returned by
Form_frmSchedule.evalLoanType() .

Eval is a silly little hack for non-programmers to use. In however many
years (14?) with Access I have never used Eval (TTBOMR).

May 30 '06 #4

P: n/a
Unless you are using A97, you want to use CallByName
instead of using Eval:

set frm = Forms("frmSchedule")
CallByName
frm,
"evalLoanType",
VbMethod

you don't want to do use eval because a bug in the
current implementation of eval causes it to evaluate
object methods twice when run once.

You can only call a form method if it is public,
and only if the form is open.

(david)


<ra*@aic.net.au> wrote in message
news:11**********************@38g2000cwa.googlegro ups.com...
I am calling a function using eval. It runs in a form module, in
response to a button OnClick.

strCall = "Forms!frmSchedule.eval" & strSName(0) & "()"
On Error Resume Next
n = Eval(strCall)
For the purposes of testing, strSName(0) is always = "LoanType"

The function evalLoanType runs ok, and doesn't generate an error.

However, when control return to the calling routing above, n is always
Empty and Err.Number = 2431, that is, "The expression you entered
contains invalid syntax."

Could anybody help me resolve this so that it returns the correct value
of the function, and doesn't produce an error? The error value is a
problem because I still need to trap situations where a function named
by the variable doesn't exist.

Thanks,

Ray


Function evalLoanType() As Integer
On Error GoTo eLT_Err
If Not PositiveInteger(Me!ScheduleNoOfParties) Then
MsgBox "Please enter the Number of Parties.", vbInformation, "Data
Entry"
evalLoanType= -1
Else
evalLoanType= 0
End If
eLT_Exit:
Exit Function
eLT_Err:
MsgBox Err.Description & vbCrLf & vbCrLf & "Cannot evaluate number
of parties." Resume eLT_Exit
End Function

May 30 '06 #5

P: n/a
ray
Thanks again, folks.

I have been working in Access for a similar length of time to Lyle and
avoided Eval simply because it looked a bit of an orphan. However, the
current situation called for function names passed as strings. Lyle, I
certainly did try making the function Public, and changed the
referencing as you suggested - I just didn't cotton on to the
distinction that you had made with regard to calling the function. I
take all suggestions made in this newsgroup seriously and try them out
as best as I understand them - comp.databases.ms-access is a major
lifeline for me in my business and I try and drop a few suggestions or
solutions back in when I am capable.

Fabulously, though, CallByName, which I had never come across before,
works an absolute treat. Thanks David!

Ray

Jun 1 '06 #6

P: n/a
How long has CallByName been in Access? That's grand!

Thanks David!
Jun 1 '06 #7

P: n/a

<w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t> wrote in message
news:EX********************@newssvr29.news.prodigy .net...
How long has CallByName been in Access? That's grand!

Thanks David!


Yes, the help system in Access is pretty helpless... I would never have
found it, but for 'Schof' in microsoft.public.access. I think it was better
known to VB programmers.
(david)
Jun 1 '06 #8

P: n/a
david epsom dot com dot au wrote:
Unless you are using A97, you want to use CallByName
instead of using Eval:

set frm = Forms("frmSchedule")
CallByName
frm,
"evalLoanType",
VbMethod

you don't want to do use eval because a bug in the
current implementation of eval causes it to evaluate
object methods twice when run once.

You can only call a form method if it is public,
and only if the form is open.


Please, try

CallByName Form_frmSchedule, "evalLoanType", VbMethod

when frmSchedule is not open and no reference/pointer to it has been
initialised.

Jun 1 '06 #9

P: n/a
>
On 31-May-2006, "david epsom dot com dot au" <david@epsomdotcomdotau> wrote:
the help system in Access is pretty helpless...

No argument there. It was excellent back in 2.0 and has been going downhill
ever since.

In 2.0 you could actually learn how to develop by using the help file. Its
only sin was that it mixed user and developer help, but even that was done
in a fairly predictable manner. As the help has moved more and more in the
modern direction it has suffered tremendously IMO.
Jun 1 '06 #10

P: n/a
Wow! Thanks for this info. Both of these worked:

1. call forms("form2").sayhello
2. callbyname form_form2, "sayhello",VbMethod

I made form2, with a public function named SayHello().

If I open the form, then line 1 works just fine. (All of this is in the
immediate window of course.) Whether the form is open or closed, line 2
works just fine.

Slick.
Jun 1 '06 #11

P: n/a

Rick Wannall wrote:
Wow! Thanks for this info. Both of these worked:

1. call forms("form2").sayhello
2. callbyname form_form2, "sayhello",VbMethod

I made form2, with a public function named SayHello().

If I open the form, then line 1 works just fine. (All of this is in the
immediate window of course.) Whether the form is open or closed, line 2
works just fine.

Slick.


Form_Form2.sayhello

Jun 1 '06 #12

P: n/a
Cool. Thanks.
Jun 1 '06 #13

P: n/a
Yes, I was wrong.

(david)

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11**********************@c74g2000cwc.googlegr oups.com...
david epsom dot com dot au wrote:
Unless you are using A97, you want to use CallByName
instead of using Eval:

set frm = Forms("frmSchedule")
CallByName
frm,
"evalLoanType",
VbMethod

you don't want to do use eval because a bug in the
current implementation of eval causes it to evaluate
object methods twice when run once.

You can only call a form method if it is public,
and only if the form is open.


Please, try

CallByName Form_frmSchedule, "evalLoanType", VbMethod

when frmSchedule is not open and no reference/pointer to it has been
initialised.

Jun 2 '06 #14

P: n/a
david epsom dot com dot au wrote:
Yes, I was wrong.


Regardless the information you gave was helpful. I had not experimented
with CallByName before your post. It has an advantage over calling a
form's public methods or using its public properties directly as in
Form_Form1.Method1.

CallByName Form_Form1, "Method1", VbMethod, "Parameter1"
opens Form1(if it's not already open), runs Qwerty and closes Form1(if
it opened it).

Form_Form1.Method1does not do the closing and this must be looked after
by the coder.

I note that either of these is useful for dealing with subforms and
avoids the lengthy form.control.form whatever syntax; the simple
Form_Form1. syntax provides us with Intellisense when coding while
CallByName I think, does not.

It may be worthwhile to note that if one opens an array of instances of
a form each method will open a new distinct instance of the form to do
its work

Thanks for telling us about this; I had missed it.

Jun 2 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.