Extra Parameter

[Cullen411]

If I have a sub that is called and sometimes it has a blind carbon copy parameter should I create two subs as below? Or is there a better way to do it. One other thing that I have come across is the concept of overloading - should I just call the subs the same name?

Sub SendEmail(sFrom,sTo,sSubject, sBody)
Set NewMailObj=Server.CreateObject("CDONTS.NewMail")
NewMailObj.From=sFrom
NewMailObj.To = sTo
NewMailObj.Subject = sSubject
NewMailObj.Body = sBody
NewMailObj.BodyFormat = 0
NewMailObj.MailFormat = 0
NewMailObj.Send
Set NewMailObj=Nothing
End Sub

Sub SendEmailBCC(sFrom,sTo,sSubject, sBody, sBCC)
Set NewMailObj=Server.CreateObject("CDONTS.NewMail")
NewMailObj.From=sFrom
NewMailObj.To = sTo
NewMailObj.BCC = sBCC
NewMailObj.Subject = sSubject
NewMailObj.Body = sBody
NewMailObj.BodyFormat = 0
NewMailObj.MailFormat = 0
NewMailObj.Send
Set NewMailObj=Nothing
End Sub

 

[theniteowl]

You should be able to do this with a single sub, you just do not send in a value for sBCC if you do not want one sent.

Paranoid? ME?? WHO WANTS TO KNOW????

 

[Cullen411]

It doesn't appear to work, I get -

Microsoft VBScript runtime error '800a01c2'

Wrong number of arguments or invalid property assignment: 'SendEmailBCC'

Is there no way around this apart from creating 2 subs?

 

[theniteowl]

Well, when you are making the call to the sub, make sure you set a blank value for sBCC like sBCC="".
It is probably choking because it is null.



Paranoid? ME?? WHO WANTS TO KNOW????

 

[emozley]

Can you just not use an If...Then?

Sub SendEmail(sFrom,sTo,sSubject, sBody, sBCC)
Set NewMailObj=Server.CreateObject("CDONTS.NewMail")
NewMailObj.From=sFrom
NewMailObj.To = sTo

If sBCC <> "" Then
NewMailObj.BCC = sBCC
End If

NewMailObj.Subject = sSubject
NewMailObj.Body = sBody
NewMailObj.BodyFormat = 0
NewMailObj.MailFormat = 0
NewMailObj.Send
Set NewMailObj=Nothing
End Sub

 

[theniteowl]

I would think so but it depends on where the failure occurs.
Is it when the function is called with a null value passed or is it when the NewMailObj.BCC value is set with the null?

Most of my ASP code has been straight top-down code.
I know null values can be a pain but no certain at what point it causes this particular error.

cullenn411, you could set the value at the top of your code like: sBCC = "". Then it will not be null. Whether or not you ever set it to any other value it should still work in your function.
At least I THINK it would. I am interested to find out.


Paranoid? ME?? WHO WANTS TO KNOW????

 

[emozley]

To account for all possibilities you should be able to go:

If sBCC <> "" And IsNotNull(sBCC)=TRUE Then
NewMailObj.BCC = sBCC
End If

 

[Cullen411]

Hi yeap using
sBCC="" works when calling the sub..when I say it works it doesn't cause an error. I wouldn't have thought that it was good coding though. (don't know why just guessing).

I just recently came across the concept of overloading in VB.NET, I THINK it's when you use 2 functions subs with the same name though with different parameters - so I thought maybe this was a scenario where it would come into play. I ran a test and this appears not to work with VBScript, so I have the choice of 2 differently named subs or using the "" empty string.

 

[theniteowl]

Nulls are always a problem that you have to test for anyway.
By setting the variable to "" you just ensure it is not null.

emozley's method is just as valid, it tests within the Sub to see if the variable is blank or null and that determines if that mail object is even set at all.

I do not see how setting the value blank would be bad coding. It is actually shorter than most alternatives and more efficient in some ways. To use an IF Then statement is higher in overhead so your application slows down.
So instead of using IF Then to test every variable that might possibly be null you are better off just setting the value up front and overwriting it with other values later.

You are not likely to notice any performance difference in either method realistically. If you have a large application with LOTS of If Then tests to perfom then it shows up. For short bits of code it makes no difference.
And the If Then test is better if there is a possibility that the variable could somehow be SET to null during the execution of the application. This could easily happen if you were pulling the values from a database, so you would have to make certain that value was not null either during assignment or later when you go to use it.

We do not have .Net here yet and I have not read anything about overloading. It sounds inefficient to have multiple subs or functions with the same name and similar function though. Perhaps it is like Javascript where you have multiple fields with the same name or ID and they get treated as arrays?
Just guessing.


Paranoid? ME?? WHO WANTS TO KNOW????

 

[Rhys666]

Operator Overloading

Methods, instance constructors, indexers, and operators are characterized by their signatures:

The signature of a method consists of the name of the method and the type and kind (value, reference, or output) of each of its formal parameters, considered in the order left to right. The signature of a method specifically does not include the return type, nor does it include the params modifier that may be specified for the right-most parameter.
The signature of an instance constructor consists of the type and kind (value, reference, or output) of each of its formal parameters, considered in the order left to right. The signature of an instance constructor specifically does not include the params modifier that may be specified for the right-most parameter.
The signature of an indexer consists of the type of each of its formal parameters, considered in the order left to right. The signature of an indexer specifically does not include the element type.
The signature of an operator consists of the name of the operator and the type of each of its formal parameters, considered in the order left to right. The signature of an operator specifically does not include the result type.
Signatures are the enabling mechanism for overloading of members in classes, structs, and interfaces:

Overloading of methods permits a class, struct, or interface to declare multiple methods with the same name, provided their signatures are unique within that class, struct, or interface.
Overloading of instance constructors permits a class or struct to declare multiple instance constructors, provided their signatures are unique within that class or struct.
Overloading of indexers permits a class, struct, or interface to declare multiple indexers, provided their signatures are unique within that class, struct, or interface.
Overloading of operators permits a class or struct to declare multiple operators with the same name, provided their signatures are unique within that class or struct.
The following example shows a set of overloaded method declarations along with their signatures.

interface ITest
{
void F(); // F()
void F(int x); // F(int)
void F(ref int x); // F(ref int)
void F(int x, int y); // F(int, int)
int F(string s); // F(string)
int F(int x); // F(int) error
void F(string[] a); // F(string[])
void F(params string[] a); // F(string[]) error
}
Note that any ref and out parameter modifiers (Section 10.5.1) are part of a signature. Thus, F(int) and F(ref int) are unique signatures. Also, note that the return type and the params modifier are not part of a signature, so it is not possible to overload solely based on return type or on the inclusion or exclusion of the params modifier. As such, the declarations of the methods F(int) and F(params string[]) identified above result in a compile-time error.

Rhys
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense Edsgar Dijkstra
If life were fair, Dan Quayle would be making a living asking 'Do you want fries with that?' John Cleese