Call: Is it necessary?

[lotus18]

Hello World

Using a Call is it necessary? You can call a function without using that keyword right? Second question, which performs faster, using a Call or not?

Rey Sean

[debasisdas]

Specifying CALL is optional and is agood practise to use in programming.

That does not involve any performance issue.

[Killer42]

Specifying CALL ... is agood practise to use in programming.

That is entirely a matter of opinion. You would hardly expect to use CALL before every statement, so why pick out particular ones?

Surely the whole point of an extensible language is that the extensions are integrated into it seamlessly, and don't require special coding to use.

[cugone]

Using the Call statement is more of a readability preference than anything.

Be aware though, that it's only safe to use it on Subroutines, not Functions, as when it's used on Functions it causes the returned value to be ignored.

[Killer42]

Using the Call statement is more of a readability preference than anything.

I'm curious about which way you mean that. I generally find the code much more readable without the Call.

[debasisdas]

My understanding is CALL should be used to call sub procedures not other event procedures and functions.

It make the code more readable in the sense that while going through the code it can be easily find out . It specifies that anything following that keyword is a sub procedure. It specially comes handy while someone else is going through your code. Specially in maintenance projects.

[lotus18]

It specially comes handy while someone else is going through your code. Specially in maintenance projects.

You have the point. : )

Rey Sean

[werks]

Hello World

Using a Call is it necessary? You can call a function without using that keyword right? Second question, which performs faster, using a Call or not?

Rey Sean

I agree with debasisdas, it is much easier to identify if you use Call


Better Than Yesterday ^^

[jamesd0142]

For what it's worth i agree with killer42, I prefer to read and write code without writing "call".

I believe it's a preference that will differ between programmers.

And here's my reason for posting:

Is it right if you use call to call a function the return value is ignored? I was unaware of this.

Does this not remove the whole point of calling a function?

[Killer42]

For what it's worth i agree with killer42, I prefer to read and write code without writing "call".

I believe it's a preference that will differ between programmers.

My point is that with an extensible language such as this, once you create a Sub or Function it effectively becomes part of the language. It's a "black box", presumed to have been tested and working. There should be no need to differentiate by using a special type of call. The name of the routine should be enough to tell you what it does. If there's any question about where the routine comes from, a simple keypress will tell you.

Is it right if you use call to call a function the return value is ignored? I was unaware of this.

Does this not remove the whole point of calling a function?

Well, yes and no. If you need the return value, then sure, it defeats the purpose. But keep in mind that since the function can contain any code you like, it may actually do something. You may want to treat it like a Sub in certain circumstances and not bother with a returned value.

The MsgBox function is a prime example. You can use it to prompt the user and determine what button they clicked. Or you can just show a message and wait for the user to click OK. Do you need to know that they clicked OK?

Examples...

  Dim UserResponse As Long
 
  ' Before performing some action...
  UserResponse = MsgBox("Are you sure?", vbYesNoCancel, "Confirm Action")
 
  ' After performing some action...
  MsgBox "Finished!"
 

[kadghar]

Hope any of you know why this happens.

[Killer42]

Hope any of you know why this happens.

Yes, that was a very simple one. The OP had put unnecessary parentheses around the argument list in the "call". All they needed was to remove them.