(Assuming VB6 - )Not exactly; parentheses are used either when you are catching the return value of a function, or when you are invoking a function using the 'Call' keyword. So technophile's example would be:bln = MyFunc(str) ' save the return value.MyFunc (str) ' discard the return value, but still use - forces passing str by value.' around each variable individually.MyFunc (str1), (str2)' as above, passing each variable by value.MyFunc(str1, str2) ' error - you would need something to catch the return value.MyFunc str ' discard the return value, don't use - passes str by method defined by function.MySub str ' no return value.Call MySub(str) ' forces use of parens.Call MyFunc(str) ' ditto. I usually teach it as 'only use parentheses when you are using the return value in an expression or assignment'.There isn't a good reason that I'm aware of for using the Call statement in that manner instead of just directly calling the function or subroutine, so I tell people not to use it since it only makes their code more confusing to read.Likewise, I think it's dangerous to force by-value passing of parameters when that is defined by the method being called, so I tell people not to do that. Who knows better about how parameters should be passed to the method you are calling: you, or the author? Ok, now I'm really confused. I'm using a provided object and here is what I've encountered:Method w/ no return valueobjTelephone.AnswerobjTelephone.AnswerBoth of these workMethod w/ a return valueobjTelephone.HangUpobjTelephone.HangUpBoth of these workMethod w/ a return value and a parameterobjTelephone.PlaceCall(strPhoneNumber)This worksThis doesn'tobjTelephone.PlaceCall strPhoneNumberI'm not using the return values in any of these, so why is it that the last example I provided doesn't work while all the others do?
Quote:Originally posted by russ-iha:Any sub or function that takes parameters REQUIRES the parens.For VB6? The best solution is to do it in a language without such a bizarre and incomprehensible syntax.The Set/Let thing is just another example of this, it always confuses me when people say VB is an easy language to write.Why do they use Dim for variable declaration again? Isn't it because in the distant past you used dim to define the dimensions of an array, but now you use it to declare scalars also?At least VB managed to move away from line numbers and $variables, but it has introduced plenty of its own little nasties.I'd recommend C#, or even VB.net above VB, or JavaScript instead of VBScript for scripting with.If you can't move to.net, look at Delphi, or even Java as a better alternative. Oh yes, the land of the curly braces. Genius, really - View image here: -To be honest, the whole paren thing was so simple out of habit that I have never stopped to really think about when they are and aren't required. Shows what I know to try and describe it I suppose.Set was necessary to distinguish object references from other data types. The CLR and CTS make such a distinction unnecessary with VB.NET.
![Cannot use parentheses when calling a sub Cannot use parentheses when calling a sub](/uploads/1/2/5/4/125429398/534001851.jpg)
I don't know of anyone who used 'Let' in their code.Dim is 'dimension' = extend or magnitude; scope. Dim is used within subs or functions to declare a variable of local scope. Most often Private/Shared/Friend/Public are used for class-wide variables.I'll be the first to admit VB6 had its problems, but I still maintain that VB code is more maintainable and readable, especially to a programmer who had no hand in writing the original code.VB.NET fixes most of the problems anyone has bothered to come up with the language (other than whining about 'its different, and different is bad').
IIRC, 'Let' was carried over from VB's BASIC roots; 'Let x = 6' is, after all, natural English. 'Let' is not actually required. I think 'Dim' was carried over in the same way; 'Dim(ension) Variable As Type' is also natural English.' Set' was required because ambiguities might otherwise arise wrt.
What was being referred to:eg.Dim aCon As ADODB.ConnectionDim aVar1 As Variant, aVar2 As VariantSet aCon = New ADODB.ConnectionaCon1.Open CONNECTIONSTRINGaVar1 = aConSet aVar2 = aConIn this example, aVar1 holds aCon's default property (it's ConnectionString property) while aVar2 holds a reference to aCon itself. 'Set' was required because of this ambiguity due to default properties; VB.NET avoided this by forbidding parameter-less default properties.VB6 may not be perfect, but IMO it is hardly cursed with a 'bizarre and incomprehensible syntax' or 'plenty of its own little nasties'; a little reading tends to make things clear - View image here: -. Quote:Originally posted by Thanatos:Always use parentheses and you won't have to worry about this crap.That is so wrong. I hope you don't actually tell people this.Am I the only one on Ars who actually learned basic when it was called BASIC?Dim comes from array declaration. Scalar variable types were created as needed.
Arrays had to be allocated before they were used, so the dim syntax was used to specify how much space needed to be allocated.' Let' comes from the BASIC days, but except for.really. old versions of BASIC it has always been an optional keyword. It actually stems from the fact that computer science was a branch of mathematics at most universities. In math lingo you say 'Let x = 5', then you perform the steps to do whatever it was you were going to do.'
Not exactly; parentheses are used either when you are catching the return value of a function, or when you are invoking a function using the 'Call' keyword. So technophile's example would be: bln. Jun 09, 2013 Resolved Cannot use parentheses when calling a Sub If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed.
Set' is not a 'classic' BASIC keyword AFAIK. It was introduced when objects were introduced into VB, along with a bunch of other keywords like 'nothing', 'is', etc.This message was edited by wb on July 06, 2003 at 14:09.This message was edited by wb on July 06, 2003 at 14:10.
Quote:Originally posted by jym:quote:Originally posted by russ-iha:Any sub or function that takes parameters REQUIRES the parens.For VB6? You're calling this from VBScript? Then with 'objTelephone.PlaceCall strPhoneNumber', you're passing in a Variant (that's the only type that VBScript) to a method that takes (probably) a String passed ByRef; hence the type mismatch (requires string, gets variant).' ObjTelephone.PlaceCall(strPhoneNumber)', on the other hand, works because you override the method's defined passing method (by using the parentheses), and pass a Variant in ByVal; VB/COM then coerces your input to the required type, so avoiding the error.' ObjTelephone.PlaceCall CStr(strPhoneNumber)' would also avoid this error.In general, it is best to declare public methods of COM components as taking parameters ByVal (for this and other reasons).
Whoever coded objTelephone was either guilty of careless or lazy coding, or just didn't have a good enough understanding of VB6 and COM. Quote:Originally posted by SvendTofte:quote:Originally posted by wb:quote:Originally posted by Thanatos:Always use parentheses and you won't have to worry about this crap.That is so wrong.
I hope you don't actually tell people this.Why is this so wrong? If you always use them, you don't need to worry right? Of course, it's always nice to know what kinda tricks, you can do with a language, in a pure syntax way, but that doesn't make the statement wrong? Just curious, as I know jack about VB (and hate the syntax).It's not about any 'tricks' it's about proper VB syntax. If you use parens when you're not supposed to, bad things can happen. Take the following trivial example:Public Function isGhey(optional PBR as Double = 1.0, optional color as String = 'Pink') as Boolean.End FunctionNow if you call isGhey and you intend to use the return value, you need the parentheses, like so:amIGhey = isGhey(0.5, 'Fuscia')However, let's say isGhey also does some other stuff and we're not interested in the return value.
According to VB syntax, if we aren't using the return value, the parentheses will indicate grouping, rather than parameter passing. So, when we say:isGhey(0.25, 'Green')What VB interprets this as is:isGhey PBR=(0.25, 'Green'), color='Pink'This is a syntax error, and VB will complain. That is why it is wrong to say you should always use parentheses. Actually, if you consult the MS site, they recommend always using parenthesis and using the Call keyword to overcome the function vs.
Method syntax. It makes the automatic conversion to VB.NET easier - View image here: -BTW, if using parens all the time was such a bad idea, I have to wonder why they made you do it in VB.NET??1. Always use parens or you will suffer function/method hell. The Call keyword was invented for a reason.2. Never override the method byval/byref parameter passing convention, or you shall suffer in hell for all eternity. Either 1) the method creator did it for a reason and thus you should not screw with it, or 2) the method creator was an idiot and thus you should use another method - View image here: -TheJetP.S.
![Cannot Use Parentheses When Calling A Sub Cannot Use Parentheses When Calling A Sub](/uploads/1/2/5/4/125429398/159899412.png)
What the heck is up with that grouping example above? The error you would receive is 'Cannot use parenthesis when calling a sub-routine', not some weird grouping behavior. Always use parens or you will suffer function/method hell. The Call keyword was invented for a reason.I was always under the impression that the 'Call' keyword existed in VB because it had existed in BASIC; and it existed in BASIC because it existed in FORTRAN, and BASIC was intended (inter alia) as a teaching language and stepping stone to 'real' languages like FORTRAN. Certainly every reference to using 'Call' in VB6 (prior to the advent of VB.NET - I can see why the recommendation to use this keyword now exists) has indicated that it was outmoded and should be avoided.quote:2.
Never override the method byval/byref parameter passing convention, or you shall suffer in hell for all eternity.Are you implying that I don't know better than some scruffy oik who just happens to be intimately familiar with the method's internal workings? - View image here: -Mears, has your problem been solved?
Note, that the recommendations above where made with at least 1/2 tongue-in-cheek. I am certainly aware that VB (or BASIC in general) didn't invent much of anything.
View image here: -Also, just thought I would add that ByRef should also be avoided when possible because it adds a potentially significant amount of overhead to each method call (even if you wrap the value to force ByVal), since the underlying COM engine needs to not only marshal the parameter to the callee, but also marshal the result back to the caller (even if it is subsequently thrown away). This can be especially destructive in a DCOM environment where cross network/process marshalling becomes a problem.
Quote:Originally posted by TheJet:Actually, if you consult the MS site, they recommend always using parenthesis and using the Call keyword to overcome the function vs. Method syntax. It makes the automatic conversion to VB.NET easier - View image here: -BTW, if using parens all the time was such a bad idea, I have to wonder why they made you do it in VB.NET??Because they finally wised-up and fixed the syntax to be less ambiguous.quote:1. Always use parens or you will suffer function/method hell. The Call keyword was invented for a reason.NO YUO!!! The call keyword is absolutely asinine.
Which is easier to read?This:If(isReady(123)) Then.orIf(Call isReady(123)) Then.?The borked VB6 syntax is NOT that difficult to understand. Use parentheses when you are using the return value. Otherwise don't use them.quote:2. Never override the method byval/byref parameter passing convention, or you shall suffer in hell for all eternity. Either 1) the method creator did it for a reason and thus you should not screw with it, or 2) the method creator was an idiot and thus you should use another method - View image here: -I agree with this. One should never override byVal vs. ByRef behavior.
The option shouldn't even be available in the language IMHO.quote:P.S. What the heck is up with that grouping example above? The error you would receive is 'Cannot use parenthesis when calling a sub-routine', not some weird grouping behavior.isGhey is a function, not a sub. MS Excel VBA and VB6 both report 'syntax error' when I try to call isGhey with parens (without using the return value). Of course the fact that the editor highlights the text in red should probably be a tip-off that it's not correct.
Quote:Originally posted by jym:(In your example:IsGhey (0.25), ('Green') 'OKisGhey (0.25, 'Green') 'Syntax error)Yes, it raises a syntax error. That's exactly what I said. Or at least, what I meant to say. Perhaps I didn't make it clear.quote:The difference between:isGhey(0.25, 'Green') ' your exampleandisGhey (0.25, 'Green') ' jym's exampleis that #1 should get the 'cannot use parenthesis when calling a subroutine' and #2 would get a syntax error.I don't care what it should return, on my computer it returns a syntax error. Don't believe me? Cut & paste the following code into MS Excel VBA and try it yourself.Public Function isGhey(Optional PBR As Double = 1#, Optional color As String = 'pink')If PBR = 0.5 Or color = 'pink' Or color = 'fuscia' ThenisGhey = TrueElseisGhey = FalseEnd IfEnd FunctionPublic Sub testisGhey(0.5,'pink')End Sub.