Centralised MsgBox
in [Visual Basic]
|
Prev: crack for VSFlex8 in VB6.0
Next: Component Handles
From: Scott M. on 9 Oct 2009 17:49 "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:uoMAIsHSKHA.4692(a)TK2MSFTNGP06.phx.gbl... > Scott M. wrote: >>> To prevent myself from committing the same perceived offence, perhaps >>> we >>> should consider the usage of "Call" in .NET is like the usage of "Let" >>> in >>> VB6; it's there but of little utility. >> >> To the best of my recollection, "Let" was absolutly required as the >> property >> setter, in other words, there was a valid reason for the keyword. Call >> provides no such benefit in .NET. It accomplishes nothing. > > Let hasn't been required since Dartmouth BASICs. It was one of the very > first optional keywords. Then how else are you supposed to define a property's "setter" in VB 6.0? > I'm pretty sure the very earliest GW/IBM BASICs allowed it to be omitted. > Yep! As is becoming the typical case here, I'm right and you're just > making shxt up. How exactly is starting a sentence with "To the best of my recollection..." making stuff up? I'm not making up that "Let" was used as a property "setter". http://msdn.microsoft.com/en-us/library/77kezfet(VS.85).aspx > The following code is from ALPHABET.BAS, dated 04/08/1982, which shipped > with IBM PC BASIC v1.00 -- take a look at lines 90, 110, etc: Great! What's your point in showing it here? -Scott
From: Scott M. on 9 Oct 2009 18:12 "DanS" <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote in message news:Xns9C9ECF7584D4Ethisnthatroadrunnern(a)216.196.97.131... > "Scott M." <s-mar(a)nospam.nospam> wrote in > news:OoJmHhsRKHA.1796(a)TK2MSFTNGP02.phx.gbl: > >> >> "Henning" <computer_hero(a)coldmail.com> wrote in message >> news:ebDfnYhRKHA.1236(a)TK2MSFTNGP05.phx.gbl... >>> And as usual, the OP has already posted in the dotnet group! >>> And then the issue of Call in dotnet takes place in the wrong group, >>> as usual! >>> >>> /Henning >> >> Since you seem to be very "used" to this kind of thing, one would >> expect you'd have gotten over it by now instead of letting it keep you >> up at night. >> >> If you haven't read the entire thread, you should because it has >> spawned an explanation of the proper use of the Call keyword in >> relation to a VB 6 application, which certainly belongs in the VB 6 >> newsgroup, no? > > That's not what I saw...... > > ....I saw you insisting over and over again that the OP's code MUST be > VB6 code strictly because of the use of the Call keyword..... Then you need to open your eyes and read the thread again. I said it is reasonable to assume that the code is VB 6. > > ....I saw you claim it wasn't in VB.Net, and were wrong...... Perhaps, but the odds still favored VB 6 and as I've said, it was a reasonable conclusion to come to. > > ....I saw you claim is was *required* to use in VBc, when in fact you > were wrong..... Well, actually no. Depending on whether you are or are not using parenthesis when calling methods, you may, in fact have to use Call. In VB6, there are five separate rules (plus 2 special cases) for when you use parenthesis around an argument list and when you don't. and these each relate to the use of the Call keyword. Rule 1....Calling a Subroutine with the Call Keyword. When calling a subroutine using the Call keyword, you must use parenthesis around the parameter list. Example....Call MySub(Parm1, Parm2) Failure to do so will cause a compile error. Rule 2....Calling a Subroutine Without the Call Keyword. When calling a subroutine without using the Call keyword, you cannot use parenthesis around the parameterlist. Example....MySub Parm1, Parm2 If you mistakenly use parenthesis around the parameter list, you will get a compile error. Rule 3....Calling a Function, Storing the Return Value in a Variable. When calling a function and you store the return value into a variable, you must use parenthesis around the parameter list. For example.....MyReturnValue = MyFunction(Parm1, Parm2) Failure to do so will cause a compile error. Rule 4....Calling a Function, Ignoring the Return Value. When calling a function and you don't use the return value, you cannot use parenthesis. For example....MyFunction Parm1, Parm2 If you mistakenly use parenthesis around the parameter list, you will geta compile error. Rule 5....Calling a Function, Ignoring the Return Value Using the Call Keyword. When calling a function, ignoring the return value and using the Call keyword you must use parenthesis. For example....Call MyFunction(Parm1, Parm2) Failure to do so will cause a compile error. Rule 6....Calling a Subroutine Without the Call Keyword But with Only One Parameter (Special Case of Rule 2). When calling a subroutine that accepts only one parameter, and you don't use the Call keyword, you can use a parenthesis. However, the behavior now changes such that the parameter is passed by value even if the parameter is declared in the subroutine by reference. Example...MySub (Parm1) This line of code will compile regardless of whether there are parenthesis, however the behavior may be different (see above). Rule 7....Calling a Function Without the Call Keyword But with Only One Parameter Ignoring the Return Value (Special Case of Rule 4). When calling a function that accepts only one parameter, and you don't use the Call keyword, you can use a parenthesis. However, the behavior now changes such that the parameter is passed by value even if the parameter is declared in the function by reference. Example: MyFunction (Parm1) This line of code will compile regardless of whether there are parenthesis, however the behavior may be different (see above). > ....I saw you claim that the keyword CALL orginated in VBc, but you were > wrong, as it had been used in other BASICs.... I wasn't clear enough about the point that I was making, which was that Call did NOT originate in .NET, it originated in the Basic that came PRIOR to ..NET. My mistake for not being that clear, but to linger on that issue doesn't change the original point I was making, it only serves to distract from the topic. > > ....And then I see that the answer to the initial question that caused > this tirade, whether it was VBc or .Net code, and once again you were > wrong...... Again, that doesn't mean that the evidence didn't support my conclusion. It only means that in this case I was wrong. Surely, you're not going to tell me that every hypothesis or every educated guess will always turn out to be true? And surely you're not going to say that when an educated guess turns out to be false it must mean that the same scenario in the future will always result in the same way? > > ....possibly you should stop discussing VBc when it's clear that you > don't have the experience with it, nor enough knowledge about it to be > able to have a fair debate. I really find it hard to believe that you could come to such a conclusion about me and my knowledge, since all you've ever done is attack me for reasons that do not, in any way relate to specific VB technical issues. And, despite your statements of what is absolutely true or not, your *facts* are not as solid as you belive them to be. Case in point: your above understanding of when Call is and is not required in VB 6. > > I find it hard to see how you can be so adamant about the superiority of > VB.Net versus VBc when clearly you have little knowledge of VBc. As pointed out, you don't know anything about my knowledge of VB 6. And as has a also been pointed out, I have not advocated VB .NET at all in this thread. That is a *fact*. And for you to continue to dispute it only serves to prove my point that you like to make stuff up to serve your own purpose. If you want to have a conversation/debate about VB 6 or VB .NET, I'm happy to particiapte. If you want to go off on a rant full of made up fantasies, you'll have to be prepared for people to call you out on them. -Scott
From: Tom Shelton on 9 Oct 2009 18:22 On 2009-10-09, Scott M. <s-mar(a)nospam.nospam> wrote: > > "DanS" <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote in message > news:Xns9C9ECF7584D4Ethisnthatroadrunnern(a)216.196.97.131... >> "Scott M." <s-mar(a)nospam.nospam> wrote in >> news:OoJmHhsRKHA.1796(a)TK2MSFTNGP02.phx.gbl: >> >>> >>> "Henning" <computer_hero(a)coldmail.com> wrote in message >>> news:ebDfnYhRKHA.1236(a)TK2MSFTNGP05.phx.gbl... >>>> And as usual, the OP has already posted in the dotnet group! >>>> And then the issue of Call in dotnet takes place in the wrong group, >>>> as usual! >>>> >>>> /Henning >>> >>> Since you seem to be very "used" to this kind of thing, one would >>> expect you'd have gotten over it by now instead of letting it keep you >>> up at night. >>> >>> If you haven't read the entire thread, you should because it has >>> spawned an explanation of the proper use of the Call keyword in >>> relation to a VB 6 application, which certainly belongs in the VB 6 >>> newsgroup, no? >> >> That's not what I saw...... >> >> ....I saw you insisting over and over again that the OP's code MUST be >> VB6 code strictly because of the use of the Call keyword..... > > Then you need to open your eyes and read the thread again. I said it is > reasonable to assume that the code is VB 6. > >> >> ....I saw you claim it wasn't in VB.Net, and were wrong...... > > Perhaps, but the odds still favored VB 6 and as I've said, it was a > reasonable conclusion to come to. > >> >> ....I saw you claim is was *required* to use in VBc, when in fact you >> were wrong..... > > Well, actually no. Depending on whether you are or are not using parenthesis > when calling methods, you may, in fact have to use Call. > > In VB6, there are five separate rules (plus 2 special cases) for when you > use parenthesis around an argument list and when you don't. and these each > relate to the use of the Call keyword. > > Rule 1....Calling a Subroutine with the Call Keyword. When calling a > subroutine using the Call keyword, you must use parenthesis around the > parameter list. > Example....Call MySub(Parm1, Parm2) > Failure to do so will cause a compile error. > > Rule 2....Calling a Subroutine Without the Call Keyword. When calling a > subroutine without using the Call keyword, you cannot use parenthesis around > the parameterlist. > Example....MySub Parm1, Parm2 > If you mistakenly use parenthesis around the parameter list, you will get a > compile error. > > Rule 3....Calling a Function, Storing the Return Value in a Variable. When > calling a function and you store the return value into a variable, you must > use parenthesis around the parameter list. > For example.....MyReturnValue = MyFunction(Parm1, Parm2) > Failure to do so will cause a compile error. > > Rule 4....Calling a Function, Ignoring the Return Value. When calling a > function and you don't use the return value, you cannot use parenthesis. > For example....MyFunction Parm1, Parm2 > If you mistakenly use parenthesis around the parameter list, you will geta > compile error. > > Rule 5....Calling a Function, Ignoring the Return Value Using the Call > Keyword. When calling a function, ignoring the return value and using the > Call keyword you must use parenthesis. > For example....Call MyFunction(Parm1, Parm2) > Failure to do so will cause a compile error. > > Rule 6....Calling a Subroutine Without the Call Keyword But with Only One > Parameter (Special Case of Rule 2). When calling a subroutine that accepts > only one parameter, and you don't use the Call keyword, you can use a > parenthesis. However, the behavior now changes such that the parameter is > passed by value even if the parameter is declared in the subroutine by > reference. > Example...MySub (Parm1) > This line of code will compile regardless of whether there are parenthesis, > however the behavior may be different (see above). > > Rule 7....Calling a Function Without the Call Keyword But with Only One > Parameter Ignoring the Return Value (Special Case of Rule 4). When calling a > function that accepts only one parameter, and you don't use the Call > keyword, you can use a parenthesis. However, the behavior now changes such > that the parameter is passed by value even if the parameter is declared in > the function by reference. > Example: MyFunction (Parm1) > This line of code will compile regardless of whether there are parenthesis, > however the behavior may be different (see above). > > I don't see you giving credit to the original author of the above? http://forums.devx.com/showthread.php?t=54171 Sorry - but I used to hang out on those forums a lot. And something about the wording jogged my memory a bit, so I went looking :) -- Tom Shelton
From: Scott M. on 9 Oct 2009 18:36 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:OdxmK8SSKHA.508(a)TK2MSFTNGP06.phx.gbl... > > I don't see you giving credit to the original author of the above? > > http://forums.devx.com/showthread.php?t=54171 > > Sorry - but I used to hang out on those forums a lot. And something about > the > wording jogged my memory a bit, so I went looking :) > > > -- > Tom Shelton I had this saved in an old document that I made several years ago and honestly don't remember where I found it, but the post you show is slightly different than what I have in my document, which leads me to belive that one of them was taken from the other. -Scott
From: DanS on 9 Oct 2009 18:55
"Scott M." <s-mar(a)nospam.nospam> wrote in news:OD4Sy1SSKHA.1908(a)TK2MSFTNGP04.phx.gbl: > > "DanS" <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote in message > news:Xns9C9ECF7584D4Ethisnthatroadrunnern(a)216.196.97.131... >> "Scott M." <s-mar(a)nospam.nospam> wrote in >> news:OoJmHhsRKHA.1796(a)TK2MSFTNGP02.phx.gbl: >> >>> >>> "Henning" <computer_hero(a)coldmail.com> wrote in message >>> news:ebDfnYhRKHA.1236(a)TK2MSFTNGP05.phx.gbl... >>>> And as usual, the OP has already posted in the dotnet group! >>>> And then the issue of Call in dotnet takes place in the wrong >>>> group, as usual! >>>> >>>> /Henning >>> >>> Since you seem to be very "used" to this kind of thing, one would >>> expect you'd have gotten over it by now instead of letting it keep >>> you up at night. >>> >>> If you haven't read the entire thread, you should because it has >>> spawned an explanation of the proper use of the Call keyword in >>> relation to a VB 6 application, which certainly belongs in the VB 6 >>> newsgroup, no? >> >> That's not what I saw...... >> >> ....I saw you insisting over and over again that the OP's code MUST >> be VB6 code strictly because of the use of the Call keyword..... > > Then you need to open your eyes and read the thread again. I said it > is reasonable to assume that the code is VB 6. said...over and over and over again...I'd call that insistant. -The fact that the code uses the keyword "Call" seems to be a tip-off that it's a VB 6 question, since "Call" is not used in VB .NET. -Not sure what you mean by reading it as "part of the message" and "didn't post it separately", but again, the keyword "Call" is not used in .NET, so it must be a VB 6 question. -I disagree. I think that in "reality" you can very easily make a very accurate educated guess that this code is VB 6 code. -As I've said, sine the reality is that "Call" is NOT found in the majoity of .NET code out there, it is reasonable to assume that VB 6 is what's being discussed when you see a snippet like that. -Even that scenario is very unlikely. As such, it is not a stretch at all to assume that a code snip containing the Call keyword is coming from VB 6 code. >> >> ....I saw you claim is was *required* to use in VBc, when in fact you >> were wrong..... > > Well, actually no. Depending on whether you are or are not using > parenthesis when calling methods, you may, in fact have to use Call. > No kidding. You indicated that using Call was req'd in VBc, which is simply not the case. I almost never use it, although some say it should be used so it's apparent that a function call is being made instead of a sub w/params. When I have used it, it was usually in debugging something that was being a PITA and I'd need to use Debug.Print statements which would require the return value, so I'd Call so I could just do a ReplaceAll replacing debug. with Call. This way I wouldn't have to go back and edit to add/remove parens. <Snipped cut & pasted text from a post from 2002 about using the call keyword. http://forums.devx.com/showthread.php?t=54171> >> >> ....And then I see that the answer to the initial question that >> caused this tirade, whether it was VBc or .Net code, and once again >> you were wrong...... > > Again, that doesn't mean that the evidence didn't support my > conclusion. It only means that in this case I was wrong. Surely, > you're not going to tell me that every hypothesis or every educated > guess will always turn out to be true? No, I won't. > And surely you're not going to > say that when an educated guess turns out to be false it must mean > that the same scenario in the future will always result in the same > way? No. >> ....possibly you should stop discussing VBc when it's clear that you >> don't have the experience with it, nor enough knowledge about it to >> be able to have a fair debate. > > I really find it hard to believe that you could come to such a > conclusion about me and my knowledge, since all you've ever done is > attack me for reasons that do not, in any way relate to specific VB > technical issues. And, despite your statements of what is absolutely > true or not, your *facts* are not as solid as you belive them to be. > Case in point: your above understanding of when Call is and is not > required in VB 6. Uh....what to not understand ? Using Call disregards the return value. What am I missing ? That you need to use parens with Call ? Duh. It's not rocket science like you want to make it out to be. >> >> I find it hard to see how you can be so adamant about the superiority >> of VB.Net versus VBc when clearly you have little knowledge of VBc. > > As pointed out, you don't know anything about my knowledge of VB 6. > And as has a also been pointed out, I have not advocated VB .NET at > all in this thread. That is a *fact*. And for you to continue to > dispute it only serves to prove my point that you like to make stuff > up to serve your own purpose. You've got me confused with someone else, as, in this thread, as you say, I haven't said anything what-so-ever about advocating .Net. Should I now say something about you making stuff up ? > If you want to have a conversation/debate about VB 6 or VB .NET, I'm > happy to particiapte. Well I don't have enough experience with .Net to make what you would consider a valid argument, not about technicalities about it, and I'm not afraid to admit that. I can make generalized arguments, like how come, the changed the object model of the Treeview ? It was the same for how long, how many years ? And across how many languages and compilers ? > If you want to go off on a rant full of made up > fantasies, you'll have to be prepared for people to call you out on > them. Fine. Call me out. I stand by my opinions, and statements. When proven wrong I am not above admitting it. I certainly didn't make up fantasies. I calls it as I sees it. Whatever you thought I said, I don't know. Of course, I'm wondering why you even saw this, as announced you kf'd me in the other thread. |