Program Progress will not stop at breakpoint

[Micron]

You are confusing Run Time errors with compile errors. They are not the same. Only when code runs do things like concatenations get evaluated. Compile errors are more object oriented. Can't recall about the effects of mis-managed methods. May you should delve into it more.

[John_G]

Good questions - I'll do my best.

But if the syntax was wrong why didn't the compiler catch it?

The compiler doesn't do any checking inside quotation marks. So, when checking "[PersonnelID] = " & [Forms]![frmPersonnel].[PersonnelID] & " [isActive] = true", the compiler "sees" only "string1" & [Forms]![frmPersonnel].[PersonnelID] & "string2", which is perfectly valid. It doesn't know that the expression, when expanded, is not a valid "Where" expression, so the error is only caught at runtime.

Also, I thought calling a function with no arguments in VBA was simply the name of the function with no arguments.

Most of the time, that is the case, you can just use the function or sub name. However, referencing a function as an event response is an exception - the () have to be there so that Access knows it is a function reference and not a macro name.

As I said, I don't ever use macros, so I don't know how the arguments part work. However, when it comes to functions and subs, the number and data types in the function definition,

Function Sample (argument list) as Integer, and the function call e.g. msgbox "Sample = " & Sample(argument list) must match^**. If you are not sure, use the function definition as the guide.

In your case, the function definition of FormHeading is Function FormHeading(), so it takes no arguments.

It appears that I must replace & with AND.

Not quite - the quotes were OK - but the AND was missing, so you are just adding something, not replacing.

^** There are ways of having exceptions to that, but I will not get into them here.

[Lou_Reed]

It seems on this one that it is a good idea to reference a function always as

Function_name(). Not Function_name

That way you are always covered.

Any thoughts.

Any help appreciated. Thanks in advance.


Respectfully,


Lou Reed

[John_G]

It seems on this one that it is a good idea to reference a function always as Function_name(). Not Function_name

No, leave the () out. If you write a line of code like this: FormHeadings(), you will get a compiler error. Function and Sub references written like that (by themselves on a line) cannot have the (), even if they DO have arguments, so a function/sub call might look like this: Myfunction argument1, argument2

[Micron]

AFAIK, the only times you must have () after a function is
- if you use the Call keyword and there are parameters
e.g. Call MyFunction (1234)
vs MyFunction 1234

- or if the function is being assigned to a variable and you are passing parameters.
Result = MsgBox ("My Message", vbYesNo, "Title")
vs Msgbox "My Message", vbYesNo, "Title"

This will generate an error: Msgbox ("My Message", vbYesNo, "Title")
so I do not think it's a matter of being able to just use them for the sake of being on the "safe" side, or however you want to put it.

[John_G]

- or if the function is being assigned to a variable and you are passing parameters.
Result = MsgBox ("My Message", vbYesNo, "Title")
vs Msgbox "My Message", vbYesNo, "Title"

Another way of looking at that is that anywhere you are using the return value if a function that has parameters, then you need the (). For example:

if MsgBox ("My Message", vbYesNo, "Title") = vbYes then ...

[Micron]

anywhere you are using the return value if a function (that) has parameters

probably a better way of saying it. Typically, I guess I used to write the "Result =" part first, then had "If Result ="

[Lou_Reed]

I tried the suggestion that you can write function call even with functions that have no arguments like this.


Call FormHeading()


It did not work. When I saved it I got


Call FormHeading


with no parenthesis, the code would compile, but I then got a run time error when I ran the code (opened the form associated with the code)..

So I just went back to calling a function with no arguments like this:


FormHeading


That was what I used originally, so I guess that is what I will keep in.

None of my function call have arguments. So this should be okay.

Please verify.

Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[Lou_Reed]

I am hopefully finishing up the db. I want to address the issue in the frmPersonnel combo box to select a person/employee to remove.

[Quote]
Since I can never open LR's databases, I can only wonder about things. Like
- why is an empty string being passed as the searchforrecord object name?
- is [PersonnelID] a number yet the combo contains a name?
- is the message box referring to a control I can't see ([FullName]) yet the active control that apparently holds the desired value is a combo box (the control related to the event code)?
- do any of these factors result in a Where criteria that is not met, thus the focus stays on the current record??? That is the behavior of this method.
[#Quote]

I need to address these items (I am assuming) in order to get this combo box to work right.

The first is

is [PersonnelID] a number yet the combo contains a name?

What is wrong with this? This was again a macro to VBA translation.


Any help appreciated. Thanks in advance.

Respectfully,

Lou Reed

[John_G]

is [PersonnelID] a number yet the combo contains a name?

The combo box is OK. The visible data is the name, but the [PersonnelID] is also in it as an invisible column. The combo box takes its value from this invisible numeric column (i.e. the invisible column is the bound column). This is a very common use of a combo box, where what the use sees is not necessarily the value Access uses.

[Lou_Reed]

Okay, but here is the quote that I am talking about:

is [PersonnelID] a number yet the combo contains a name?

How I connect/program this up so that the name that I select from the combo box is the name that shows up in the warning dialog box and if I choose to delete this name, then it is the one deleted.
and only that name is deleted?

Respectfully,

Lou Reed

[Micron]

I looked through all the replies and cannot see where you were told this

I tried the suggestion that you can write function call even with functions that have no arguments like this.
Call FormHeading()

but I can find that you were explicitly told in post #19 that you could not do this

Re: your question -
"is [PersonnelID] a number yet the combo contains a name?"
What is wrong with this? This was again a macro to VBA translation.

The inference is that an ID field is usually a number; the combo contains a name to search on, yet there were no quotes in the concatenation that surrounded the reference to the control that contains that name. In other words, I suspected the concatenation was like John Smith when it should be 'John Smith'.
John_G explained that the combo is not bound to a text field (the name), but rather a number field so it is OK. Had you not posted your db, it would be incumbent upon you to explain which column was bound and what its data type is. This leads me to a conclusion that I'll get to after addressing your question.

What you probably should be focused on is the last question from post #10. If the filter for the SearchForRecord method is invalid, the result will be to stay on the current record. Since I cannot examine the db, I cannot tell if your filter statement resolves to anything or not. Which brings me to this conclusion: I think it would be best if I refrained from commenting on any of your posts where an examination of the design is required since all I seem to do is introduce confusion.

[Lou_Reed]

Micron:

I was using the function call like this:

FormHeading

I was told it was okay, but not in this instance of code. I should call the function.

So I tried

Call FormHeading()

The open-close parenthesis was removed off when I saved the code and I got this

Call FormHeading.

and this gave me a runtime error, when I opened its associated form. So what could I do then. I just went back to what I was doing before, ie.:

FormHeading


I would love to use the recommend alternative that works.

I do not know what works now.

Somewhere, I was told the I could do this (or at least I interpreted it that way):

Call function_name(arg1,arg2)

Well I had no arguments and I just used

Call function_name()


As I said before, when I saved it, it dropped the ().

Then when I opened the form associated with this code:

I got a runtime error.

Then I dropped the Call from the line and just used

FormHeading

Which is what I had before. The complier did not complain and upon opening the form associated with the code I got no
runtime error.

So I must assume at least that way is the correct way.

If there is way better way please tell me. I need to know it.

Respectfully,

Lou Reed

[Micron]

It has been said here that these are allowed:
Call myFunction (arg1, arg2)
myFunction arg1, arg2

It was also said that Call myFunction() is not allowed. Really, it doesn't matter what you tried if it wouldn't compile, it wasn't allowed.
Maybe you should review https://msdn.microsoft.com/en-us/vba...ion-procedures. IMHO, the statement there
The Call statement is not required, but if you use it, you must enclose any arguments in parentheses.
should have been written as
The Call statement is not required, but if you use it, you must enclose arguments in parentheses.

[Lou_Reed]

Okay, but I cannot use something like

FormHeading

in that syntax to call a function after an event?

After an event?

Respectfully,

Lou Reed