|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Overflowing a LongI've yet again found myself baffled by how complicated VB makes relatively simple tasks, and I was hoping someone might be able to shed some light on a solution to my problem. My problem can be simplified to the following: if I have a Long integer that has reached its maximum capacity (2^31-1), and I add one to this Long, VB throws an Overflow error. What I would like to happen (in the context of my current appliation, which is uniquely hashing Strings), however, is for the result of evaluating 2 ^ 31 and storing it to a long to _rollover_, to become the actual result of the binary arithmetic, namely -2 ^ 31. In most languages, this is done automatically. For instance, if you have a byte that is maxed out: 2 ^ 8 = 255 = 11111111 And you add 1: 11111111 + 00000001 ---------------- 1 00000000 The result is 0 (the minimum value), as the ninth bit does not fit in the buffer of the Byte and so is discarded. With a Long integer, the 64th bit is the sign bit, so when you add 1, it becomes 100...00, or the smallest possible value that can fit in that buffer (-2 ^ 31), and when you add 1 to -1 (111...111), the buffer overflows leaving only zeros. **This is the math that VB is doing under the hood**, but instead of returning the result, it does a second check to make sure that after discarding these extra bits, the result is 0 (the only overflow case VB allows), and, if it's not, it throws an error. So my question is this: How does one handle overflows such that they do *not* generate errors, but instead return the *actual* binary result? I've tried various algorithms, one of which works but is painfully slow (by recursively converting a double back down into a long). Visual Basic's bitwise operators (And, Or, Xor -- they don't even have a LR shift) support at most comparisons between two 32-bit types (Long And Long = Long); however, in order to make use of those in this case, I would need to compare two 64 bit-types (Double And Double = Double), as I need to compress the result of my arithmetic back down into an overflowed Long. Is there any way in VB to actually physically shift or manipulate a Double at the bit level? Ultimately, what work best would be the VB equivalent of the following Java method--I cannot however find a way to do this in VB unless I can find a method to shift the bits of a Double in a relatively efficient manner. Note that, in Java, an "int" is a 32-bit signed integer (the equivalent of a VB Long) and a "long" is a 64-bit signed integer (the equivalent of a VB Double, minus the floating point). import java.util.Random; public class BinMath { public static void main(String[] args) { Random r = new Random(7); int val = 0; for (int i = 0; i < 20; i ++) { long d = r.nextLong(); val += handleOverflow(val + d); } System.out.printf("Final: %d\n", val); } public static int handleOverflow(long d) { System.out.printf("%d -> ", d); while (d > Integer.MAX_VALUE || d < Integer.MIN_VALUE) { d = d >> 32; } System.out.printf("%d\n", d); return (int) d; } } Any ideas how to do this in VB???? Thanks in advance. -- Daniel Cannon AmiDaniel <cannon.dani***@gmail.com> wrote:
> question is this: How does one handle overflows such that they do Cutting to the chase, one potential solution would be to turn off Overflow Checking > *not* generate errors, but instead return the *actual* binary result? in the Advanced Compiler Optimizations. That'll make debugging a little more difficult as that really only kicks in when running the EXE, I believe, so you'd need to test your boundary conditions outside the IDE. You can also do this algorithmically, but the overhead would be far greater if the above does the trick. Show quoteHide quote > Hi all, > > I've yet again found myself baffled by how complicated VB makes > relatively simple tasks, and I was hoping someone might be able to > shed some light on a solution to my problem. > > My problem can be simplified to the following: if I have a Long > integer that has reached its maximum capacity (2^31-1), and I add one > to this Long, VB throws an Overflow error. What I would like to happen > (in the context of my current appliation, which is uniquely hashing > Strings), however, is for the result of evaluating 2 ^ 31 and storing > it to a long to _rollover_, to become the actual result of the binary > arithmetic, namely -2 ^ 31. In most languages, this is done > automatically. For instance, if you have a byte that is maxed out: > > 2 ^ 8 = 255 = 11111111 > > And you add 1: > > 11111111 > + 00000001 > ---------------- > 1 00000000 > > The result is 0 (the minimum value), as the ninth bit does not fit in > the buffer of the Byte and so is discarded. With a Long integer, the > 64th bit is the sign bit, so when you add 1, it becomes 100...00, or > the smallest possible value that can fit in that buffer (-2 ^ 31), and > when you add 1 to -1 (111...111), the buffer overflows leaving only > zeros. **This is the math that VB is doing under the hood**, but > instead of returning the result, it does a second check to make sure > that after discarding these extra bits, the result is 0 (the only > overflow case VB allows), and, if it's not, it throws an error. So my > question is this: How does one handle overflows such that they do > *not* generate errors, but instead return the *actual* binary result? > > I've tried various algorithms, one of which works but is painfully > slow (by recursively converting a double back down into a long). > Visual Basic's bitwise operators (And, Or, Xor -- they don't even have > a LR shift) support at most comparisons between two 32-bit types (Long > And Long = Long); however, in order to make use of those in this case, > I would need to compare two 64 bit-types (Double And Double = Double), > as I need to compress the result of my arithmetic back down into an > overflowed Long. Is there any way in VB to actually physically shift > or manipulate a Double at the bit level? > > Ultimately, what work best would be the VB equivalent of the following > Java method--I cannot however find a way to do this in VB unless I can > find a method to shift the bits of a Double in a relatively efficient > manner. Note that, in Java, an "int" is a 32-bit signed integer (the > equivalent of a VB Long) and a "long" is a 64-bit signed integer (the > equivalent of a VB Double, minus the floating point). > > import java.util.Random; > > public class BinMath { > public static void main(String[] args) { > Random r = new Random(7); > int val = 0; > for (int i = 0; i < 20; i ++) { > long d = r.nextLong(); > val += handleOverflow(val + d); > } > System.out.printf("Final: %d\n", val); > } > > public static int handleOverflow(long d) { > System.out.printf("%d -> ", d); > while (d > Integer.MAX_VALUE || d < Integer.MIN_VALUE) { > d = d >> 32; > } > System.out.printf("%d\n", d); > > return (int) d; > } > } > > Any ideas how to do this in VB???? Thanks in advance. "Karl E. Peterson" <k***@mvps.org> wrote in message Simple solution to that is to compile the appropriate code into a dll. You news:%23SllZ1sVHHA.1200@TK2MSFTNGP04.phx.gbl... > Cutting to the chase, one potential solution would be to turn off Overflow > Checking in the Advanced Compiler Optimizations. That'll make debugging a > little more difficult as that really only kicks in when running the EXE, I > believe, so you'd need to test your boundary conditions outside the IDE. could even make it look like the java function: java: val += handleOverflow(val + d); (is this correct?) vb: handleOverflow(val, d); For the OP, C# does the rollover but I'm not sure about vb.net. Michael "Michael C" <nospam@nospam.com> wrote in message I just realised this is VBA for autocad which probably doesn't have compile news:eBmlPFtVHHA.1360@TK2MSFTNGP02.phx.gbl... > Simple solution to that is to compile the appropriate code into a dll. You > could even make it look like the java function: options at all. Daniel, download this dll to your machine and add it as a reference to your project: http://mikesdriveway.com/misc/OverflowStuffLib.zip Then you can write code like this: x = AddLongs(x, 1) x = SubtractLongs(x, 1) You might need the vb6 runtimes which can be downloaded from MS. Michael On Feb 22, 3:52 pm, "Michael C" <nos...@nospam.com> wrote: Actually, this is being built as an ActiveX dll, so I can specify> "Michael C" <nos...@nospam.com> wrote in message > I just realised this is VBA for autocad which probably doesn't have compile > options at all. Daniel, download this dll to your machine and add it as a > reference to your project: compile options--I simply cross-posted as I wasn't sure where I was going to get the best answer :D. I will take a look at your library though, as it may still come in handy if I ever need to do this outside of a compiled app. Thanks again. -- Daniel Cannon "AmiDaniel" <cannon.dani***@gmail.com> wrote in message Here's the extensive source code. ByVal is used because it is faster I news:1172185010.445740.118350@h3g2000cwc.googlegroups.com... > Actually, this is being built as an ActiveX dll, so I can specify > compile options--I simply cross-posted as I wasn't sure where I was > going to get the best answer :D. I will take a look at your library > though, as it may still come in handy if I ever need to do this > outside of a compiled app. Thanks again. believe. It would possibly be better to put this into a dll instead of turning off the integer checks throughout your app but as you said, most languages don't have this check anyway and the world hasn't imploded. Public Function AddLongs(ByVal Value1 As Long, ByVal Value2 As Long) As Long AddLongs = Value1 + Value2 End Function Public Function SubtractLongs(ByVal Value1 As Long, ByVal Value2 As Long) As Long SubtractLongs = Value1 - Value2 End Function Michael
Show quote
Hide quote
On Feb 22, 3:03 pm, "Karl E. Peterson" <k***@mvps.org> wrote: Oh, wow, there's a compiler option to supress overflow checking?> AmiDaniel <cannon.dani***@gmail.com> wrote: > > question is this: How does one handle overflows such that they do > > *not* generate errors, but instead return the *actual* binary result? > > Cutting to the chase, one potential solution would be to turn off Overflow Checking > in the Advanced Compiler Optimizations. That'll make debugging a little more > difficult as that really only kicks in when running the EXE, I believe, so you'd > need to test your boundary conditions outside the IDE. > > You can also do this algorithmically, but the overhead would be far greater if the > above does the trick. > -- > .NET: It's About Trust! > http://vfred.mvps.org Great, I'll give that a try and see if it works--if it does, I take back the nasty things I said about VB :). They really should implement a bit-shift operator, though, and preferably one that can handle more than a Long! Thanks for your help. -- Daniel Cannon AmiDaniel <cannon.dani***@gmail.com> wrote:
Show quoteHide quote > On Feb 22, 3:03 pm, "Karl E. Peterson" <k***@mvps.org> wrote: Cool! (I'm almost afraid to ask if you really meant VBA, not VB? <g>)>> AmiDaniel <cannon.dani***@gmail.com> wrote: >>> question is this: How does one handle overflows such that they do >>> *not* generate errors, but instead return the *actual* binary result? >> >> Cutting to the chase, one potential solution would be to turn off Overflow >> Checking in the Advanced Compiler Optimizations. That'll make debugging a >> little more difficult as that really only kicks in when running the EXE, I >> believe, so you'd need to test your boundary conditions outside the IDE. >> >> You can also do this algorithmically, but the overhead would be far greater if >> the above does the trick. > > Oh, wow, there's a compiler option to supress overflow checking? > Great, I'll give that a try and see if it works--if it does, I take > back the nasty things I said about VB :). > They really should implement Totally agree. Isn't gonna happen, though. It's a dead language; which isn't > a bit-shift operator, though, and preferably one that can handle more > than a Long! Thanks for your help. altogether a Bad Thing. On 22 Feb 2007 14:47:37 -0800, "AmiDaniel" <cannon.dani***@gmail.com> wrote: ¤ Oh, wow, there's a compiler option to supress overflow checking?¤ Great, I'll give that a try and see if it works--if it does, I take ¤ back the nasty things I said about VB :). They really should implement ¤ a bit-shift operator, though, and preferably one that can handle more ¤ than a Long! Thanks for your help. Actually it was implemented in Visual Basic.NET 2003. Paul ~~~~ Microsoft MVP (Visual Basic) Paul Clement <UseAdddressAtEndofMess***@swspectrum.com> wrote:
> On 22 Feb 2007 14:47:37 -0800, "AmiDaniel" <cannon.dani***@gmail.com> wrote: Which has *nothing* to do with the subject at hand, of course!> ¤ Oh, wow, there's a compiler option to supress overflow checking? > ¤ Great, I'll give that a try and see if it works--if it does, I take > ¤ back the nasty things I said about VB :). They really should implement > ¤ a bit-shift operator, though, and preferably one that can handle more > ¤ than a Long! Thanks for your help. > > Actually it was implemented in Visual Basic.NET 2003. On Fri, 23 Feb 2007 09:48:28 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: ¤ > ¤ Oh, wow, there's a compiler option to supress overflow checking?¤ > ¤ Great, I'll give that a try and see if it works--if it does, I take ¤ > ¤ back the nasty things I said about VB :). They really should implement ¤ > ¤ a bit-shift operator, though, and preferably one that can handle more ¤ > ¤ than a Long! Thanks for your help. ¤ > ¤ > Actually it was implemented in Visual Basic.NET 2003. ¤ ¤ Which has *nothing* to do with the subject at hand, of course! Then why did you bring it up? "Totally agree. Isn't gonna happen, though. It's a dead language; which isn't altogether a Bad Thing." Paul ~~~~ Microsoft MVP (Visual Basic) Paul Clement <UseAdddressAtEndofMess***@swspectrum.com> wrote:
Show quoteHide quote > On Fri, 23 Feb 2007 09:48:28 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: Non sequitur.> > ¤ > ¤ Oh, wow, there's a compiler option to supress overflow checking? > ¤ > ¤ Great, I'll give that a try and see if it works--if it does, I take > ¤ > ¤ back the nasty things I said about VB :). They really should implement > ¤ > ¤ a bit-shift operator, though, and preferably one that can handle more > ¤ > ¤ than a Long! Thanks for your help. > ¤ > > ¤ > Actually it was implemented in Visual Basic.NET 2003. > ¤ > ¤ Which has *nothing* to do with the subject at hand, of course! > > Then why did you bring it up? > > "Totally agree. Isn't gonna happen, though. It's a dead language; which isn't > altogether a Bad Thing." "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message What a strange statement! Are you on something?news:978ut219lahtu5c8uvch2qtp8th3m67m8h@4ax.com... > Actually it was implemented in Visual Basic.NET 2003. Mike Williams <M***@WhiskyAndCoke.com> wrote:
> "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message It's the Kool-Aid...> news:978ut219lahtu5c8uvch2qtp8th3m67m8h@4ax.com... > >> Actually it was implemented in Visual Basic.NET 2003. > > What a strange statement! Are you on something? Karl E. Peterson wrote:
> Mike Williams <M***@WhiskyAndCoke.com> wrote: An amazingly resilient meme, that one.>> "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message >> news:978ut219lahtu5c8uvch2qtp8th3m67m8h@4ax.com... >> >>> Actually it was implemented in Visual Basic.NET 2003. >> What a strange statement! Are you on something? > > It's the Kool-Aid... Since the product used to blunt the poison's taste in Jonestown was really Flav-or-ade. Maybe Karl belongs to a different group that uses Kool-Aid...? :)
Rob Show quoteHide quote "Bob O`Bob" <filter***@yahoogroups.com> wrote in message news:eJGDCt7VHHA.4720@TK2MSFTNGP04.phx.gbl... > Karl E. Peterson wrote: >> Mike Williams <M***@WhiskyAndCoke.com> wrote: >>> "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in >>> message >>> news:978ut219lahtu5c8uvch2qtp8th3m67m8h@4ax.com... >>> >>>> Actually it was implemented in Visual Basic.NET 2003. >>> What a strange statement! Are you on something? >> >> It's the Kool-Aid... > > > An amazingly resilient meme, that one. > > Since the product used to blunt the poison's taste in Jonestown was really > Flav-or-ade. Bob O`Bob <filter***@yahoogroups.com> wrote:
Show quoteHide quote > Karl E. Peterson wrote: Hard to keep a Good Meme down! ;-)>> Mike Williams <M***@WhiskyAndCoke.com> wrote: >>> "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote ... >>> >>>> Actually it was implemented in Visual Basic.NET 2003. >>> >>> What a strange statement! Are you on something? >> >> It's the Kool-Aid... > > An amazingly resilient meme, that one. > > Since the product used to blunt the poison's taste in Jonestown was really > Flav-or-ade. On Fri, 23 Feb 2007 19:10:23 -0000, "Mike Williams" <M***@WhiskyAndCoke.com> wrote: ¤ ¤ > Actually it was implemented in Visual Basic.NET 2003. ¤ ¤ What a strange statement! Are you on something? ¤ Why did you find it strange? Care to explain? Paul ~~~~ Microsoft MVP (Visual Basic) > ¤ > Actually it was implemented in Visual Basic.NET 2003. If I had to guess, I would say because this newsgroup is devoted to problems > ¤ > ¤ What a strange statement! Are you on something? > ¤ > > Why did you find it strange? Care to explain? people have with VB6 (and earlier). What other languages do (be they VB.NET, C++, Fortran or whatever) doesn't go very far in answering questions posed here by people using the programming language for which this newsgroup caters to. Rick On Tue, 27 Feb 2007 11:35:02 -0500, "Rick Rothstein \(MVP - VB\)" <rickNOSPAMnews@NOSPAMcomcast.net> ¤ > ¤ > Actually it was implemented in Visual Basic.NET 2003.wrote: ¤ > ¤ ¤ > ¤ What a strange statement! Are you on something? ¤ > ¤ ¤ > ¤ > Why did you find it strange? Care to explain? ¤ ¤ If I had to guess, I would say because this newsgroup is devoted to problems ¤ people have with VB6 (and earlier). What other languages do (be they VB.NET, ¤ C++, Fortran or whatever) doesn't go very far in answering questions posed ¤ here by people using the programming language for which this newsgroup ¤ caters to. My post was in response to the statement about adding the feature to the language and correcting one which claimed it would never happen. It isn't up to me to decide whether the option is a viable alternative. I'm simply providing the information for those who would choose to decide for themselves, and not having it forced upon them by those who would never consider it. Paul ~~~~ Microsoft MVP (Visual Basic) Paul Clement <UseAdddressAtEndofMess***@swspectrum.com> wrote:
Show quoteHide quote > ¤ > ¤ > Actually it was implemented in Visual Basic.NET 2003. It didn't happen. The language died. You're hallucinating. QED.> ¤ > ¤ > ¤ > ¤ What a strange statement! Are you on something? > ¤ > > ¤ > Why did you find it strange? Care to explain? > ¤ > ¤ If I had to guess, I would say because this newsgroup is devoted to problems > ¤ people have with VB6 (and earlier). What other languages do (be they VB.NET, > ¤ C++, Fortran or whatever) doesn't go very far in answering questions posed > ¤ here by people using the programming language for which this newsgroup > ¤ caters to. > > My post was in response to the statement about adding the feature to the language > and correcting one which claimed it would never happen. On Tue, 27 Feb 2007 09:55:38 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: ¤ >¤ > My post was in response to the statement about adding the feature to the language ¤ > and correcting one which claimed it would never happen. ¤ ¤ It didn't happen. The language died. You're hallucinating. QED. No I've simply moved on to the next version. You're still in denial. HTH. Paul ~~~~ Microsoft MVP (Visual Basic) Paul Clement <UseAdddressAtEndofMess***@swspectrum.com> wrote:
> On Tue, 27 Feb 2007 09:55:38 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: And yet, here you are!> > ¤ > > ¤ > My post was in response to the statement about adding the feature to the > language ¤ > and correcting one which claimed it would never happen. > ¤ > ¤ It didn't happen. The language died. You're hallucinating. QED. > > No I've simply moved on to the next version. > You're still in denial. As we tell GWB when he says he's been talking to God, "Put down that mirror!"On Tue, 27 Feb 2007 11:03:15 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: ¤ >¤ > ¤ > ¤ > ¤ > My post was in response to the statement about adding the feature to the ¤ > language ¤ > and correcting one which claimed it would never happen. ¤ > ¤ ¤ > ¤ It didn't happen. The language died. You're hallucinating. QED. ¤ > ¤ > No I've simply moved on to the next version. ¤ ¤ And yet, here you are! No question your observations are limited to this venue. But some of us *can* support more than one version. Imagine that. ¤ > You're still in denial. ¤ ¤ As we tell GWB when he says he's been talking to God, "Put down that mirror!" Well that would explain your pre-occupation with others. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) Paul Clement <UseAdddressAtEndofMess***@swspectrum.com> wrote:
Show quoteHide quote > On Tue, 27 Feb 2007 11:03:15 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: What shortcoming are you compensating for?> > ¤ > > ¤ > ¤ > > ¤ > ¤ > My post was in response to the statement about adding the feature to the > ¤ > language ¤ > and correcting one which claimed it would never happen. > ¤ > ¤ > ¤ > ¤ It didn't happen. The language died. You're hallucinating. QED. > ¤ > > ¤ > No I've simply moved on to the next version. > ¤ > ¤ And yet, here you are! > > No question your observations are limited to this venue. > > But some of us *can* support more than one version. Imagine that. Alright, people. Other than you two, I think we're all tired of this now.
Rob Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:O0D5ydqWHHA.4632@TK2MSFTNGP04.phx.gbl... > Paul Clement <UseAdddressAtEndofMess***@swspectrum.com> wrote: >> On Tue, 27 Feb 2007 11:03:15 -0800, "Karl E. Peterson" <k***@mvps.org> >> wrote: >> >> ¤ > >> ¤ > ¤ > >> ¤ > ¤ > My post was in response to the statement about adding the feature >> to the >> ¤ > language ¤ > and correcting one which claimed it would never happen. >> ¤ > ¤ >> ¤ > ¤ It didn't happen. The language died. You're hallucinating. QED. >> ¤ > >> ¤ > No I've simply moved on to the next version. >> ¤ >> ¤ And yet, here you are! >> >> No question your observations are limited to this venue. >> >> But some of us *can* support more than one version. Imagine that. > > What shortcoming are you compensating for? > -- > .NET: It's About Trust! > http://vfred.mvps.org > On Tue, 27 Feb 2007 11:42:41 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: ¤ > ¤ > ¤ > My post was in response to the statement about adding the feature to the¤ > ¤ > language ¤ > and correcting one which claimed it would never happen. ¤ > ¤ > ¤ ¤ > ¤ > ¤ It didn't happen. The language died. You're hallucinating. QED. ¤ > ¤ > ¤ > ¤ > No I've simply moved on to the next version. ¤ > ¤ ¤ > ¤ And yet, here you are! ¤ > ¤ > No question your observations are limited to this venue. ¤ > ¤ > But some of us *can* support more than one version. Imagine that. ¤ ¤ What shortcoming are you compensating for? The assumption that you can understand simple concepts. Sorry, my mistake. Paul ~~~~ Microsoft MVP (Visual Basic) "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message But the feature you were taking about, as I recall, was a Shift or perhaps a news:ikq8u2lv76gdt5su75u2ieneghia5rmu0v@4ax.com... > My post was in response to the statement about > adding the feature to the language Rotate instruction. Such a feature has *not* been added to Visual Basic, at least not to the *real* Visual Basic. Dotnet is effectively a completely different language. It is *not* an update to VB6. You must be "on something" if you think that it is. Micro$haft can of course call it anything they like, just as you can spend all year if you wish, or even longer, calling a spade a fork. But calling a spade a fork will not actually turn it into a fork, no matter how many times you say it! Mike On Tue, 27 Feb 2007 20:04:51 -0000, "Mike Williams" <M***@WhiskyAndCoke.com> wrote: ¤ > My post was in response to the statement about¤ > adding the feature to the language ¤ ¤ But the feature you were taking about, as I recall, was a Shift or perhaps a ¤ Rotate instruction. Such a feature has *not* been added to Visual Basic, at ¤ least not to the *real* Visual Basic. Dotnet is effectively a completely ¤ different language. It is *not* an update to VB6. You must be "on something" ¤ if you think that it is. Micro$haft can of course call it anything they ¤ like, just as you can spend all year if you wish, or even longer, calling a ¤ spade a fork. But calling a spade a fork will not actually turn it into a ¤ fork, no matter how many times you say it! Don't know what to tell you Mike. It's Microsoft's product and a bit shift operator was added in a subsequent version of the Visual Basic language. You may not have liked the additions and changes to the language and language extensions, and can call it whatever you want or pretend it doesn't exist - but the fact is that it does exist and it's still Visual Basic. Perhaps they should have left the word Basic out of Visual Basic 1.0 as well. Maybe they could have called it Visual DooDad or something like that because it really isn't Basic but a completely different language that I had to learn and master. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) Will you two just whip it out and measure, this is getting tiring.
If I were Microsoft, I'd withdraw the MVP designation for this kind of continual ranting. Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message Aren't you having any fun, Robert?news:%239DHD90WHHA.4668@TK2MSFTNGP04.phx.gbl... > Will you two just whip it out and measure, this is getting tiring. > If I were Microsoft, I'd withdraw the MVP designation for this > kind of continual ranting. Mike Not particularly, no. I did make one mistake, though, it's not just two of
you, apparently...I'd missed that there were others going back & forth as well. Rob Show quoteHide quote "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message news:OZKw1H2WHHA.4872@TK2MSFTNGP03.phx.gbl... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message > news:%239DHD90WHHA.4668@TK2MSFTNGP04.phx.gbl... > >> Will you two just whip it out and measure, this is getting tiring. >> If I were Microsoft, I'd withdraw the MVP designation for this >> kind of continual ranting. > > Aren't you having any fun, Robert? > > Mike > > "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message No it was not! There was no "subsequent version" of Visual BASIC. VB6 was news:o7uau2h6p8b85mcsevguiqe0lhkhfhftgj@4ax.com... > Don't know what to tell you Mike. It's Microsoft's product > and a bit shift operator was added in a subsequent version > of the Visual Basic language. the last version. VB.Net is NOT BASIC!!!!! Granted, Micro$haft can call it BASIC if they wish, partly because BASIC is not a registered trade mark and partly because very few people have got the soirt of cash to be able to task Micro$haft to court over it even if it was. But even Micro$haft can spend all year iof they wish calling a spade a fork . . . but it will still not be a spade at the end of it. In just the same way, VBH.Net will NEVER magically turn itself into BASIC, no matter how many times Micro$haft call it by that name!!! Mike ~~~~ Microsoft MVP (Visual Basic)
Show quote
Hide quote
"Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message Well said. Pity mike missed the whole thing and just repeated his rant.> Don't know what to tell you Mike. It's Microsoft's product and a bit shift > operator was added in a > subsequent version of the Visual Basic language. You may not have liked > the additions and changes to > the language and language extensions, and can call it whatever you want or > pretend it doesn't exist > - but the fact is that it does exist and it's still Visual Basic. > > Perhaps they should have left the word Basic out of Visual Basic 1.0 as > well. Maybe they could have > called it Visual DooDad or something like that because it really isn't > Basic but a completely > different language that I had to learn and master. ;-) Michael "Michael C" <nospam@nospam.com> wrote in message You're quite wrong. Visual Basic 6 and below *are* essentially the same as news:uhCGJOrXHHA.2636@TK2MSFTNGP06.phx.gbl... >> Perhaps they should have left the word Basic out of Visual >> Basic 1.0 as well. Maybe they could have called it Visual >> DooDad or something like that because it really isn't Basic >> but a completely different language that I had to learn and >> master. ;-) > Well said. Pity mike missed the whole thing and just repeated his rant. the old versions of BASIC. The only difference is that Visual Basic is essentially event driven whereas the old versions of BASIC were sequential. But the old BASIC sequential code will still run in Visual Basic (VB6 and below), and it will still run in its old sequential mode if you wish, including line numbers and GoSubs and Returns and almost everything else. In many cases (although not in all cases of course) you can just "copy and paste" an entire old fashioned BASIC program (line numbers and Gosub and all) into a VB6 Command Button click event and click the button and it will run. There are a few things you will need to alter, particularly when dealing with keyboard input, but not many. You can't do that, or anything like it, in Visual FredNet (or whatever they are calling it now). In Visual FredNet not even a simple Print "Hello World" will work without modification! VB6 is as much like the old fashioned BASIC as you can get for a language that is event driven. If you personally looked on it as something completely new that you had to learn and master from scratch, as you have suggested, then perhaps you . . . (to be continued)! Mike
Show quote
Hide quote
"Mike Williams" <m***@whiskyandCoke.com> wrote in message But some changes are needed from old basic to VB6. Not using the old basic I news:ONONYEyXHHA.1388@TK2MSFTNGP05.phx.gbl... > You're quite wrong. Visual Basic 6 and below *are* essentially the same as > the old versions of BASIC. The only difference is that Visual Basic is > essentially event driven whereas the old versions of BASIC were > sequential. But the old BASIC sequential code will still run in Visual > Basic (VB6 and below), and it will still run in its old sequential mode if > you wish, including line numbers and GoSubs and Returns and almost > everything else. In many cases (although not in all cases of course) you > can just "copy and paste" an entire old fashioned BASIC program (line > numbers and Gosub and all) into a VB6 Command Button click event and click > the button and it will run. There are a few things you will need to alter, > particularly when dealing with keyboard input, but not many. You can't do > that, or anything like it, in Visual FredNet (or whatever they are calling > it now). In Visual FredNet not even a simple Print "Hello World" will work > without modification! VB6 is as much like the old fashioned BASIC as you > can get for a language that is event driven. If you personally looked on > it as something completely new that you had to learn and master from > scratch, as you have suggested, then perhaps you . . . (to be continued)! wouldn't know but I suspect your under-exaggerating the changes that would be required. Maybe a greater number of changes are required for vb.net but it's still the same basic syntax and much of what doesn't work is code that relies on libraries (eg ADO). At what point do you consider it a different language, is there a certain percentage of code? Michael Michael C <nospam@nospam.com> wrote:
> But some changes are needed from old basic to VB6. Not using the old basic I That number is technically known as "very damned few." Swap and Data were two > wouldn't know but I suspect your under-exaggerating the changes that would > be required. keywords that went bye-bye, and present the greatest migration challenge. Others, like Peek and Poke aren't really a very good idea in an environment where multiple applications are running, eh? Ummmm, otherwise... Nope, that's about it. > Maybe a greater number of changes are required for vb.net Quick, what's the result? Debug.Print Len(n%)> At what point do you consider it a different One measure I'd suggest is *when the same code* produces different results.> language, is there a certain percentage of code? "Michael C" <nospam@nospam.com> wrote in message I'm not "under exaggerating", Michael. I have written BASIC programs for news:uA$F7V3XHHA.2436@TK2MSFTNGP06.phx.gbl... > But some changes are needed from old basic to VB6. Not using > the old basic I wouldn't know but I suspect your under-exaggerating > the changes that would be required. almost thirty years and many of even my very earliest BASIC programs would run with no problems whatsoever if I pasted them into a VB6 Button Click event, for example. But not a single one of them would run in dotnet. Not even the simplest of them. Not even most of the "one liners". > Maybe a greater number of changes are required for vb.net A massive number of changes!> but it's still the same basic syntax No it isn't, Michael. It is massively different.> At what point do you consider it a different language, is there a certain It's not something I've bothered to actually quantify. It's more of a "gut > percentage of code? feeling" thing, although you could certainly quantify it if you wished to do so. As I said earlier, I've been programming for nearly thirty years (machine code, Assembler, Fortran and BASIC) and when I picked up my first copy of Visual Basic (which I didn't bother doing until VB5 came out, because I was busy with other languages at the time) I was almost immediately comfortable with it. It was BASIC, but with some extra bells and whistles. There was of course a slight learning curve because of the event driven nature of VB5 (which was new to me) but nevertheless I felt at home almost straight away and I could convert even the oldest of my previous BASIC programs to VB5 very quickly and with very few problems. Dotnet is not like that. Not like that at all. As far as I am concerned, dotnet is not BASIC at all. The only relationship dotnet has to the old BASIC is that the Micro$oft sales team have persuaded the Micro$oft programmers to "graft onto it" a large number of "Basic sounding constructs" in an attempt to persuade people that it is something which it isn't! Their underhand ploy hasn't worked for me, although I'm sure lots of people will be taken in by it, at least until they have parted with their money. Mike "Mike Williams" <m***@whiskyandCoke.com> wrote in message They mustn't do much though. They obviously can't draw to the screen.news:uUhjtq3XHHA.2436@TK2MSFTNGP06.phx.gbl... > I'm not "under exaggerating", Michael. I have written BASIC programs for > almost thirty years and many of even my very earliest BASIC programs would > run with no problems whatsoever if I pasted them into a VB6 Button Click > event, for example. > But not a single one of them would run in dotnet. Not even the simplest of That is likely true but restricting vb.net to vb6 syntax would have held it > them. Not even most of the "one liners". back a *huge* amount. Can you imagine our nicely oop language being infected with gosubs, gotos etc? > A massive number of changes! It's basically the same.> >> but it's still the same basic syntax > > No it isn't, Michael. It is massively different. > It's not something I've bothered to actually quantify. It's more of a "gut There is a slight learning curve but it's really not that bad. It's > feeling" thing, although you could certainly quantify it if you wished to > do so. As I said earlier, I've been programming for nearly thirty years > (machine code, Assembler, Fortran and BASIC) and when I picked up my first > copy of Visual Basic (which I didn't bother doing until VB5 came out, > because I was busy with other languages at the time) I was almost > immediately comfortable with it. It was BASIC, but with some extra bells > and whistles. There was of course a slight learning curve because of the > event driven nature of VB5 (which was new to me) but nevertheless I felt > at home almost straight away and I could convert even the oldest of my > previous BASIC programs to VB5 very quickly and with very few problems. > Dotnet is not like that. definately less of learning curve to going from a dos language to an event driven language (if you think back, learning events wasn't that easy, it could get complicated). > Not like that at all. As far as I am concerned, dotnet is not BASIC at You can design a form just like vb6 and all the syntax is still basic > all. The only relationship dotnet has to the old BASIC is that the > Micro$oft sales team have persuaded the Micro$oft programmers to "graft > onto it" a large number of "Basic sounding constructs" in an attempt to > persuade people that it is something which it isn't! Their underhand ploy > hasn't worked for me, although I'm sure lots of people will be taken in by > it, at least until they have parted with their money. syntax. It's both visual and basic :-) Michael Michael C <nospam@nospam.com> wrote:
>> I'm not "under exaggerating", Michael. I have written BASIC programs for That simply isn't true. Just last year, I sucked some QB4 code directly into VB6. >> almost thirty years and many of even my very earliest BASIC programs would >> run with no problems whatsoever if I pasted them into a VB6 Button Click >> event, for example. > > They mustn't do much though. They obviously can't draw to the screen. What did it do? Binary DBF handling. True, once I confirmed it was working (key point there!), I was able to "objectify" it. It became far prettier, but I could easily run/edit/test/compile it right within VB6. No sort of binary file i/o is portable between VB6<->VFred. "Karl E. Peterson" <k***@mvps.org> wrote in message Well it simply is true. If a basic dos app writes to the screen it's not news:Oq9SPA5XHHA.3268@TK2MSFTNGP04.phx.gbl... > That simply isn't true. going to do much in vb6. > Just last year, I sucked some QB4 code directly into VB6. What did it do? And that is a good thing! You guys might like to work in the past but the vb > Binary DBF handling. True, once I confirmed it was working (key point > there!), I was able to "objectify" it. It became far prettier, but I > could easily run/edit/test/compile it right within VB6. No sort of binary > file i/o is portable between VB6<->VFred. file handling would have to be not only the worst feature in vb6 but the worst feature in any language that has ever existed (ok, maybe a slight exaggeration but not much). Michael > Well it simply is true. If a basic dos app writes to the screen it's not Just to clarify before you guys go at it some more, when you say "writes to > going to do much in vb6. the screen", what BASIC command are you referring to? If you're talking about "Print", that hasn't exactly changed much between...hell...even Apple/C64 and older versions of BASIC and Visual Basic, other than you have to put a Debug in front of them. Yeah, okay, if you want to make it more like a normal UI, you're gonna need to do something a little extra, but if the goal is simply to get information to a window that the programmer can see, Debug.Print will get you there...Print "Hello World" and Debug.Print "Hello World" both print "Hello World" to the screen. Now, if you're talking about something like a graphical app, well...nothing was all that standard back in DOS days anyway, so anything that complex would need to be re-written thoroughly, no question. Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message it would be handy if the user could see it too :-)> Just to clarify before you guys go at it some more, when you say "writes > to the screen", what BASIC command are you referring to? If you're > talking about "Print", that hasn't exactly changed much > between...hell...even Apple/C64 and older versions of BASIC and Visual > Basic, other than you have to put a Debug in front of them. Yeah, okay, > if you want to make it more like a normal UI, you're gonna need to do > something a little extra, but if the goal is simply to get information to > a window that the programmer can see, > Debug.Print will get you there...Print "Hello World" and Debug.Print Debug.print is only going to work in the IDE and printing to the form isn't > "Hello World" both print "Hello World" to the screen. > > Now, if you're talking about something like a graphical app, > well...nothing was all that standard back in DOS days anyway, so anything > that complex would need to be re-written thoroughly, no question. going to do much good either. Michael Exactly. Even *I* know that Debug.Print is not remotely equivalent to the
old Print! Show quoteHide quote "Michael C" <nospam@nospam.com> wrote in message news:OF43IE6XHHA.1244@TK2MSFTNGP04.phx.gbl... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message >> Just to clarify before you guys go at it some more, when you say "writes >> to the screen", what BASIC command are you referring to? If you're >> talking about "Print", that hasn't exactly changed much >> between...hell...even Apple/C64 and older versions of BASIC and Visual >> Basic, other than you have to put a Debug in front of them. Yeah, okay, >> if you want to make it more like a normal UI, you're gonna need to do >> something a little extra, but if the goal is simply to get information to >> a window that the programmer can see, > > it would be handy if the user could see it too :-) > >> Debug.Print will get you there...Print "Hello World" and Debug.Print >> "Hello World" both print "Hello World" to the screen. >> >> Now, if you're talking about something like a graphical app, >> well...nothing was all that standard back in DOS days anyway, so anything >> that complex would need to be re-written thoroughly, no question. > > Debug.print is only going to work in the IDE and printing to the form > isn't going to do much good either. > > Michael > I agree completely...but from a strict standpoint of compatibility, it
performs a related function with a minimum of changes. You'd be utterly stupid to expect that to be an appropriate method of printing something on-screen, but in a HIGHLY limited fashion, it is nevertheless compatible. It's certainly a weak point in the ongoing debate, but as undesirable of a method as it might be, I'd have to take Karl's side on this one that it is, in its own limited (read: "special") way, not truly an incompatibility between older BASICs and VB. As for printing to the form, that's just so foreign to me, I'd never even considered that. I would disagree there as well, though. It would sort of get you where you're going, though I suspect to do anything truly useful, you'd have to make more changes to your code than would be considered appropriate for a "drop-in" replacement. Then again, I suspect that much the same things could be said of a lot of VB to VB.NET code replacements as well, which is sort of the point of this whole discussion. Many things like "On Error" statements still work in VB.NET, as I understand it...it's just not considered the acceptable way to do them any more. Rob Show quoteHide quote "Aalaan" <veryinva***@invalid.com> wrote in message news:45ecf981@dnews.tpgi.com.au... > Exactly. Even *I* know that Debug.Print is not remotely equivalent to the > old Print! > > "Michael C" <nospam@nospam.com> wrote in message > news:OF43IE6XHHA.1244@TK2MSFTNGP04.phx.gbl... >> "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message >>> Just to clarify before you guys go at it some more, when you say "writes >>> to the screen", what BASIC command are you referring to? If you're >>> talking about "Print", that hasn't exactly changed much >>> between...hell...even Apple/C64 and older versions of BASIC and Visual >>> Basic, other than you have to put a Debug in front of them. Yeah, okay, >>> if you want to make it more like a normal UI, you're gonna need to do >>> something a little extra, but if the goal is simply to get information >>> to a window that the programmer can see, >> >> it would be handy if the user could see it too :-) >> >>> Debug.Print will get you there...Print "Hello World" and Debug.Print >>> "Hello World" both print "Hello World" to the screen. >>> >>> Now, if you're talking about something like a graphical app, >>> well...nothing was all that standard back in DOS days anyway, so >>> anything that complex would need to be re-written thoroughly, no >>> question. >> >> Debug.print is only going to work in the IDE and printing to the form >> isn't going to do much good either. >> >> Michael >> > > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message Why? Windows itself prints to its windows. Why shouldn't you do it as well?news:%23AyVwbBYHHA.4872@TK2MSFTNGP03.phx.gbl... > As for printing to the form, that's just so foreign to me, I'd > never even considered that. I would disagree there as well Mike It's a style thing: I tend to think of controls as what you interact with;
the form should be just a holder. Besides, for the most part, even simple controls are far more functional than printing directly to a form (unless you're making your own user controls or something of that nature). Rob Show quoteHide quote "Mike Williams" <m***@whiskyandCoke.com> wrote in message news:emjz8uDYHHA.3272@TK2MSFTNGP03.phx.gbl... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message > news:%23AyVwbBYHHA.4872@TK2MSFTNGP03.phx.gbl... > >> As for printing to the form, that's just so foreign to me, I'd >> never even considered that. I would disagree there as well > > Why? Windows itself prints to its windows. Why shouldn't you do it as > well? > > Mike "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message But Controls print to the Form! How else do you think they display the news:OQXh9FEYHHA.4552@TK2MSFTNGP05.phx.gbl... > It's a style thing: I tend to think of controls as what you interact > with; the form should be just a holder. Besides, for the most part, even > simple controls are far more functional than printing directly to a form > (unless you're making your own user controls or something of that nature). stuff! And what about "printing" to a printer. Do you disagree with that as well? How are you going to place your Controls on the printed page? Surely you're not just going to dump a bitmap of them? Printing is the lifeblood of most applications. Mike Sorry to back this up a level, but responding to your post returned an
invalid message ID error every time. Very odd. -------------------------------- Huh? I'm not entirely sure we're having the same discussion, as I don't see what printing to a printer or placing controls has to do with this. My point is that unless I'm making my own controls, it's just foreign for me to print directly to a form using the Form.Print and related commands. In my world, at least, you populate a text box or label or whatever's appropriate; Form.Print is unwieldy and to me violates the concept of a form being primarily a container for controls. While I won't claim VAST experience with VB6, since I'm mostly an Access guy, I've never known anybody to use Form.Print outside of creating their own controls. Rob Show quoteHide quote "Mike Williams" <m***@whiskyandCoke.com> wrote in message news:%23cr1RREYHHA.1296@TK2MSFTNGP02.phx.gbl... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message > news:OQXh9FEYHHA.4552@TK2MSFTNGP05.phx.gbl... > >> It's a style thing: I tend to think of controls as what you interact >> with; the form should be just a holder. Besides, for the most part, even >> simple controls are far more functional than printing directly to a form >> (unless you're making your own user controls or something of that >> nature). > > But Controls print to the Form! How else do you think they display the > stuff! And what about "printing" to a printer. Do you disagree with that > as well? How are you going to place your Controls on the printed page? > Surely you're not just going to dump a bitmap of them? Printing is the > lifeblood of most applications. > > Mike On Tue, 6 Mar 2007 20:41:05 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >Sorry to back this up a level, but responding to your post returned an <snip>>invalid message ID error every time. Very odd. >-------------------------------- >Huh? I'm not entirely sure we're having the same discussion, as I don't see >what printing to a printer or placing controls has to do with this. > >My point is that unless I'm making my own controls, it's just foreign for me >to print directly to a form using the Form.Print and related commands. In >my world, at least, you populate a text box or label or whatever's >appropriate; Form.Print is unwieldy and to me violates the concept of a form >being primarily a container for controls. There are many ways of skinning cats. Actually Print, Line and PSet are all fundamental Windows concepts, originally the idea was to 'paint' the Screen in the Paint event, but mostly people find that a PITA and set AutoRedraw = True (which is also a fundamental Windows concept called 'double buffering' ) A Form is just a surface. A bit like a whiteboard, you can drow on it or Bluetack other things onto it - it is designed for both. > There are many ways of skinning cats. Agreed...it's just a matter of how I look at it. Coming from an Access > Actually Print, Line and PSet are all fundamental Windows concepts, > originally the idea was to 'paint' the Screen in the Paint event, but > mostly people find that a PITA and set AutoRedraw = True (which is > also a fundamental Windows concept called 'double buffering' ) > > A Form is just a surface. A bit like a whiteboard, you can drow on it > or Bluetack other things onto it - it is designed for both. background, I pretty much always think in terms of controls on forms. Yes, all the same commands are available in Access (or at least I'm pretty sure they're all the same...I'd have to compare one-by-one to be 100% sure of that), but especially in Access, it's almost unheard of to actually use them. I think I've seen the drawing commands used maybe twice in the entire time I've been working with Access (since about '91, give or take), and not since "the early days". It's just taboo...or at least pretty much unheard of...in an environment that's typically geared towards data-binding and serving up information. As I said in one of my posts, my experience with VB6 isn't quite as long-standing, but I've never seen anything that uses them in VB6, either (though obviously user controls would be a likely candidate to do so - not something I've ever needed to work with). I'm sure they're out there, but for the type of work I do in VB6 and the types of sample code I look at elsewhere, I've simply never come across any of those commands in use. Rob On Wed, 7 Mar 2007 12:45:25 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: Show quoteHide quote >> There are many ways of skinning cats. If you started on the TRS80 in 1977 then you come from a bit more than>> Actually Print, Line and PSet are all fundamental Windows concepts, >> originally the idea was to 'paint' the Screen in the Paint event, but >> mostly people find that a PITA and set AutoRedraw = True (which is >> also a fundamental Windows concept called 'double buffering' ) >> >> A Form is just a surface. A bit like a whiteboard, you can drow on it >> or Bluetack other things onto it - it is designed for both. >Agreed...it's just a matter of how I look at it. Coming from an Access >background, I pretty much always think in terms of controls on forms. Yes, >all the same commands are available in Access (or at least I'm pretty sure >they're all the same...I'd have to compare one-by-one to be 100% sure of >that), but especially in Access, it's almost unheard of to actually use >them. I think I've seen the drawing commands used maybe twice in the entire >time I've been working with Access (since about '91, give or take), and not >since "the early days". It's just taboo...or at least pretty much unheard >of...in an environment that's typically geared towards data-binding and >serving up information. >As I said in one of my posts, my experience with VB6 isn't quite as >long-standing, but I've never seen anything that uses them in VB6, either >(though obviously user controls would be a likely candidate to do so - not >something I've ever needed to work with). I'm sure they're out there, but >for the type of work I do in VB6 and the types of sample code I look at >elsewhere, I've simply never come across any of those commands in use. an Access background <g> Actually my first PC was a Commodore PET in 1977, and its BASIC was written by ... guess whom ... Microsoft, who also wrote the Apple BASIC that I used a few years later. Actually I write my own filing systems and don't use any of VB's data binding stuff. A PET was the next computer I worked on, followed (if memory serves, anyway)
by the VIC 20, the C64, and the Apple II. Note, most of those weren't actually my computers, they were the computers at the office, the local video store, or school. Only the C64 was actually mine. I mean, after all, who could afford FOUR computers in those days? What a ridiculous notion! (We currently have four computers in our house for two people. <g>) Yeah, VB's databinding is a kludge, but as you'd expect, Access' databinding was designed by people who were a little better at it than the people who wrote VB6. :) Oh and yes, I do have more than just an Access background, but Access was what I learned VB on (as distinguished from the myriad of other versions of BASIC). Okay, technically that was VBA, but at least to my mind, it's the same as VB...plus or minus a few objects. :) Rob Show quoteHide quote "J French" <erew***@nowhere.uk> wrote in message news:45efc84c.1706525@news.btopenworld.com... > On Wed, 7 Mar 2007 12:45:25 -0500, "Robert Morley" > <rmor***@magma.ca.N0.Freak1n.sparn> wrote: > >>> There are many ways of skinning cats. >>> Actually Print, Line and PSet are all fundamental Windows concepts, >>> originally the idea was to 'paint' the Screen in the Paint event, but >>> mostly people find that a PITA and set AutoRedraw = True (which is >>> also a fundamental Windows concept called 'double buffering' ) >>> >>> A Form is just a surface. A bit like a whiteboard, you can drow on it >>> or Bluetack other things onto it - it is designed for both. > >>Agreed...it's just a matter of how I look at it. Coming from an Access >>background, I pretty much always think in terms of controls on forms. >>Yes, >>all the same commands are available in Access (or at least I'm pretty sure >>they're all the same...I'd have to compare one-by-one to be 100% sure of >>that), but especially in Access, it's almost unheard of to actually use >>them. I think I've seen the drawing commands used maybe twice in the >>entire >>time I've been working with Access (since about '91, give or take), and >>not >>since "the early days". It's just taboo...or at least pretty much unheard >>of...in an environment that's typically geared towards data-binding and >>serving up information. > >>As I said in one of my posts, my experience with VB6 isn't quite as >>long-standing, but I've never seen anything that uses them in VB6, either >>(though obviously user controls would be a likely candidate to do so - not >>something I've ever needed to work with). I'm sure they're out there, but >>for the type of work I do in VB6 and the types of sample code I look at >>elsewhere, I've simply never come across any of those commands in use. > > If you started on the TRS80 in 1977 then you come from a bit more than > an Access background <g> > > Actually my first PC was a Commodore PET in 1977, and its BASIC was > written by ... guess whom ... Microsoft, who also wrote the Apple > BASIC that I used a few years later. > > Actually I write my own filing systems and don't use any of VB's data > binding stuff. > > On Thu, 8 Mar 2007 10:57:58 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >A PET was the next computer I worked on, followed (if memory serves, anyway) I came home from Uni one vac and found a couple of guys unpacking a>by the VIC 20, the C64, and the Apple II. Note, most of those weren't >actually my computers, they were the computers at the office, the local >video store, or school. Only the C64 was actually mine. I mean, after all, >who could afford FOUR computers in those days? What a ridiculous notion! >(We currently have four computers in our house for two people. <g>) PET on the dining room table. Before then I had programmed a little on a teletype in APL on some on-line mainframe, so BASIC was new to me, as was the concept of having a screen. We had set up a small business on the side, it was doing rather nicely, but the paperwork was a problem. I sat down at 7pm that night and by 5am the following morning we had a little invoicing suite that could bang out more invoices in half an hour than our rather slow typist could produce in a day. I realized that computers were rather useful. >Yeah, VB's databinding is a kludge, but as you'd expect, Access' databinding I know little about Access.>was designed by people who were a little better at it than the people who >wrote VB6. :) >Oh and yes, I do have more than just an Access background, but Access was You'll have fun with some of the other VB constructs, my favourite are>what I learned VB on (as distinguished from the myriad of other versions of >BASIC). Okay, technically that was VBA, but at least to my mind, it's the >same as VB...plus or minus a few objects. :) UserControls. It might be worth looking at Delphi for producing 'real' DLLs - I think they have a 'free' version until the end of March. > You'll have fun with some of the other VB constructs, my favourite are I looked at Delphi a long time ago and thought it looked great, but I'm more > UserControls. It might be worth looking at Delphi for producing > 'real' DLLs - I think they have a 'free' version until the end of > March. or less constrained by what's in common use at the office. For my personal projects, I'd rather stick to what's in use at the office, just to enhance my overall skills on the same platform. I may yet look into Delphi at some point, but it'll have to become at least a bit more popular before I devote a lot of time to learning it (or re-learning it if Turbo Pascal counts). Rob Sorry to back this up a level, but I was getting invalid ID errors when
responding to your post. ---------------------------------- Huh? I'm not entirely sure we're having the same discussion, as I don't see what printing to a printer or placing controls has to do with this. My point is that unless I'm making my own controls, it's just foreign for me to print directly to a form using the Form.Print and related commands. In my world, at least, you populate a text box or label or whatever's appropriate; Form.Print is unwieldy and to me violates the concept of a form being primarily a container for controls. While I won't claim VAST experience with VB6, since I'm mostly an Access guy, I've never known anybody to use Form.Print outside of creating their own controls. Rob Show quoteHide quote "Mike Williams" <m***@whiskyandCoke.com> wrote in message news:%23cr1RREYHHA.1296@TK2MSFTNGP02.phx.gbl... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message > news:OQXh9FEYHHA.4552@TK2MSFTNGP05.phx.gbl... > >> It's a style thing: I tend to think of controls as what you interact >> with; the form should be just a holder. Besides, for the most part, even >> simple controls are far more functional than printing directly to a form >> (unless you're making your own user controls or something of that >> nature). > > But Controls print to the Form! How else do you think they display the > stuff! And what about "printing" to a printer. Do you disagree with that > as well? How are you going to place your Controls on the printed page? > Surely you're not just going to dump a bitmap of them? Printing is the > lifeblood of most applications. > > Mike Michael C wrote:
> And that is a good thing! You guys might like to work in the past but the vb Well, at least we've finally firmly established from which orifice your "wisdom" spouts.> file handling would have to be not only the worst feature in vb6 but the > worst feature in any language that has ever existed (ok, maybe a slight > exaggeration but not much). -- "Bob O`Bob" <filter***@yahoogroups.com> wrote in message Funny you should say that i'm speaking out of my a, when you post nothing news:O5Xnr75XHHA.4000@TK2MSFTNGP02.phx.gbl... > Michael C wrote: > >> And that is a good thing! You guys might like to work in the past but the >> vb file handling would have to be not only the worst feature in vb6 but >> the worst feature in any language that has ever existed (ok, maybe a >> slight exaggeration but not much). > > > Well, at least we've finally firmly established from which orifice your > "wisdom" spouts. but an insult. Michael Michael C wrote:
Show quoteHide quote > "Bob O`Bob" <filter***@yahoogroups.com> wrote in message Classic VB's file handling doesn't need to be defended.> news:O5Xnr75XHHA.4000@TK2MSFTNGP02.phx.gbl... >> Michael C wrote: >> >>> And that is a good thing! You guys might like to work in the past but the >>> vb file handling would have to be not only the worst feature in vb6 but >>> the worst feature in any language that has ever existed (ok, maybe a >>> slight exaggeration but not much). >> >> Well, at least we've finally firmly established from which orifice your >> "wisdom" spouts. > > Funny you should say that i'm speaking out of my a, when you post nothing > but an insult. > "Bob O`Bob" <filter***@yahoogroups.com> wrote in message Another statement that just doesn't say anything except "I disagree" (and is news:%236qgAK6XHHA.1216@TK2MSFTNGP03.phx.gbl... > Classic VB's file handling doesn't need to be defended. plain wrong). There are *plenty* of faults with VB's file handling. Michael C wrote:
> "Bob O`Bob" <filter***@yahoogroups.com> wrote in message You, too, are free to make your language choice a beauty contest.> news:%236qgAK6XHHA.1216@TK2MSFTNGP03.phx.gbl... >> Classic VB's file handling doesn't need to be defended. > > Another statement that just doesn't say anything except "I disagree" (and is > plain wrong). There are *plenty* of faults with VB's file handling. > > When you get right down to it, half of "getting stuff done" IS about the
beauty of the language. An inelegant language is harder to program in and typically less productive/more error prone, so language choice IS partly a beauty contest. Rob Show quoteHide quote "Bob O`Bob" <filter***@yahoogroups.com> wrote in message news:eP0AqZ6XHHA.3268@TK2MSFTNGP04.phx.gbl... > Michael C wrote: >> "Bob O`Bob" <filter***@yahoogroups.com> wrote in message >> news:%236qgAK6XHHA.1216@TK2MSFTNGP03.phx.gbl... >>> Classic VB's file handling doesn't need to be defended. >> >> Another statement that just doesn't say anything except "I disagree" (and >> is plain wrong). There are *plenty* of faults with VB's file handling. > > > You, too, are free to make your language choice a beauty contest. > Classic VB's file handling doesn't need to be defended. ROTFLMAO!!! You can't be serious?!? I dislike VB.NET as much as anyone here, but to say that Classic VB's file handling doesn't need to be defended is about the most ludicrous thing I've ever heard! It's a monstrosity! Rob On Mon, 05 Mar 2007 19:49:50 -0800, Bob O`Bob <filter***@yahoogroups.com> wrote:
¤ ¤ Classic VB's file handling doesn't need to be defended. Rather difficult to defend something that is syntactically non intuitive. Paul ~~~~ Microsoft MVP (Visual Basic) Sorry Bob, but I gotta go with him on that one too. I really do like VB6,
but file handling is not its strength, either in terms of raw power (I don't see SQL Server being written in VB) or in terms of programming elegance either. Rob Show quoteHide quote "Bob O`Bob" <filter***@yahoogroups.com> wrote in message news:O5Xnr75XHHA.4000@TK2MSFTNGP02.phx.gbl... > Michael C wrote: > >> And that is a good thing! You guys might like to work in the past but the >> vb file handling would have to be not only the worst feature in vb6 but >> the worst feature in any language that has ever existed (ok, maybe a >> slight exaggeration but not much). > > > Well, at least we've finally firmly established from which orifice your > "wisdom" spouts. > > -- Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
> Sorry Bob, but I gotta go with him on that one too. I really do like VB6, It's both simple *and* elegant. If it weren't, MSBasic wouldn't be the language > but file handling is not its strength, either in terms of raw power (I don't > see SQL Server being written in VB) or in terms of programming elegance > either. that outpaced COBOL for most lines of code written. Ever. I'm not talking about the language in general (which I think is fairly
elegant overall), I'm talking about the file handling in particular. For example, in what way is Open "C:\test.dat" For Random Access Read Write Lock Read Write As #1 Len=512 in ANY way elegant? While that's certainly the worst of them, the Print #, Get # and similar statements aren't exactly tidy in some of their permutations either. Object-orientation would have gone a long way to solving this inelegance, but I guess we're any number of years too late for that at this point. :) Rob Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:uuZHalBYHHA.4560@TK2MSFTNGP03.phx.gbl... > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> Sorry Bob, but I gotta go with him on that one too. I really do like >> VB6, >> but file handling is not its strength, either in terms of raw power (I >> don't >> see SQL Server being written in VB) or in terms of programming elegance >> either. > > It's both simple *and* elegant. If it weren't, MSBasic wouldn't be the > language that outpaced COBOL for most lines of code written. Ever. > -- > .NET: It's About Trust! > http://vfred.mvps.org > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
> I'm not talking about the language in general (which I think is fairly It really couldn't be simpler! That's the point.> elegant overall), I'm talking about the file handling in particular. For > example, in what way is > > Open "C:\test.dat" For Random Access Read Write Lock Read Write As #1 > Len=512 > > in ANY way elegant? Open [filename] For [usage] As [handle] Maybe you had to "grow up" on a command line to appreciate the clarity there? > While that's certainly the worst of them, I see it as *far* superior to any sort of object-based method, for both ease of use and comprehension. Any student programmer can grasp the fundamentals of this syntax in the first week of courses. > the Print #, Get # and similar statements aren't exactly tidy in some of their They're pretty danged straight-forward, too.> permutations either. > Object-orientation would have gone a long way to Only for accomplished snobs. For beginners, that means they need to spend *weeks*, > solving this inelegance, but I guess we're any number of years too late for > that at this point. :) at least, getting up to speed before they can even begin to accomplish anything useful. Not to mention, file i/o is the *last* place you want to introduce unnecessary overhead. So objects are inherently inefficient, in addition to being opaque. Toss newbs into the mix, and you have just prescribed a royal mess. > It really couldn't be simpler! That's the point. Nice theory, but I *did* grow up on a command-line. My first exposure to > > Open [filename] For [usage] As [handle] > > Maybe you had to "grow up" on a command line to appreciate the clarity > there? computers was in '77, and it was a TRS-80 as I remember it. For me, a MUCH more elegant solution would be somewhat similar to ADO's handling of recordsets: With MyFile .OpenMode = ReadWrite .Sharing = LockReadWrite .Open "filename" End With ....and dispense with what I consider to be the utterly archaic notion of file handles (or at least it's archaic in the sense of a properly developed 4GL; for something like lower-level API calls, obviously you'd still need them). > I see it as *far* superior to any sort of object-based method, for both We obviously see it differently, then. It seems that you see beauty where I > ease of use and comprehension. Any student programmer can grasp the > fundamentals of this syntax in the first week of courses. see The Hunchback of Notre Dame. And I've seen no end of student programmers who've looked at the syntax and run fleeing. Perhaps, as you say, it's because most of them ARE younger than you or I, but they don't see it as intuitive in any way. >> the Print #, Get # and similar statements aren't exactly tidy in some of Are you also a C programmer, by any chance? I've had any number of C >> their permutations either. > They're pretty danged straight-forward, too. programmers try to convince me that it's not cryptic either. I'll grant that in and of themselves, the commands are easy enough, though I would've preferred something like "MyFile.Output MyString" to "Print #MyFile, MyString", but I find the distinction between things like Input #/Line Input #/Get # and Print #/Write #/Put # to be a little esoteric. And I won't even get into the less-commonly used commands like Width #. I suppose it's a convenient enough command, but I'm of the opinion that the programmer should be doing that portion of the work, not the file system. > Only for accomplished snobs. For beginners, that means they need to spend Here again, I couldn't disagree with you more. My "With MyFile" example is > *weeks*, at least, getting up to speed before they can even begin to > accomplish anything useful. what I think *most* programmers would consider intuitive unless they think strictly in terms of 3GLs or even machine language. > Not to mention, file i/o is the *last* place you want to introduce Objects are not inherently inefficient (well, okay, maybe if you're working > unnecessary overhead. So objects are inherently inefficient, in addition > to being opaque. Toss newbs into the mix, and you have just prescribed a > royal mess. in VB.NET), and to say that they're opaque is oxymoronic to me. To me, and I *think* most people who learned programming in the last few decades, objects by their nature are more intuitive than 3GL/command-line style commands. And speed-wise, if the object is well-designed and built into the basic structure of the language, there should be no noticeable difference between the two. At the lowest level, it gets compiled into a function call with parameters either way. There might be a lookup table or something of that nature involved for an object's methods, but the indirection there wouldn't even take a nanosecond on any computer built within the last decade or so. In short, I would guess that you probably started programming even earlier than I did, and thus you're more deeply entrenched in the programming style of command lines and third-generation languages. While I learned on those and 65xx assembly language and the like, my "natural" thought processes lean more towards OOP. By the same token, however, I can see where my background comes into play, as I have significant difficulty with some of the VB.NET structures and programming styles. After all, who ever heard of calling methods or looking at properties of primitive data types? :) Rob Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
>> It really couldn't be simpler! That's the point. I sorta thought as much, which makes me wonder why the trouble with this >> >> Open [filename] For [usage] As [handle] >> >> Maybe you had to "grow up" on a command line to appreciate the clarity >> there? > > Nice theory, but I *did* grow up on a command-line. My first exposure to > computers was in '77, and it was a TRS-80 as I remember it. simple/elegant syntax. > For me, a MUCH more elegant solution would be somewhat similar to ADO's That's too many permutations and combinations for most beginners! Why be so > handling of recordsets: > > With MyFile > .OpenMode = ReadWrite > .Sharing = LockReadWrite > .Open "filename" > End With difficult? That's ivory-tower thinking, for a blue-collar problem. > ...and dispense with what I consider to be the utterly archaic notion of Abstraction from the metal only serves to incubate ignorance. While you have the > file handles (or at least it's archaic in the sense of a properly developed > 4GL; for something like lower-level API calls, obviously you'd still need > them). history, up-n-comers have no friggin' idea why things are as they are. It shows. >> I see it as *far* superior to any sort of object-based method, for both I *like* objects, don't get me wrong. And, they *can* be useful for abstracting >> ease of use and comprehension. Any student programmer can grasp the >> fundamentals of this syntax in the first week of courses. > > We obviously see it differently, then. It seems that you see beauty where I > see The Hunchback of Notre Dame. file i/o. But that's a few rungs up the ladder. If you don't grasp the basics, the rest will never flow. > And I've seen no end of student I never said "intuitive" did I? The syntax is *easily* memorized, though. (You got > programmers who've looked at the syntax and run fleeing. Perhaps, as you > say, it's because most of them ARE younger than you or I, but they don't see > it as intuitive in any way. an F1 key?) >>> the Print #, Get # and similar statements aren't exactly tidy in some of Only under extreme protest. <g>>>> their permutations either. >> >> They're pretty danged straight-forward, too. > > Are you also a C programmer, by any chance? > I've had any number of C It's not! Jeeez, I just can't imagine anything more straight-forward.> programmers try to convince me that it's not cryptic either. > I'll grant that in and of themselves, the commands are easy enough, Well, okay then! :-)> though I would've Print *really* isn't all that difficult. Write is a distraction. I often have to > preferred something like "MyFile.Output MyString" to "Print #MyFile, > MyString", but I find the distinction between things like Input #/Line Input > #/Get # and Print #/Write #/Put # to be a little esoteric. lookup Input syntax, as I don't generally use it. Get/Put are as basic as it gets, and the preferred alternative in nearly any situation. > And I won't even Build your strings in memory, and dump 'em to file with a single Put. Once you > get into the less-commonly used commands like Width #. I suppose it's a > convenient enough command, but I'm of the opinion that the programmer should > be doing that portion of the work, not the file system. realize the operational efficiencies there, none of this dithering will seem to have been worth the effort. >> Only for accomplished snobs. For beginners, that means they need to spend You've totally missed my point. Though you suggest you _can_ understand it.>> *weeks*, at least, getting up to speed before they can even begin to >> accomplish anything useful. > > Here again, I couldn't disagree with you more. My "With MyFile" example is > what I think *most* programmers would consider intuitive unless they think > strictly in terms of 3GLs or even machine language. >> Not to mention, file i/o is the *last* place you want to introduce Yes. They are. The closer you get to the metal, the more efficient you can be. >> unnecessary overhead. So objects are inherently inefficient, in addition >> to being opaque. Toss newbs into the mix, and you have just prescribed a >> royal mess. > > Objects are not inherently inefficient Objects stand in the way of getting things done, just as the lack of electricity really makes using that power drill difficult. > (well, okay, maybe if you're working in VB.NET), Especially so, there.> and to say that they're opaque is oxymoronic to me. Never heard the term "black box"?> To me, and You've evolved. That's no excuse to forsake those who follow.> I *think* most people who learned programming in the last few decades, > objects by their nature are more intuitive than 3GL/command-line style > commands. > And speed-wise, if the object is well-designed and built into the Never used FSO either, huh? <g>> basic structure of the language, there should be no noticeable difference > between the two. > At the lowest level, it gets compiled into a function call That potentially precludes you writing your own efficient wrappers, then. Not a > with parameters either way. There might be a lookup table or something of > that nature involved for an object's methods, but the indirection there > wouldn't even take a nanosecond on any computer built within the last decade > or so. good solution. > In short, I would guess that you probably started programming even earlier 1974, as I recall. And, yes, I definitely lean towards OOP-based solutions. (Ever > than I did, and thus you're more deeply entrenched in the programming style > of command lines and third-generation languages. While I learned on those > and 65xx assembly language and the like, my "natural" thought processes lean > more towards OOP. read my columns? http://vb.mvps.org/articles) > By the same token, however, I can see where my background Whoeever heard of a language that *lacked* such critters???> comes into play, as I have significant difficulty with some of the VB.NET > structures and programming styles. After all, who ever heard of calling > methods or looking at properties of primitive data types? :) On Tue, 6 Mar 2007 13:16:45 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >I'm not talking about the language in general (which I think is fairly That is very close to what happens at the API level, which is a>elegant overall), I'm talking about the file handling in particular. For >example, in what way is > Open "C:\test.dat" For Random Access Read Write Lock Read Write As #1 >Len=512 >in ANY way elegant? While that's certainly the worst of them, the Print #, >Get # and similar statements aren't exactly tidy in some of their >permutations either. Object-orientation would have gone a long way to >solving this inelegance, but I guess we're any number of years too late for >that at this point. :) development of the MSDOS Int 21h approach. I think you are saying that programmers should not have access to low level stuff, and should be forced to use more complicated structures. Personally I disagree, if I want to OO my file handling, then I want to write it myself, not use half as/ed implementations like the FSO that looks like it was written by a MS intern. > That is very close to what happens at the API level, which is a Yes, it's very close to Int 21h, but the point of higher-level languages is > development of the MSDOS Int 21h approach. to simplify that kind of low-level programming, not represent it verbatim. If that weren't the point, then higher-level languages would be unnecessary. That said, I think they should give you some kind of avenue to the lower-level calls where possible, which VB doesn't necessarily do the best job of. > I think you are saying that programmers should not have access to low Okay, maybe I'm misrepresenting myself, then. I'm not saying that you > level stuff, and should be forced to use more complicated structures. should be forced to use more complicated structures because I don't think of objects as inherently complicated...to me, they're inherently LESS complicated. But as I mentioned in another post, a function would serve the same purpose without requiring OO (and in retrospect, would probably be a better approach than OO anyway), while being a lot cleaner and easier to work with in terms of making things like Intellisense work, which it doesn't with the existing Open command. Oh, and just TRY offering your users record-locking and file-sharing options via a GUI (admittedly, not that common a need)...you're going to end up writing 20 separate Open commands just to handle all the permutations, because as far as I know, you can't use variables to handle the various options that you'll need to. > Personally I disagree, if I want to OO my file handling, then I want Yes, well, I think most people agree that FSO is a disaster. Let's not hold > to write it myself, not use half as/ed implementations like the FSO > that looks like it was written by a MS intern. up the worst of the worst as an example of why we shouldn't use the best of the best. Rob On Wed, 7 Mar 2007 12:57:44 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> That is very close to what happens at the API level, which is a Actually, under MSDOS we often tended to use our own file handling>> development of the MSDOS Int 21h approach. >Yes, it's very close to Int 21h, but the point of higher-level languages is >to simplify that kind of low-level programming, not represent it verbatim. >If that weren't the point, then higher-level languages would be unnecessary. >That said, I think they should give you some kind of avenue to the >lower-level calls where possible, which VB doesn't necessarily do the best >job of. stuff using Int 21h we had huge ASM libraries that we built up, and could do virtually anything with them. Show quoteHide quote >> I think you are saying that programmers should not have access to low I see your point>> level stuff, and should be forced to use more complicated structures. >Okay, maybe I'm misrepresenting myself, then. I'm not saying that you >should be forced to use more complicated structures because I don't think of >objects as inherently complicated...to me, they're inherently LESS >complicated. But as I mentioned in another post, a function would serve the >same purpose without requiring OO (and in retrospect, would probably be a >better approach than OO anyway), while being a lot cleaner and easier to >work with in terms of making things like Intellisense work, which it doesn't >with the existing Open command. Oh, and just TRY offering your users >record-locking and file-sharing options via a GUI (admittedly, not that >common a need)...you're going to end up writing 20 separate Open commands >just to handle all the permutations, because as far as I know, you can't use >variables to handle the various options that you'll need to. - personally I would have liked MS to improve their Intellisense >> Personally I disagree, if I want to OO my file handling, then I want Well, if one wants to write an Object to handle filing, then it is>> to write it myself, not use half as/ed implementations like the FSO >> that looks like it was written by a MS intern. >Yes, well, I think most people agree that FSO is a disaster. Let's not hold >up the worst of the worst as an example of why we shouldn't use the best of >the best. pretty easy - I've a number of those things for buffered file reading/writing. Actually OO stuff is not new, under MSDOS we were effectively doing just that. Call DoSomething( MyData ) is really the same as MyData.DoSomething although the latter is prettier Interestingly, a 'Handle' is actually an Object ... > Actually, under MSDOS we often tended to use our own file handling That makes sense. I've done a little 8086 programming, but not much, and > stuff using Int 21h we had huge ASM libraries that we built up, and > could do virtually anything with them. most of it has been in reverse engineering some VERY old programs into modern-day (at the time) languages :), so developing my own ASM libraries has never really come up. > Interestingly, a 'Handle' is actually an Object ... Well...a pointer to an object, anyway. :) Unless you meant that a handle was an object like the cupboard it's mounted on is an object. <eg> Rob On Thu, 8 Mar 2007 11:04:12 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> Actually, under MSDOS we often tended to use our own file handling I was working for a City financial software house and some of us got>> stuff using Int 21h we had huge ASM libraries that we built up, and >> could do virtually anything with them. >That makes sense. I've done a little 8086 programming, but not much, and >most of it has been in reverse engineering some VERY old programs into >modern-day (at the time) languages :), so developing my own ASM libraries >has never really come up. into ASM for doing things that were impossible in the version of MS BASIC we were using, over a few years we built up libraries that allowed us to do just about anything - I even had BASIC going TSR They were great days. >> Interestingly, a 'Handle' is actually an Object ... Being pedantic, a 'handle' can be a reference to an Object, but the>Well...a pointer to an object, anyway. :) Unless you meant that a handle >was an object like the cupboard it's mounted on is an object. <eg> main thing is that OO is not a new concept, although later implementations are much nicer to work with. > Being pedantic I've been accused of that before. :)> a 'handle' can be a reference to an Object, but the I'm not sure if I would entirely agree that it's "truly" OO if you're > main thing is that OO is not a new concept, although later > implementations are much nicer to work with. passing a handle around, but the difference is really just a matter of semantics. MyOject.DoStuff and DoStuff(MyObject) get you to the same place in the end. I definitely agree about the "nicer to work with" part, though...absolutely no arguments there. :) Rob On Tue, 6 Mar 2007 13:50:58 +1100, "Michael C" <nospam@nospam.com> Print "Hullo World" ?wrote: >"Karl E. Peterson" <k***@mvps.org> wrote in message >news:Oq9SPA5XHHA.3268@TK2MSFTNGP04.phx.gbl... >> That simply isn't true. >Well it simply is true. If a basic dos app writes to the screen it's not >going to do much in vb6. Maybe you are thinking of A$ = Input$(1) or A$ = Inkey$ Even those can be achieved quite easily with VB5/6 Of course Locate disappeared, but that is pretty easy to emulate A flashing cursor takes a little ingenuity, but it is not difficult I ported a large Basic 7.1 sequential App over to VB, it 'printed' all its screens, used the equivalent of Inkey$ and had a block cursor. Not a Visual control in sight (well there was just one, but it did not need to be there). Mostly it was just cut and paste, although I tended to use Classes to restrict scope. >> Just last year, I sucked some QB4 code directly into VB6. What did it do? What is wrong with VB's file handling ?>> Binary DBF handling. True, once I confirmed it was working (key point >> there!), I was able to "objectify" it. It became far prettier, but I >> could easily run/edit/test/compile it right within VB6. No sort of binary >> file i/o is portable between VB6<->VFred. >And that is a good thing! You guys might like to work in the past but the vb >file handling would have to be not only the worst feature in vb6 but the >worst feature in any language that has ever existed (ok, maybe a slight >exaggeration but not much). It is just a thin shell over the underlying APIs It would be nice if we could still get at the underlying file handle, but that is not the end of the world. Michael C <nospam@nospam.com> wrote:
> "Karl E. Peterson" <k***@mvps.org> wrote in message Pffft! The same could be said for a DOS app whose client got a wild hair and all of > news:Oq9SPA5XHHA.3268@TK2MSFTNGP04.phx.gbl... >> That simply isn't true. > > Well it simply is true. If a basic dos app writes to the screen it's not > going to do much in vb6. a sudden wanted it to work in SCREEN 13 mode. You change your output device, you change your output method. That's a fundamental fact of life, regardless of language. >> Just last year, I sucked some QB4 code directly into VB6. What did it do? Never has there been a simpler, or more elegant, approach devised. Indeed, one that >> Binary DBF handling. True, once I confirmed it was working (key point >> there!), I was able to "objectify" it. It became far prettier, but I >> could easily run/edit/test/compile it right within VB6. No sort of binary >> file i/o is portable between VB6<->VFred. > > And that is a good thing! You guys might like to work in the past but the vb > file handling would have to be not only the worst feature in vb6 but the > worst feature in any language that has ever existed (ok, maybe a slight > exaggeration but not much). empowered *millions* of non-programmers with the ability to actually "Get 'er done!" You, sir, are a snob of the rankest order. > Never has there been a simpler, or more elegant, approach devised. Much as with Bob's reply, I have to laugh at that kind of assertion. See my > Indeed, one that empowered *millions* of non-programmers with the ability > to actually "Get 'er done!" other post. "Simple" and "elegant" are NOT words I would use in conjunction with VB's various file statements, and are one of the things I've heard the most complaints about from language newbies over the years. Rob Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
>> Never has there been a simpler, or more elegant, approach devised. Not sure if that's ignorance or arrogance laughing? Definitely one of the two, but >> Indeed, one that empowered *millions* of non-programmers with the ability >> to actually "Get 'er done!" > > Much as with Bob's reply, I have to laugh at that kind of assertion. See my > other post. perhaps a mix. > "Simple" and "elegant" are NOT words I would use in conjunction Heh... Perhaps from *language* newbies, but definitely not from *programming* > with VB's various file statements, and are one of the things I've heard the > most complaints about from language newbies over the years. newbies. World of difference there. (Argues in favor of the 'arrogance' supposition, above.) >> Much as with Bob's reply, I have to laugh at that kind of assertion. See Neither. Again, my other post goes into detail, so I won't here. We simply >> my >> other post. > Not sure if that's ignorance or arrogance laughing? Definitely one of the > two, but perhaps a mix. see programming from different angles; that doesn't make either of our outlooks invalid, just incomprehensible to one another. >> "Simple" and "elegant" are NOT words I would use in conjunction It depends on the languages they were raised in. As I said in my other >> with VB's various file statements, and are one of the things I've heard >> the >> most complaints about from language newbies over the years. > Heh... Perhaps from *language* newbies, but definitely not from > *programming* newbies. World of difference there. (Argues in favor of > the 'arrogance' supposition, above.) post, for those who are entrenched in command lines, perhaps it makes perfect sense...for me, it's archaic and unwieldy. Rob Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
>>> "Simple" and "elegant" are NOT words I would use in conjunction WRONG! That's the point, as well. To *learn* programming, objects are a bad way to >>> with VB's various file statements, and are one of the things I've heard >>> the most complaints about from language newbies over the years. > >> Heh... Perhaps from *language* newbies, but definitely not from >> *programming* newbies. World of difference there. (Argues in favor of >> the 'arrogance' supposition, above.) > > It depends on the languages they were raised in. start. Okay, at the risk of crossing sub-threads, I'm gonna respond to this
message, because I think it summarizes the fundamental point of the other one, without being several screens long. :) > WRONG! That's the point, as well. To *learn* programming, objects are a This is something of a different point than the other. We'll leave .NET out > bad way to start. of this discussion, since that would just obfuscate your point (seeing as pretty much EVERYTHING is an Object there). I suppose I would agree with your statement above, at least insofar as any programmer worth their money is concerned. If you want to write a two-bit program that does little more than "Hello World", I'm not sure it matters whether you start with objects or not. Certainly if you want to get into things like designing your own classes and such, I think you'd better know a bit more about the fundamentals than objects alone. They may provide an appropriate context to your learning, though, so whether they should be introduced only later, or presented in tandem with lower-level techniques is up for debate. But I'm not an instructor, so I won't try to debate the best option there. But the original point wasn't whether or not objects are a good way to learn programming, but whether or not the syntax of file handling in VB was good or not. And I'd have to say that while it may provide a good insight to how things work at a low level, I still think there were MUCH better ways to design it, even if you avoid OOP entirely. Take for example, this function...why not incorporate THIS into the language as the main way of opening files instead of what I consider to be the horrible syntax they're using. (This wouldn't work as written, and you'd probably want to add more to it in terms of handling various things, but it demonstrates the point, anyway.) Public Function OpenFile(ByVal strFileName As String, _ Optional ByVal OpenMode As OpenModeEnum, _ Optional ByVal IOMode As IOModeEnum, _ Optional ByVal LockMode As LockModeEnum, _ Optional ByVal lngRecordLength As Long) As Integer Dim intFileNum As Integer intFileNum = FreeFile() Open strFileName For OpenMode IOMode LockMode As intFileNum Len = lngRecordLength OpenFile = intFileNum End Function Then opening a file would be a standard function call with parameters that would show up in Intellisense. Wouldn't that make a hell of a lot more sense than the clunky format they chose to use instead? Written that way at the low level, I doubt there would've been any speed differences, since either way, you're wrapping around system calls. And after all, most other non-primitive language elements are function calls or OOP (mind is blanking on the proper term, but by "primitive" I mean things like comparison operators, math, assignments, etc.). Same thing goes for the "Name" statement. Pretty straightforward (in fact, I'll even go so far as to say simpler than a sub), but to my mind, it still would've made a lot more sense to have it as a sub like almost everything else, rather than a statement of its own that doesn't match the grammar of the rest of the language. That's how I see things, anyways. Rob
Show quote
Hide quote
"Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> skrev i meddelandet And for a tired eye, where is the differens in calling OpenFile and actuallynews:uRM%238FEYHHA.4552@TK2MSFTNGP05.phx.gbl... > Okay, at the risk of crossing sub-threads, I'm gonna respond to this > message, because I think it summarizes the fundamental point of the other > one, without being several screens long. :) > > > WRONG! That's the point, as well. To *learn* programming, objects are a > > bad way to start. > > This is something of a different point than the other. We'll leave .NET out > of this discussion, since that would just obfuscate your point (seeing as > pretty much EVERYTHING is an Object there). I suppose I would agree with > your statement above, at least insofar as any programmer worth their money > is concerned. If you want to write a two-bit program that does little more > than "Hello World", I'm not sure it matters whether you start with objects > or not. Certainly if you want to get into things like designing your own > classes and such, I think you'd better know a bit more about the > fundamentals than objects alone. They may provide an appropriate context to > your learning, though, so whether they should be introduced only later, or > presented in tandem with lower-level techniques is up for debate. But I'm > not an instructor, so I won't try to debate the best option there. > > But the original point wasn't whether or not objects are a good way to learn > programming, but whether or not the syntax of file handling in VB was good > or not. And I'd have to say that while it may provide a good insight to how > things work at a low level, I still think there were MUCH better ways to > design it, even if you avoid OOP entirely. Take for example, this > function...why not incorporate THIS into the language as the main way of > opening files instead of what I consider to be the horrible syntax they're > using. (This wouldn't work as written, and you'd probably want to add more > to it in terms of handling various things, but it demonstrates the point, > anyway.) > > Public Function OpenFile(ByVal strFileName As String, _ > Optional ByVal OpenMode As OpenModeEnum, _ > Optional ByVal IOMode As IOModeEnum, _ > Optional ByVal LockMode As LockModeEnum, _ > Optional ByVal lngRecordLength As Long) As Integer > > Dim intFileNum As Integer > > intFileNum = FreeFile() > Open strFileName For OpenMode IOMode LockMode As intFileNum Len = > lngRecordLength > OpenFile = intFileNum > End Function > > Then opening a file would be a standard function call with parameters that > would show up in Intellisense. Wouldn't that make a hell of a lot more > sense than the clunky format they chose to use instead? Written that way at > the low level, I doubt there would've been any speed differences, since > either way, you're wrapping around system calls. And after all, most other > non-primitive language elements are function calls or OOP (mind is blanking > on the proper term, but by "primitive" I mean things like comparison > operators, math, assignments, etc.). Same thing goes for the "Name" > statement. Pretty straightforward (in fact, I'll even go so far as to say > simpler than a sub), but to my mind, it still would've made a lot more sense > to have it as a sub like almost everything else, rather than a statement of > its own that doesn't match the grammar of the rest of the language. > > That's how I see things, anyways. > > > > Rob > Open the file? /Henning > And for a tired eye, where is the differens in calling OpenFile and In the style and homogeneity of the language, as well as the ability to make > actually > Open the file? use of the GUI features like Intellisense. Rob Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
Show quoteHide quote > Okay, at the risk of crossing sub-threads, I'm gonna respond to this Surprise, surprise, surprise... We agree! :-)> message, because I think it summarizes the fundamental point of the other > one, without being several screens long. :) > >> WRONG! That's the point, as well. To *learn* programming, objects are a >> bad way to start. > > This is something of a different point than the other. We'll leave .NET out > of this discussion, since that would just obfuscate your point (seeing as > pretty much EVERYTHING is an Object there). I suppose I would agree with > your statement above, at least insofar as any programmer worth their money > is concerned. If you want to write a two-bit program that does little more > than "Hello World", I'm not sure it matters whether you start with objects > or not. Certainly if you want to get into things like designing your own > classes and such, I think you'd better know a bit more about the > fundamentals than objects alone. They may provide an appropriate context to > your learning, though, so whether they should be introduced only later, or > presented in tandem with lower-level techniques is up for debate. But I'm > not an instructor, so I won't try to debate the best option there. > But the original point wasn't whether or not objects are a good way to learn Considering MSBasic is/was, at its core, a learning language (albeit one that could > programming, but whether or not the syntax of file handling in VB was good > or not. subsequently be leveraged to do just about anything!), it seems your definition of "good" is somewhat contextually removed. > And I'd have to say that while it may provide a good insight to how Well, because. <g> The *original* BASIC didn't have functions, per se. Certainly > things work at a low level, I still think there were MUCH better ways to > design it, even if you avoid OOP entirely. Take for example, this > function...why not incorporate THIS into the language as the main way of > opening files instead of what I consider to be the horrible syntax they're > using. nothing on a complexity scale such as that. And, since those very first days at Dartmouth, the objective was to always allow code to move forward. That is, until that fateful day in 2001 when forward-compatability was declared obsolete. Show quoteHide quote > (This wouldn't work as written, and you'd probably want to add more And besides, you've pretty much just replicated the intrinsic Open statement, with > to it in terms of handling various things, but it demonstrates the point, > anyway.) > > Public Function OpenFile(ByVal strFileName As String, _ > Optional ByVal OpenMode As OpenModeEnum, _ > Optional ByVal IOMode As IOModeEnum, _ > Optional ByVal LockMode As LockModeEnum, _ > Optional ByVal lngRecordLength As Long) As Integer > > Dim intFileNum As Integer > > intFileNum = FreeFile() > Open strFileName For OpenMode IOMode LockMode As intFileNum Len = > lngRecordLength > OpenFile = intFileNum > End Function the *only* possible real benefit being that it could now support Intellisense. > Then opening a file would be a standard function call with parameters that I swear, I didn't read ahead. <g>> would show up in Intellisense. > Wouldn't that make a hell of a lot more See: Forward-Compatability. Or,> sense than the clunky format they chose to use instead? Language Stability http://vb.mvps.org/tips/stability.asp > Written that way at Well, there ya go again. <g> The stuff you're complaining about goes back to > the low level, I doubt there would've been any speed differences, since > either way, you're wrapping around system calls. And after all, most other > non-primitive language elements are function calls or OOP (mind is blanking > on the proper term, but by "primitive" I mean things like comparison > operators, math, assignments, etc.). Same thing goes for the "Name" > statement. Pretty straightforward (in fact, I'll even go so far as to say > simpler than a sub), but to my mind, it still would've made a lot more sense > to have it as a sub like almost everything else, rather than a statement of > its own that doesn't match the grammar of the rest of the language. Dartmouth. It's the price we pay for being able to reuse our code. And it's really not *that* bad. Really. :-) Okay, so the obvious choice would be to do leave the backwards compatibility
there, but offer the function as the newer & better way of doing things...MS was always good at that! (c.f., that fateful day in 2001 that you mentioned, and the other thread about ini files vs. registry, and the various OS's, and the various versions of Office, and... and... and... <g>). Rob Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:O3EgceEYHHA.3272@TK2MSFTNGP03.phx.gbl... > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> Okay, at the risk of crossing sub-threads, I'm gonna respond to this >> message, because I think it summarizes the fundamental point of the other >> one, without being several screens long. :) >> >>> WRONG! That's the point, as well. To *learn* programming, objects are >>> a >>> bad way to start. >> >> This is something of a different point than the other. We'll leave .NET >> out >> of this discussion, since that would just obfuscate your point (seeing as >> pretty much EVERYTHING is an Object there). I suppose I would agree with >> your statement above, at least insofar as any programmer worth their >> money >> is concerned. If you want to write a two-bit program that does little >> more >> than "Hello World", I'm not sure it matters whether you start with >> objects >> or not. Certainly if you want to get into things like designing your own >> classes and such, I think you'd better know a bit more about the >> fundamentals than objects alone. They may provide an appropriate context >> to >> your learning, though, so whether they should be introduced only later, >> or >> presented in tandem with lower-level techniques is up for debate. But >> I'm >> not an instructor, so I won't try to debate the best option there. > > Surprise, surprise, surprise... We agree! :-) > >> But the original point wasn't whether or not objects are a good way to >> learn >> programming, but whether or not the syntax of file handling in VB was >> good >> or not. > > Considering MSBasic is/was, at its core, a learning language (albeit one > that could subsequently be leveraged to do just about anything!), it seems > your definition of "good" is somewhat contextually removed. > >> And I'd have to say that while it may provide a good insight to how >> things work at a low level, I still think there were MUCH better ways to >> design it, even if you avoid OOP entirely. Take for example, this >> function...why not incorporate THIS into the language as the main way of >> opening files instead of what I consider to be the horrible syntax >> they're >> using. > > Well, because. <g> The *original* BASIC didn't have functions, per se. > Certainly nothing on a complexity scale such as that. And, since those > very first days at Dartmouth, the objective was to always allow code to > move forward. That is, until that fateful day in 2001 when > forward-compatability was declared obsolete. > >> (This wouldn't work as written, and you'd probably want to add more >> to it in terms of handling various things, but it demonstrates the point, >> anyway.) >> >> Public Function OpenFile(ByVal strFileName As String, _ >> Optional ByVal OpenMode As OpenModeEnum, _ >> Optional ByVal IOMode As IOModeEnum, _ >> Optional ByVal LockMode As LockModeEnum, _ >> Optional ByVal lngRecordLength As Long) As Integer >> >> Dim intFileNum As Integer >> >> intFileNum = FreeFile() >> Open strFileName For OpenMode IOMode LockMode As intFileNum Len = >> lngRecordLength >> OpenFile = intFileNum >> End Function > > And besides, you've pretty much just replicated the intrinsic Open > statement, with the *only* possible real benefit being that it could now > support Intellisense. > >> Then opening a file would be a standard function call with parameters >> that >> would show up in Intellisense. > > I swear, I didn't read ahead. <g> > >> Wouldn't that make a hell of a lot more >> sense than the clunky format they chose to use instead? > > See: Forward-Compatability. Or, > > Language Stability > http://vb.mvps.org/tips/stability.asp > >> Written that way at >> the low level, I doubt there would've been any speed differences, since >> either way, you're wrapping around system calls. And after all, most >> other >> non-primitive language elements are function calls or OOP (mind is >> blanking >> on the proper term, but by "primitive" I mean things like comparison >> operators, math, assignments, etc.). Same thing goes for the "Name" >> statement. Pretty straightforward (in fact, I'll even go so far as to >> say >> simpler than a sub), but to my mind, it still would've made a lot more >> sense >> to have it as a sub like almost everything else, rather than a statement >> of >> its own that doesn't match the grammar of the rest of the language. > > Well, there ya go again. <g> The stuff you're complaining about goes back > to Dartmouth. It's the price we pay for being able to reuse our code. > And it's really not *that* bad. Really. :-) > -- > .NET: It's About Trust! > http://vfred.mvps.org > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
> Okay, so the obvious choice would be to do leave the backwards compatibility No need to quote Gomer again, I see. :-)> there, but offer the function as the newer & better way of doing things...MS > was always good at that! (c.f., that fateful day in 2001 that you > mentioned, and the other thread about ini files vs. registry, and the > various OS's, and the various versions of Office, and... and... and... <g>). Nothing wrong with new ways to do stuff! Nothing at all. The only real obligation of the language vendor, though, is to maintain the investment of their customer by insuring that the old way moves forward. (At least for a few releases, as proposed in already cited "Language Stability" whitepaper.) Robert Morley wrote:
> Okay, so the obvious choice would be to do leave the backwards compatibility The way it is, anyone who really desires it can write a wrapper function anyway.> there, but offer the function as the newer & better way of doing things... Bob -- Not readily...at least not as far as I know. I don't BELIEVE you can write
any kind of statement like I did in my pseudo-function, where I used variables to specify the open modes. Unless I miss my guess, you'd have to have a separate case in your function for every permutation of the various open modes, read/write modes and sharing modes. Doable, yes, but UGLY! Rob Show quoteHide quote "Bob O`Bob" <filter***@yahoogroups.com> wrote in message news:uvEWeDFYHHA.4692@TK2MSFTNGP04.phx.gbl... > Robert Morley wrote: >> Okay, so the obvious choice would be to do leave the backwards >> compatibility there, but offer the function as the newer & better way of >> doing things... > > > The way it is, anyone who really desires it can write a wrapper function > anyway. > > > > Bob > -- Karl E. Peterson wrote:
> Well, because. <g> The *original* BASIC didn't have functions, per se. Certainly The PDC in Orlando was July 11th-14th, 2000> nothing on a complexity scale such as that. And, since those very first days at > Dartmouth, the objective was to always allow code to move forward. That is, until > that fateful day in 2001 when forward-compatability was declared obsolete. Bob -- Robert Morley wrote:
> But the original point wasn't whether or not objects are a good way to learn You're viewing the thread through "syntax of" colored glasses.> programming, but whether or not the syntax of file handling in VB was good > or not. Like I've said time and time again, if you want a beauty contest, fine, just know that's all you're getting. Bob -- And as I replied at some point in this thread, the beauty of the language is
half the battle. A cryptic or cumbersome language will take longer to program in and be more prone to errors. In a way, that's why we've evolved from BASIC with line numbers and GOTO and all kinds of other things to the more modern versions. They're more elegant and less error prone in addition to being more powerful overall. Rob Show quoteHide quote "Bob O`Bob" <filter***@yahoogroups.com> wrote in message news:%23%23tu0%23EYHHA.4692@TK2MSFTNGP04.phx.gbl... > Robert Morley wrote: > >> But the original point wasn't whether or not objects are a good way to >> learn programming, but whether or not the syntax of file handling in VB >> was good or not. > > > You're viewing the thread through "syntax of" colored glasses. > > Like I've said time and time again, if you want a beauty contest, fine, > just know that's all you're getting. > > > > Bob > -- Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
> And as I replied at some point in this thread, the beauty of the language is Ah, but *not* as long as a language that prevents reusing the code, once it's > half the battle. A cryptic or cumbersome language will take longer to > program in and be more prone to errors. written and debugged! True enough, but we're not talking about migrating to .NET. :)
Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:erFmBqFYHHA.4008@TK2MSFTNGP05.phx.gbl... > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> And as I replied at some point in this thread, the beauty of the language >> is >> half the battle. A cryptic or cumbersome language will take longer to >> program in and be more prone to errors. > > Ah, but *not* as long as a language that prevents reusing the code, once > it's written and debugged! > -- > .NET: It's About Trust! > http://vfred.mvps.org > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
> "Karl E. Peterson" <k***@mvps.org> wrote in message The allusion was that transparent, was it? I wonder why... <g>> news:erFmBqFYHHA.4008@TK2MSFTNGP05.phx.gbl... >> Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >>> And as I replied at some point in this thread, the beauty of the language >>> is half the battle. A cryptic or cumbersome language will take longer to >>> program in and be more prone to errors. >> >> Ah, but *not* as long as a language that prevents reusing the code, once >> it's written and debugged! > > True enough, but we're not talking about migrating to .NET. :) Bottom line, as *wonderful* as Intellisense is, it's nowhere near worth giving up functional/tested code for! Fair enough, but VB6 could easily have provided both a function and the
older syntax as well. Rob Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:ut$pTXOYHHA.992@TK2MSFTNGP04.phx.gbl... > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> "Karl E. Peterson" <k***@mvps.org> wrote in message >> news:erFmBqFYHHA.4008@TK2MSFTNGP05.phx.gbl... >>> Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >>>> And as I replied at some point in this thread, the beauty of the >>>> language >>>> is half the battle. A cryptic or cumbersome language will take longer >>>> to >>>> program in and be more prone to errors. >>> >>> Ah, but *not* as long as a language that prevents reusing the code, once >>> it's written and debugged! >> >> True enough, but we're not talking about migrating to .NET. :) > > The allusion was that transparent, was it? I wonder why... <g> > > Bottom line, as *wonderful* as Intellisense is, it's nowhere near worth > giving up functional/tested code for! > -- > .NET: It's About Trust! > http://vfred.mvps.org > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
Show quoteHide quote > "Karl E. Peterson" <k***@mvps.org> wrote in message Would've been a welcome improvement to the language! :-)> news:ut$pTXOYHHA.992@TK2MSFTNGP04.phx.gbl... >> Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >>> "Karl E. Peterson" <k***@mvps.org> wrote in message >>> news:erFmBqFYHHA.4008@TK2MSFTNGP05.phx.gbl... >>>> Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >>>>> And as I replied at some point in this thread, the beauty of the >>>>> language >>>>> is half the battle. A cryptic or cumbersome language will take longer >>>>> to >>>>> program in and be more prone to errors. >>>> >>>> Ah, but *not* as long as a language that prevents reusing the code, once >>>> it's written and debugged! >>> >>> True enough, but we're not talking about migrating to .NET. :) >> >> The allusion was that transparent, was it? I wonder why... <g> >> >> Bottom line, as *wonderful* as Intellisense is, it's nowhere near worth >> giving up functional/tested code for! > > Fair enough, but VB6 could easily have provided both a function and the > older syntax as well. Robert Morley wrote:
>> Never has there been a simpler, or more elegant, approach devised. Having done a few semesters as a university instructor, I suspect I've>> Indeed, one that empowered *millions* of non-programmers with the ability >> to actually "Get 'er done!" > > Much as with Bob's reply, I have to laugh at that kind of assertion. See my > other post. "Simple" and "elegant" are NOT words I would use in conjunction > with VB's various file statements, and are one of the things I've heard the > most complaints about from language newbies over the years. dealt face-to-face with more "newbies" than most people who post here. And while file I/O has always been a relatively /boring/ part of the curriculum, it's never even remotely been a difficult one for my students. Yeah, it's verbose. But there's /value/ there. It's vital to remember that the "audience" for source code is other humans. Bob -- "Michael C" <nospam@nospam.com> wrote in message Yes they did! If you think that earlier version of BASIC were not capable of news:%23uEMtz3XHHA.2636@TK2MSFTNGP06.phx.gbl... > > They mustn't do much though. They obviously can't draw to the screen. drawing to the screen then you need to think again! The Print method draws to the screen, and that has been an essential part of the BASIC language for over thirty years! And lots of versions of BASIC I have used over the years have had various drawing methods such as Circle and many others. Mike Michael C wrote:
> "Mike Williams" <m***@whiskyandCoke.com> wrote in message That's more to do with the DOS/Windows API than the languages > news:uUhjtq3XHHA.2436@TK2MSFTNGP06.phx.gbl... >> I'm not "under exaggerating", Michael. I have written BASIC programs for >> almost thirty years and many of even my very earliest BASIC programs would >> run with no problems whatsoever if I pasted them into a VB6 Button Click >> event, for example. > > They mustn't do much though. They obviously can't draw to the screen. themselves, and you know it. >> But not a single one of them would run in dotnet. Not even the simplest of It didn't need to be restricted, only to be backwards compatible without >> them. Not even most of the "one liners". > > That is likely true but restricting vb.net to vb6 syntax would have held it > back a *huge* amount. breaking changes. Adding new things is a good thing (when done with careful thought). Breaking old behaviour is always bad. For example, they could have added .NET's file I/O *in addition to* keeping the VB6 way. The only two things they needed to change were: deterministic finalization and running in the .NET framework. Even then, the option to compile to native should be there (like it is for C++). > Can you imagine our nicely oop language being infected If you don't like a part of the language, and can avoid it, then don't > with gosubs, gotos etc? use it - simple as that. C++ still has goto, despite being looked down upon by most. >> A massive number of changes! The *tokens* of VB6 and VB.NET are very similar. However the *grammars* >> >>> but it's still the same basic syntax >> No it isn't, Michael. It is massively different. > > It's basically the same. of VB6 and VB.NET are only fairly similar (Dim, As, Function; Sub; Type; [With]; Public; Private; For...Next; Exit <Block>; [Property]; . as scope operator; function calls ...) but not the "basically the same" (File I/O; Error handling; GoSub/GoTo; Mixed Visibility Properties ... ). Therefore the languages cannot be considered the same, not only because the grammars are significantly different (Had VB.NET merely _extended_ VB6's grammar then they might be considered that might be ) but also because many items' *semantics* have been removed or changed (Return; Variant; Dimensioning arrays; On Error; String; Long; Integer; Dim x, y as Type). Syntax = Tokens + Grammar. (http://en.wikipedia.org/wiki/Syntax_of_programming_languages , summarised) Language = (At least) Syntax + Semantics. (My definition) It's the same with java and C++. They use almost identical tokens, similar grammars (but with significant differences) and different semantics (e.g. How many java operations are "implementation defined"). Do you consider java and C++ to be "basically the same"? Show quoteHide quote >> It's not something I've bothered to actually quantify. It's more of a "gut It's not the learning curve that's the issue: any programmer worth their >> feeling" thing, although you could certainly quantify it if you wished to >> do so. As I said earlier, I've been programming for nearly thirty years >> (machine code, Assembler, Fortran and BASIC) and when I picked up my first >> copy of Visual Basic (which I didn't bother doing until VB5 came out, >> because I was busy with other languages at the time) I was almost >> immediately comfortable with it. It was BASIC, but with some extra bells >> and whistles. There was of course a slight learning curve because of the >> event driven nature of VB5 (which was new to me) but nevertheless I felt >> at home almost straight away and I could convert even the oldest of my >> previous BASIC programs to VB5 very quickly and with very few problems. >> Dotnet is not like that. > > There is a slight learning curve but it's really not that bad. It's > definately less of learning curve to going from a dos language to an event > driven language (if you think back, learning events wasn't that easy, it > could get complicated). salt will be able to pick up new languages fairly quickly (they will need to, as the set of languages in use changes). The issue is taking old code, that behaved one way, and knowing that it will behave the same way in what is supposed to be the next version of a language. >> Not like that at all. As far as I am concerned, dotnet is not BASIC at Wrong, you've confused "syntax" with merely "tokens" again. But at >> all. The only relationship dotnet has to the old BASIC is that the >> Micro$oft sales team have persuaded the Micro$oft programmers to "graft >> onto it" a large number of "Basic sounding constructs" in an attempt to >> persuade people that it is something which it isn't! Their underhand ploy >> hasn't worked for me, although I'm sure lots of people will be taken in by >> it, at least until they have parted with their money. > > You can design a form just like vb6 and all the syntax is still basic > syntax. It's both visual and basic :-) least you're right about the visual bit - no-one denies the right of Fred to be called _Visual_ Fred, it's just the Basic bit that's at odds with reality. <g> Stewart
Show quote
Hide quote
"Mike Williams" <m***@whiskyandCoke.com> skrev i meddelandet Even old PowerBasic code can rather easy be made to run. A few Find/Replacenews:ONONYEyXHHA.1388@TK2MSFTNGP05.phx.gbl... > "Michael C" <nospam@nospam.com> wrote in message > news:uhCGJOrXHHA.2636@TK2MSFTNGP06.phx.gbl... > > >> Perhaps they should have left the word Basic out of Visual > >> Basic 1.0 as well. Maybe they could have called it Visual > >> DooDad or something like that because it really isn't Basic > >> but a completely different language that I had to learn and > >> master. ;-) > > > Well said. Pity mike missed the whole thing and just repeated his rant. > > You're quite wrong. Visual Basic 6 and below *are* essentially the same as > the old versions of BASIC. The only difference is that Visual Basic is > essentially event driven whereas the old versions of BASIC were sequential. > But the old BASIC sequential code will still run in Visual Basic (VB6 and > below), and it will still run in its old sequential mode if you wish, > including line numbers and GoSubs and Returns and almost everything else. In > many cases (although not in all cases of course) you can just "copy and > paste" an entire old fashioned BASIC program (line numbers and Gosub and > all) into a VB6 Command Button click event and click the button and it will > run. There are a few things you will need to alter, particularly when > dealing with keyboard input, but not many. You can't do that, or anything > like it, in Visual FredNet (or whatever they are calling it now). In Visual > FredNet not even a simple Print "Hello World" will work without > modification! VB6 is as much like the old fashioned BASIC as you can get for > a language that is event driven. If you personally looked on it as something > completely new that you had to learn and master from scratch, as you have > suggested, then perhaps you . . . (to be continued)! > > Mike > > > and they work. /Henning Paul Clement wrote:
> Perhaps they should have left the word Basic out of Visual Basic 1.0 Not that I really want to get into a slanging war, but VB isn't completely > as well. Maybe they could have called it Visual DooDad or something > like that because it really isn't Basic but a completely different > language that I had to learn and master. ;-) different to Basic - I still have Basic code (QBasic I believe - mainly Astonomical calulations stuff) which run perfectly well in VB Classic of any version. -- Regards, Michael Cole "Michael Cole" <no***@microsoft.com.au> wrote in message On the other hand, Visual DooDad is an even better name name Visual Fred fornews:%23NrWiasXHHA.3656@TK2MSFTNGP05.phx.gbl > Paul Clement wrote: > >> Perhaps they should have left the word Basic out of Visual Basic 1.0 >> as well. Maybe they could have called it Visual DooDad or something >> like that because it really isn't Basic but a completely different >> language that I had to learn and master. ;-) > > Not that I really want to get into a slanging war, but VB isn't > completely different to Basic - I still have Basic code (QBasic I > believe - mainly Astonomical calulations stuff) which run perfectly > well in VB Classic of any version. whatever that thing is. -- Reply to the group so all can participate VB.Net: "Fool me once..." On Feb 23, 10:16 am, Paul Clement
<UseAdddressAtEndofMess***@swspectrum.com> wrote: > Actually it was implemented in Visual Basic.NET 2003. Well, I definitely don't need a shift operator that desperately :). I> never thought MS would invent a framework worse than MFC, but lo' and behold, they succeeded with .NET. What would be ideal would be if MS would simply opensource their VB6 compiler and let independents pound it into something that works better--but that's obviously not going to happen... I guess I'll just have to learn to work with what I've got. -- Daniel Cannon AmiDaniel <cannon.dani***@gmail.com> wrote:
> On Feb 23, 10:16 am, Paul Clement Heh, so you've met our resident evangelist! Repeat after me:> <UseAdddressAtEndofMess***@swspectrum.com> wrote: >> Actually it was implemented in Visual Basic.NET 2003. > > Well, I definitely don't need a shift operator that desperately :). "Bite me, Paul!" :-) <g>> never thought MS would invent a framework worse than MFC, but lo' and > behold, they succeeded with .NET. > What would be ideal would be if MS would simply opensource their VB6 The problem of theirs that just continues to grow -- they *are* their own best > compiler and let independents pound it into something that works > better--but that's obviously not going to happen... I guess I'll just > have to learn to work with what I've got. competition. On Fri, 23 Feb 2007 14:52:16 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: ¤ > Well, I definitely don't need a shift operator that desperately :).¤ ¤ Heh, so you've met our resident evangelist! Repeat after me: ¤ ¤ "Bite me, Paul!" ¤ ¤ :-) Hey, someone's gotta save the folks from the resident anti-Microsoft boogeymen. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) On Tue, 27 Feb 2007 12:12:58 -0600, Paul Clement
<UseAdddressAtEndofMess***@swspectrum.com> wrote: in <lns8u2t72fsfu8m6d228k780em6qrf9***@4ax.com> Show quoteHide quote >On Fri, 23 Feb 2007 14:52:16 -0800, "Karl E. Peterson" <k***@mvps.org> wrote: Someone better save microsoft from their own anti-customer behavior.> >¤ > Well, I definitely don't need a shift operator that desperately :). >¤ >¤ Heh, so you've met our resident evangelist! Repeat after me: >¤ >¤ "Bite me, Paul!" >¤ >¤ :-) > >Hey, someone's gotta save the folks from the resident anti-Microsoft boogeymen. ;-) > > >Paul >~~~~ >Microsoft MVP (Visual Basic) Whoops! Looks like it might be too late. Aww shucks, it sucks to be microsoft. On Tue, 27 Feb 2007 11:05:42 -0800, Stefan Berglund <sorry.no.kool***@for.me> wrote:
¤ >¤ > Well, I definitely don't need a shift operator that desperately :). ¤ >¤ ¤ >¤ Heh, so you've met our resident evangelist! Repeat after me: ¤ >¤ ¤ >¤ "Bite me, Paul!" ¤ >¤ ¤ >¤ :-) ¤ > ¤ >Hey, someone's gotta save the folks from the resident anti-Microsoft boogeymen. ;-) ¤ > ¤ > ¤ >Paul ¤ >~~~~ ¤ >Microsoft MVP (Visual Basic) ¤ ¤ Someone better save microsoft from their own anti-customer behavior. ¤ Whoops! Looks like it might be too late. Aww shucks, it sucks to be ¤ microsoft. Having no experience in that area I'll have to defer to yours as an anti-customer. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) "AmiDaniel" <cannon.dani***@gmail.com> wrote in message Turn off integer overflow checks in the advanced compile options.news:1172181173.866088.142210@s48g2000cws.googlegroups.com... > So my question is this: How does one handle overflows > such that they do *not* generate errors, but instead return > the *actual* binary result? Mike "AmiDaniel" <cannon.dani***@gmail.com> wrote in message I agree that VB is extremely limited in that area, but you can perform some news:1172181173.866088.142210@s48g2000cws.googlegroups.com... > Is there any way in VB to actually physically shift > or manipulate a Double at the bit level? simple jobs fairly easily and quickly. Multiply by 2 will shift the bits left for you, and divide by 2 (using integer division \ rather than standard division / for speed) will shift them right. That, coupled with turning off integer overflow checks in the compile options, will allow to do some things, with certain limitations. VB does generally suck though when it comes to dealing with data at bit level. Mike > I've yet again found myself baffled by how complicated VB makes <snip>> relatively simple tasks, and I was hoping someone might be able to > shed some light on a solution to my problem. > > My problem can be simplified to the following: if I have a Long > integer that has reached its maximum capacity (2^31-1), and I add one > to this Long, VB throws an Overflow error. What I would like to happen > (in the context of my current appliation, which is uniquely hashing > Strings), however, is for the result of evaluating 2 ^ 31 and storing > it to a long to _rollover_, to become the actual result of the binary > arithmetic, namely -2 ^ 31. In most languages, this is done > automatically. Have a look at this old post for an example of how to work with QWords in VB: http://groups.google.co.uk/group/microsoft.public.vb.general.discussion/msg/647fea5d3bcb6ce0 It also deals with a low unsigned DWord in this code should you not want the full 64-bit range, in that case all you'd need is something like: '*** Private Function AddDWordsUnsigned(ByVal inA As Long, ByVal inB As Long) As Long AddDWordsUnsigned = UDWordToSDWord(SDWordToUDWord(inA) + inB) End Function '*** This version silently ignores overflow past the 32'nd bit should it occur. If you're doing lots of additions to this value, then I would suggest using a Currency type throughout and only converting back to an unsigned DWord at the end. Also, should you need it in the future, bit-shifting can be emulated in VB by multiplying or integer dividing by powers of 2 i.e. Multiply by 2 == <<1, divide by 4 == >>2 etc. Hope this helps, Mike - Microsoft Visual Basic MVP - E-Mail: ED***@mvps.org WWW: Http://EDais.mvps.org/ On Feb 23, 9:18 am, "Mike D Sutton" <E***@mvps.org> wrote: Hmm, looks interesting. Changing the compiler options seemed to solve> Have a look at this old post for an example of how to work with QWords in VB:http://groups.google.co.uk/group/microsoft.public.vb.general.discussi... > It also deals with a low unsigned DWord in this code should you not want the full 64-bit range, in that case all you'd > need is something like: my problem, so I'll likely won't need that for this app, but thanks anyway--it may well come in handy later. It takes an approach that I probably would have never thought of, and it's far more efficient (although requiring more space and type conversions) than my old recursive method to compress doubles. > Also, should you need it in the future, bit-shifting can be emulated in VB by multiplying or integer dividing by powers Again, I am slighltly concerned about the efficiency of this. Shift> of 2 i.e. Multiply by 2 == <<1, divide by 4 == >>2 etc. left by x bits requires calculating the exponent of 2^x (and exponent operations tend to be slow in all languages) and then performing the actual multiplication, which is quite a bit slower than the single operation of shifting bits. This may seem like nit-picking, but in my current app, I'd be performing this bit-shifting an average of about 10 times on a little more than 2 million items. It adds up. I'm also not entirely sure how VB handles floating point integers-- does multiplying, i.e., " 123.003582382101" actually shift the physical bits of the float? I don't believe so. Similarly, if you divide 3 by 2 and store it in a float, it won't be 1 (the actual shift right), but rather 1.5. I worry that if I use multiplication/division, even I think I'll never use any types that are floating point, I'll wind up digging myself a very deep grave that I wouldn't have to worry about if I had an actual shift operator. -- Daniel Cannon AmiDaniel <cannon.dani***@gmail.com> wrote:
>> Also, should you need it in the future, bit-shifting can be emulated in VB by In cases like that, it really pays off to precalculate a little lookup table for the >> multiplying or integer dividing by powers >> of 2 i.e. Multiply by 2 == <<1, divide by 4 == >>2 etc. > > Again, I am slighltly concerned about the efficiency of this. Shift > left by x bits requires calculating the exponent of 2^x (and exponent > operations tend to be slow in all languages) and then performing the > actual multiplication, which is quite a bit slower than the single > operation of shifting bits. This may seem like nit-picking, but in my > current app, I'd be performing this bit-shifting an average of about > 10 times on a little more than 2 million items. It adds up. powers: Private Function TwoToThe(ByVal Power As Long) As Long Static BeenHere As Boolean Static Results(0 To 31) As Long Dim i As Long ' Build lookup table, first time through. ' Results hold powers of two from 0-31. If Not BeenHere Then Results(0) = 1 For i = 1 To 30 Results(i) = Results(i - 1) * 2 Next i Results(31) = &H80000000 BeenHere = True End If ' Return requested result If Power >= 0 And Power <= 31 Then TwoToThe = Results(Power) End If End Function > I'm also not entirely sure how VB handles floating point integers-- That's an oxymoron, isn't it?Karl E. Peterson wrote:
> AmiDaniel <cannon.dani***@gmail.com> wrote: Public fpi as Oxymoron> >> I'm also not entirely sure how VB handles floating point integers-- > > That's an oxymoron, isn't it? Yep, sure enough! On Feb 23, 7:30 pm, Bob O`Bob <filter***@yahoogroups.com> wrote:
> Karl E. Peterson wrote: In VB-land, anything's possible :). I suppose I ought to have said> > AmiDaniel <cannon.dani***@gmail.com> wrote: > > >> I'm also not entirely sure how VB handles floating point integers-- > > > That's an oxymoron, isn't it? > > Public fpi as Oxymoron > > Yep, sure enough! "floating point variables", but I assume you know what I meant =P. -- Daniel Cannon AmiDaniel <cannon.dani***@gmail.com> wrote:
Show quoteHide quote > On Feb 23, 7:30 pm, Bob O`Bob <filter***@yahoogroups.com> wrote: I think one of the things that *most* confuses those new to VB is that the >> Karl E. Peterson wrote: >>> AmiDaniel <cannon.dani***@gmail.com> wrote: >> >>>> I'm also not entirely sure how VB handles floating point integers-- >> >>> That's an oxymoron, isn't it? >> >> Public fpi as Oxymoron >> >> Yep, sure enough! > > In VB-land, anything's possible :). I suppose I ought to have said > "floating point variables", but I assume you know what I meant =P. definition of "Integer" is extremely precise. So much so, in fact, it hasn't changed in over 30 years. So much so, it was invariate across 8-, 16-, and 32-bit processors. In fact, it was this very confusion that led to the ultimate death of VB, as we all knew and loved it. The newcomers couldn't be bothered to RTFM. MSBASIC, 1976-2001, RIP. > Hmm, looks interesting. Changing the compiler options seemed to solve From a performance point of view, this is a fastest way I've found in native VB of dealing with unsigned values.> my problem, so I'll likely won't need that for this app, but thanks > anyway--it may well come in handy later. It takes an approach that I > probably would have never thought of, and it's far more efficient > (although requiring more space and type conversions) than my old > recursive method to compress doubles. > Again, I am slighltly concerned about the efficiency of this. Shift In the majority of cases you already know how many bits you want to shift by and as such can simply put in the > left by x bits requires calculating the exponent of 2^x (and exponent > operations tend to be slow in all languages) and then performing the > actual multiplication, which is quite a bit slower than the single > operation of shifting bits. This may seem like nit-picking, but in my > current app, I'd be performing this bit-shifting an average of about > 10 times on a little more than 2 million items. It adds up. pre-calculated value rather than using the costly power operator. In these cases you get very fast code, it may even be optimised by the compiler into a SHL/SHR operation in the compiled .EXE. > I'm also not entirely sure how VB handles floating point integers-- Shift operations are bitwise and only ever operate on integer values though?.. Due to the way floating point values are > does multiplying, i.e., " 123.003582382101" actually shift the > physical bits of the float? I don't believe so. stored, a bitwise operation simply makes no sense there. The Currency data-type in VB is a _fixed_-point rather than floating point value, which means that it's really stored as an integer behind the scenes which makes it more accurate to do these kind of operations with than floating point types such as a Double or Decimal. > Similarly, if you divide 3 by 2 and store it in a float, it won't be 1 (the actual VB has two division methods; "/" performs floating point division, while "\" performs much faster integer division which > shift right), but rather 1.5. I worry that if I use multiplication/division, > even I think I'll never use any types that are floating point, I'll > wind up digging myself a very deep grave that I wouldn't have to worry > about if I had an actual shift operator. circumvents this problem. The overhead of calling out to a DLL every time a bit-shift needs to be performed is likely going to be higher than jumping through a few hoops in VB. If you're really worried about performance then personally I would move the entire hashing algorithm into a C++ DLL and just make one call in the VB app to that, but it does give you an extra dependency to cart around. Hope this helps, Mike - Microsoft Visual Basic MVP - E-Mail: ED***@mvps.org WWW: Http://EDais.mvps.org/ |
|||||||||||||||||||||||
Other interesting topics