|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Looking for a way to convert dec to binDear All,
I'm looking for a way to convert a byte into decimal, the ultimate goal is to read a byte from a file in binary, and convert it to a string of text, I've googled around, and a lot of the snippets I find don't seem to meet my needs. Can anybody help Regards Paul. Since posting, I went on the hunt again, and I found this which works....
Dim i As Integer NoOfBits = 8 'make sure there are enough bits to contain the number Do While mychar > (2 ^ NoOfBits) - 1 NoOfBits = NoOfBits + 8 Loop DecToBin = vbNullString 'build the string For i = 0 To (NoOfBits - 1) DecToBin = CStr((mychar And 2 ^ i) / 2 ^ i) & DecToBin Next i the mychar is the value I've read in from the file, and DecToBin is the final result, the NoOfBits is the amount of bits, i.e. 8 bit or 16 bit... hope this helps if someone needs a similar things... Regards Paul. Show quoteHide quote "Kardon Coupé" <prefer.to@readon.newsgroups> wrote in message news:epmIgz5XHHA.3824@TK2MSFTNGP02.phx.gbl... > Dear All, > > I'm looking for a way to convert a byte into decimal, the ultimate goal is > to read a byte from a file in binary, and convert it to a string of text, > I've googled around, and a lot of the snippets I find don't seem to meet > my needs. > > Can anybody help > > Regards > Paul. >
Show quote
Hide quote
"Kardon Coupé" <prefer.to@readon.newsgroups> wrote in message That code is massively inefficient. I wouldn't be suprised if this code ran news:uhJz065XHHA.208@TK2MSFTNGP05.phx.gbl... > Since posting, I went on the hunt again, and I found this which works.... > > Dim i As Integer > NoOfBits = 8 > 'make sure there are enough bits to contain the number > Do While mychar > (2 ^ NoOfBits) - 1 > NoOfBits = NoOfBits + 8 > Loop > DecToBin = vbNullString > 'build the string > For i = 0 To (NoOfBits - 1) > DecToBin = CStr((mychar And 2 ^ i) / 2 ^ i) & DecToBin > Next i > > the mychar is the value I've read in from the file, and DecToBin is the > final result, the NoOfBits is the amount of bits, i.e. 8 bit or 16 bit... > > hope this helps if someone needs a similar things... 100 times faster: Private Function DecToBin2(ByVal mychar As Byte) As String Dim res As String: res = "00000000" Dim i As Long: i = 8 While mychar > 0 Mid$(res, i, 1) = CStr(mychar And 1) mychar = mychar \ 2 i = i - 1 Wend DecToBin2 = res End Function Michael
Show quote
Hide quote
"Michael C" <nospam@nospam.com> wrote in message Ok Rick, we are waiting....news:%23Y4qma6XHHA.4220@TK2MSFTNGP03.phx.gbl... > "Kardon Coupé" <prefer.to@readon.newsgroups> wrote in message > news:uhJz065XHHA.208@TK2MSFTNGP05.phx.gbl... > > Since posting, I went on the hunt again, and I found this which works.... > > > > Dim i As Integer > > NoOfBits = 8 > > 'make sure there are enough bits to contain the number > > Do While mychar > (2 ^ NoOfBits) - 1 > > NoOfBits = NoOfBits + 8 > > Loop > > DecToBin = vbNullString > > 'build the string > > For i = 0 To (NoOfBits - 1) > > DecToBin = CStr((mychar And 2 ^ i) / 2 ^ i) & DecToBin > > Next i > > > > the mychar is the value I've read in from the file, and DecToBin is the > > final result, the NoOfBits is the amount of bits, i.e. 8 bit or 16 bit... > > > > hope this helps if someone needs a similar things... > > That code is massively inefficient. I wouldn't be suprised if this code ran > 100 times faster: > > Private Function DecToBin2(ByVal mychar As Byte) As String > Dim res As String: res = "00000000" > Dim i As Long: i = 8 > > While mychar > 0 > Mid$(res, i, 1) = CStr(mychar And 1) > mychar = mychar \ 2 > i = i - 1 > Wend > DecToBin2 = res > End Function > > Michael > <g>
Show quote
Hide quote
>> > Since posting, I went on the hunt again, and I found this which For those of you who are unsure of what Ralph is challenging me to, he wants > works.... >> > >> > Dim i As Integer >> > NoOfBits = 8 >> > 'make sure there are enough bits to contain the number >> > Do While mychar > (2 ^ NoOfBits) - 1 >> > NoOfBits = NoOfBits + 8 >> > Loop >> > DecToBin = vbNullString >> > 'build the string >> > For i = 0 To (NoOfBits - 1) >> > DecToBin = CStr((mychar And 2 ^ i) / 2 ^ i) & DecToBin >> > Next i >> > >> > the mychar is the value I've read in from the file, and DecToBin is the >> > final result, the NoOfBits is the amount of bits, i.e. 8 bit or 16 > bit... >> > >> > hope this helps if someone needs a similar things... >> >> That code is massively inefficient. I wouldn't be suprised if this code > ran >> 100 times faster: >> >> Private Function DecToBin2(ByVal mychar As Byte) As String >> Dim res As String: res = "00000000" >> Dim i As Long: i = 8 >> >> While mychar > 0 >> Mid$(res, i, 1) = CStr(mychar And 1) >> mychar = mychar \ 2 >> i = i - 1 >> Wend >> DecToBin2 = res >> End Function >> >> Michael >> > > Ok Rick, we are waiting.... > > <g> to see if I can post a one-liner function to convert a byte value into a binary value. I am pretty sure this function meets that challenge... Private Function Dec2Bin(ByVal mychar As Byte) As String Dec2Bin = Mid$("00000001001000110100010101100111" & _ "10001001101010111100110111101111", 4 * Val("&h" & _ Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ "10001001101010111100110111101111", 4 * Val("&h" & _ Right$(Format$(Hex$(mychar), "00"), 1)) + 1, 4) End Function <vbg> Rick
Show quote
Hide quote
"Rick Rothstein (MVP - VB)" <rickNOSPAMnews@NOSPAMcomcast.net> skrev i Dim i As Bytemeddelandet news:euuNsDAYHHA.992@TK2MSFTNGP04.phx.gbl... > >> > Since posting, I went on the hunt again, and I found this which > > works.... > >> > > >> > Dim i As Integer > >> > NoOfBits = 8 > >> > 'make sure there are enough bits to contain the number > >> > Do While mychar > (2 ^ NoOfBits) - 1 > >> > NoOfBits = NoOfBits + 8 > >> > Loop > >> > DecToBin = vbNullString > >> > 'build the string > >> > For i = 0 To (NoOfBits - 1) > >> > DecToBin = CStr((mychar And 2 ^ i) / 2 ^ i) & DecToBin > >> > Next i > >> > > >> > the mychar is the value I've read in from the file, and DecToBin is the > >> > final result, the NoOfBits is the amount of bits, i.e. 8 bit or 16 > > bit... > >> > > >> > hope this helps if someone needs a similar things... > >> > >> That code is massively inefficient. I wouldn't be suprised if this code > > ran > >> 100 times faster: > >> > >> Private Function DecToBin2(ByVal mychar As Byte) As String > >> Dim res As String: res = "00000000" > >> Dim i As Long: i = 8 > >> > >> While mychar > 0 > >> Mid$(res, i, 1) = CStr(mychar And 1) > >> mychar = mychar \ 2 > >> i = i - 1 > >> Wend > >> DecToBin2 = res > >> End Function > >> > >> Michael > >> > > > > Ok Rick, we are waiting.... > > > > <g> > > For those of you who are unsure of what Ralph is challenging me to, he wants > to see if I can post a one-liner function to convert a byte value into a > binary value. I am pretty sure this function meets that challenge... > > Private Function Dec2Bin(ByVal mychar As Byte) As String > Dec2Bin = Mid$("00000001001000110100010101100111" & _ > "10001001101010111100110111101111", 4 * Val("&h" & _ > Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ > 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ > "10001001101010111100110111101111", 4 * Val("&h" & _ > Right$(Format$(Hex$(mychar), "00"), 1)) + 1, 4) > End Function > > <vbg> > > Rick > >Sorry Rick, you just asked for it :) Dim s As String For i = 0 To 127 s = Dec2Bin(i) Debug.Print i, s Next this is the output from values of i: 26 = 00010000 42 = 00100000 58 = 00110000 Or did I as usual do something wrong? /Henning
Show quote
Hide quote
>> For those of you who are unsure of what Ralph is challenging me to, he Nope, you are correct, the function I posted is flawed, but that is because > wants >> to see if I can post a one-liner function to convert a byte value into a >> binary value. I am pretty sure this function meets that challenge... >> >> Private Function Dec2Bin(ByVal mychar As Byte) As String >> Dec2Bin = Mid$("00000001001000110100010101100111" & _ >> "10001001101010111100110111101111", 4 * Val("&h" & _ >> Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ >> 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ >> "10001001101010111100110111101111", 4 * Val("&h" & _ >> Right$(Format$(Hex$(mychar), "00"), 1)) + 1, 4) >> End Function >> >> <vbg> >> >> Rick >> >>Sorry Rick, you just asked for it :) > Dim i As Byte > Dim s As String > > For i = 0 To 127 > s = Dec2Bin(i) > Debug.Print i, s > Next > > > this is the output from values of i: > 26 = 00010000 > 42 = 00100000 > 58 = 00110000 > > Or did I as usual do something wrong? I grabbed the wrong one to post. My initial attempt was to try and control the hex-unit selection with the format function. Of course, in thinking about it, that was a foolish thing to do, but it was what I did initially. Then I changed the first part of the concatenation to handle the selection of the first hex-unit correctly and forgot to modify the selection of the second hex-unit. Here is the corrected one-liner function... Private Function Dec2Bin(ByVal mychar As Byte) As String Dec2Bin = Mid$("00000001001000110100010101100111" & _ "10001001101010111100110111101111", 4 * Val("&h" & _ Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ "10001001101010111100110111101111", 4 * Val("&h" & _ Right$(Hex$(mychar), 1)) + 1, 4) End Function Thanks for catching that... we wouldn't want anyone crazy enough to use this function to end up with incorrect results, now would we?<g> Rick
Show quote
Hide quote
"Rick Rothstein (MVP - VB)" <rickNOSPAMnews@NOSPAMcomcast.net> skrev i Well done, I just have to save this for my grandchildren ;)meddelandet news:%23D0VTWBYHHA.4440@TK2MSFTNGP03.phx.gbl... > >> For those of you who are unsure of what Ralph is challenging me to, he > > wants > >> to see if I can post a one-liner function to convert a byte value into a > >> binary value. I am pretty sure this function meets that challenge... > >> > >> Private Function Dec2Bin(ByVal mychar As Byte) As String > >> Dec2Bin = Mid$("00000001001000110100010101100111" & _ > >> "10001001101010111100110111101111", 4 * Val("&h" & _ > >> Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ > >> 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ > >> "10001001101010111100110111101111", 4 * Val("&h" & _ > >> Right$(Format$(Hex$(mychar), "00"), 1)) + 1, 4) > >> End Function > >> > >> <vbg> > >> > >> Rick > >> > >>Sorry Rick, you just asked for it :) > > Dim i As Byte > > Dim s As String > > > > For i = 0 To 127 > > s = Dec2Bin(i) > > Debug.Print i, s > > Next > > > > > > this is the output from values of i: > > 26 = 00010000 > > 42 = 00100000 > > 58 = 00110000 > > > > Or did I as usual do something wrong? > > Nope, you are correct, the function I posted is flawed, but that is because > I grabbed the wrong one to post. My initial attempt was to try and control > the hex-unit selection with the format function. Of course, in thinking > about it, that was a foolish thing to do, but it was what I did initially. > Then I changed the first part of the concatenation to handle the selection > of the first hex-unit correctly and forgot to modify the selection of the > second hex-unit. Here is the corrected one-liner function... > > Private Function Dec2Bin(ByVal mychar As Byte) As String > Dec2Bin = Mid$("00000001001000110100010101100111" & _ > "10001001101010111100110111101111", 4 * Val("&h" & _ > Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ > 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ > "10001001101010111100110111101111", 4 * Val("&h" & _ > Right$(Hex$(mychar), 1)) + 1, 4) > End Function > > Thanks for catching that... we wouldn't want anyone crazy enough to use this > function to end up with incorrect results, now would we?<g> > > Rick > /Henning
Show quote
Hide quote
>> Private Function Dec2Bin(ByVal mychar As Byte) As String Grandchildren now (or in the future)? Why, so you can tell them about the >> Dec2Bin = Mid$("00000001001000110100010101100111" & _ >> "10001001101010111100110111101111", 4 * Val("&h" & _ >> Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ >> 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ >> "10001001101010111100110111101111", 4 * Val("&h" & _ >> Right$(Hex$(mychar), 1)) + 1, 4) >> End Function >> >> Thanks for catching that... we wouldn't want anyone crazy enough to use > this >> function to end up with incorrect results, now would we?<g> >> > Well done, I just have to save this for my grandchildren ;) crazy person you (used to) hang out with online (when you were younger)?<g> Rick
Show quote
Hide quote
"Rick Rothstein (MVP - VB)" <rickNOSPAMnews@NOSPAMcomcast.net> skrev i younger)?<g>meddelandet news:O5no21BYHHA.2316@TK2MSFTNGP04.phx.gbl... > >> Private Function Dec2Bin(ByVal mychar As Byte) As String > >> Dec2Bin = Mid$("00000001001000110100010101100111" & _ > >> "10001001101010111100110111101111", 4 * Val("&h" & _ > >> Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ > >> 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ > >> "10001001101010111100110111101111", 4 * Val("&h" & _ > >> Right$(Hex$(mychar), 1)) + 1, 4) > >> End Function > >> > >> Thanks for catching that... we wouldn't want anyone crazy enough to use > > this > >> function to end up with incorrect results, now would we?<g> > >> > > Well done, I just have to save this for my grandchildren ;) > > Grandchildren now (or in the future)? Why, so you can tell them about the > crazy person you (used to) hang out with online (when you were > Yep, when I was as young as now (61)!! My oldest grandson is 5.> Rick > /Henning > Yep, when I was as young as now (61)!! My oldest grandson is 5. Hey, we are the same age! (No grandchildren though.)Rick In article <ecEt5HCYHHA.3***@TK2MSFTNGP02.phx.gbl>,
rickNOSPAMnews@NOSPAMcomcast.net (Rick Rothstein \(MVP - VB\)) wrote: > *From:* "Rick Rothstein \(MVP - VB\)" <rickNOSPAMnews@NOSPAMcomcast.net> So am I (61), but no grandchildren (or children or SO for that matter), > > > Yep, when I was as young as now (61)!! My oldest grandson is 5. > > Hey, we are the same age! (No grandchildren though.) > which is how I managed to retire 12 years ago! :^)) Regards John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply...
Show quote
Hide quote
"John K.Eason" <john@jeasonNoSpam.cix.co.uk> skrev i meddelandet Retire? For a while I was thinking of living forever, but with DotNot andnews:memo.20070306235939.3460A@jeason.compulink.co.uk... > In article <ecEt5HCYHHA.3***@TK2MSFTNGP02.phx.gbl>, > rickNOSPAMnews@NOSPAMcomcast.net (Rick Rothstein \(MVP - VB\)) wrote: > > > *From:* "Rick Rothstein \(MVP - VB\)" <rickNOSPAMnews@NOSPAMcomcast.net> > > > > > Yep, when I was as young as now (61)!! My oldest grandson is 5. > > > > Hey, we are the same age! (No grandchildren though.) > > > > So am I (61), but no grandchildren (or children or SO for that matter), > which is how I managed to retire 12 years ago! :^)) > > Regards > John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply... Vista, I'm not so sure anymore.... Well, at least we can virtually have a beer together! Cheers. /Henning In article <45ee0f72$0$17842$57c3e***@news3.bahnhof.se>,
computer_h***@coldmail.com (Henning) wrote: > Well, at least we can virtually have a beer together! Cheers. That's the other way to save money. - I don't drink either! :^)Regards John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply... "John K.Eason" <john@jeasonNoSpam.cix.co.uk> skrev i meddelandet Not even a virtual beer?news:memo.20070307114915.3896A@jeason.compulink.co.uk... > In article <45ee0f72$0$17842$57c3e***@news3.bahnhof.se>, > computer_h***@coldmail.com (Henning) wrote: > > > Well, at least we can virtually have a beer together! Cheers. > > That's the other way to save money. - I don't drink either! :^) > > Regards > John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply... /Henning In article <45eeadac$0$17842$57c3e***@news3.bahnhof.se>,
computer_h***@coldmail.com (Henning) wrote: > Not even a virtual beer? The real stuff tastes like soapy water to me, so I'll pass on the virtual version as well thanks. Appreciate the offer though! :^) Regards John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply... Funny, I always thought the same too. You're one of the few I know who
shares my sentiments about beer. Of course, now I know I have Celiac Disease, so beer (containing barley) is RIGHT off the menu...not that it was ever on it in the first place. (For those who're wondering, put simply, for those with Celiac, wheat, rye and barley are like a non-lethal poison...similar to lactose intolerance, but much MUCH more sensitive.) Rob Show quoteHide quote "John K.Eason" <john@jeasonNoSpam.cix.co.uk> wrote in message news:memo.20070307233252.3896C@jeason.compulink.co.uk... > In article <45eeadac$0$17842$57c3e***@news3.bahnhof.se>, > computer_h***@coldmail.com (Henning) wrote: > >> Not even a virtual beer? > > The real stuff tastes like soapy water to me, so I'll pass on the virtual > version as well thanks. > Appreciate the offer though! :^) > > Regards > John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply... On Wed, 7 Mar 2007 18:54:45 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >Funny, I always thought the same too. You're one of the few I know who Interesting, I think that might be the genetic intolerance that is>shares my sentiments about beer. Of course, now I know I have Celiac >Disease, so beer (containing barley) is RIGHT off the menu...not that it was >ever on it in the first place. >(For those who're wondering, put simply, for those with Celiac, wheat, rye >and barley are like a non-lethal poison...similar to lactose intolerance, >but much MUCH more sensitive.) common amongst the Japanese. It is more common amongst some groups than others, but not by all that much.
I think in North America, it's been estimated at 1 in 300 people (though most go undiagnosed for years, if ever), and in some populations it's as high as 1 in 100. Yes, that's a threefold increase, but it's still comparatively uncommon, especially when you factor in the underdiagnosis. As for genetic transmission, if you have it, there's roughly a 1 in 10 chance that an immediate family member will also have it, but after that first generation, it drops off to pretty much normal probabilities. Any more questions? I was only diagnosed 1.5 years ago, so I've done LOTS of reading on it, and am a wealth of (admittedly non-VB-related) information. :) Rob Show quoteHide quote "J French" <erew***@nowhere.uk> wrote in message news:45efcff8.3671362@news.btopenworld.com... > On Wed, 7 Mar 2007 18:54:45 -0500, "Robert Morley" > <rmor***@magma.ca.N0.Freak1n.sparn> wrote: > >>Funny, I always thought the same too. You're one of the few I know who >>shares my sentiments about beer. Of course, now I know I have Celiac >>Disease, so beer (containing barley) is RIGHT off the menu...not that it >>was >>ever on it in the first place. > >>(For those who're wondering, put simply, for those with Celiac, wheat, rye >>and barley are like a non-lethal poison...similar to lactose intolerance, >>but much MUCH more sensitive.) > > Interesting, I think that might be the genetic intolerance that is > common amongst the Japanese. > > On Thu, 8 Mar 2007 11:16:59 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >It is more common amongst some groups than others, but not by all that much. Interesting, I did not know that, I've only seen it in Japanese and>I think in North America, it's been estimated at 1 in 300 people (though >most go undiagnosed for years, if ever), and in some populations it's as >high as 1 in 100. Yes, that's a threefold increase, but it's still >comparatively uncommon, especially when you factor in the underdiagnosis. >As for genetic transmission, if you have it, there's roughly a 1 in 10 >chance that an immediate family member will also have it, but after that >first generation, it drops off to pretty much normal probabilities. > >Any more questions? I was only diagnosed 1.5 years ago, so I've done LOTS >of reading on it, and am a wealth of (admittedly non-VB-related) >information. :) Chinese - but I guess it can be undiagnosed.
Show quote
Hide quote
"Rick Rothstein (MVP - VB)" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in Ohhh, elegance & simplicity, I'll use this code where and when ever message > > For those of you who are unsure of what Ralph is challenging me to, he > wants to see if I can post a one-liner function to convert a byte value > into a binary value. I am pretty sure this function meets that > challenge... > > Private Function Dec2Bin(ByVal mychar As Byte) As String > Dec2Bin = Mid$("00000001001000110100010101100111" & _ > "10001001101010111100110111101111", 4 * Val("&h" & _ > Left$(String$(-(mychar < 16), "0") & Hex$(mychar), _ > 1)) + 1, 4) & Mid$("00000001001000110100010101100111" & _ > "10001001101010111100110111101111", 4 * Val("&h" & _ > Right$(Format$(Hex$(mychar), "00"), 1)) + 1, 4) > End Function > > <vbg> > > Rick possible, thanks Rick. Don't worry, I'll give you full credit. Dave O. Great,mygoalinlife.Everythingoneline.Etc.<g>
CanYouSayLISP? Dick -- Richard Grier, MVP Hard & Software Author of Visual Basic Programmer's Guide to Serial Communications, Fourth Edition, ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March 2006. See www.hardandsoftware.net for details and contact information. > Great,mygoalinlife.Everythingoneline.Etc.<g> Actually, it wouldn't have occurred to me to attempt to make this kind of function into a one-liner on my own, but Ralph challenged me...<g> Rick > Dim res As String: res = "00000000" Interesting way of declaring starting values for your variables...never seen > Dim i As Long: i = 8 that style before. Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message Colons as statement separators = 20th-century BASIC in my opinion. I only news:uITfVFBYHHA.992@TK2MSFTNGP02.phx.gbl... >> Dim res As String: res = "00000000" >> Dim i As Long: i = 8 > > Interesting way of declaring starting values for your variables...never > seen that style before. use them that way in the immediate window. Hehehe...yes, I started programming in basic on a TSR-80, so I'm QUITE
familiar with colons as statement separators. I'd just never considered using them as part of the Dim statements. What can I say...the next language I learned after BASIC was Pascal, which had some very strict ideas about things like variable declarations vs. code. It influenced my programming style fairly heavily. Rob Show quoteHide quote "Jeff Johnson" <i.get@enough.spam> wrote in message news:OomHpJBYHHA.4308@TK2MSFTNGP05.phx.gbl... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message > news:uITfVFBYHHA.992@TK2MSFTNGP02.phx.gbl... > >>> Dim res As String: res = "00000000" >>> Dim i As Long: i = 8 >> >> Interesting way of declaring starting values for your variables...never >> seen that style before. > > Colons as statement separators = 20th-century BASIC in my opinion. I only > use them that way in the immediate window. > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I don't mind the C[++/#]-style method of declaring and initializing on one news:eC9lXhBYHHA.4560@TK2MSFTNGP03.phx.gbl... > Hehehe...yes, I started programming in basic on a TSR-80, so I'm QUITE > familiar with colons as statement separators. I'd just never considered > using them as part of the Dim statements. What can I say...the next > language I learned after BASIC was Pascal, which had some very strict > ideas about things like variable declarations vs. code. It influenced my > programming style fairly heavily. line. But until VB.NOT, BASIC and its derivatives did not do it and I don't like to see it together. When you're writing BASIC, don't try to make it look like C.... On Tue, 6 Mar 2007 12:51:46 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >Hehehe...yes, I started programming in basic on a TSR-80, so I'm QUITE That is interesting, my other language is Delphi, which is OO Pascal>familiar with colons as statement separators. I'd just never considered >using them as part of the Dim statements. What can I say...the next >language I learned after BASIC was Pascal, which had some very strict ideas >about things like variable declarations vs. code. It influenced my >programming style fairly heavily. One of our continual beefs is the inability to initialize a Stack variable when declaring it. Hehehe. I have no objection to the idea at all; I just learned a certain
rigidity, and despite bitching about it at the time, have found that it works for me in general. I also don't randomly jump out of loops with things like Exit Do or Exit For. They're effectively a form of GoTo, and like Pascal taught, I find they're absolutely never necessary (and only very rarely even useful) once you wrap your mind around doing without them. Like I said, Pascal influenced my programming style significantly. :) That said, I also follow popular conventions of the language to some degree. So, if I WERE working in VB.NET, or I think C++ supports it as well, I might well initialize variables at declaration time. I've also seen such strangeness in VB.NET as only dimensioning variables inside an If...Then structure. Not sure I'll ever wrap my mind around that, but if it's popular in the language, I might get used to it. (PS, I know you can do exactly the same thing in VB6, but I've seen it a lot more in the VB.NET examples I've seen than I ever have in VB6/VBA.) Rob Show quoteHide quote "J French" <erew***@nowhere.uk> wrote in message news:45ee71e4.4066669@news.btopenworld.com... > On Tue, 6 Mar 2007 12:51:46 -0500, "Robert Morley" > <rmor***@magma.ca.N0.Freak1n.sparn> wrote: > >>Hehehe...yes, I started programming in basic on a TSR-80, so I'm QUITE >>familiar with colons as statement separators. I'd just never considered >>using them as part of the Dim statements. What can I say...the next >>language I learned after BASIC was Pascal, which had some very strict >>ideas >>about things like variable declarations vs. code. It influenced my >>programming style fairly heavily. > > That is interesting, my other language is Delphi, which is OO Pascal > > One of our continual beefs is the inability to initialize a Stack > variable when declaring it. Robert Morley wrote:
> That said, I also follow popular conventions of the language to some degree. One detail which keeps getting overlooked is that> So, if I WERE working in VB.NET, or I think C++ supports it as well, I might > well initialize variables at declaration time. in VB, unlike most other languages, declaring a variable DOES initialize it. Bob -- Bob O`Bob <filter***@yahoogroups.com> wrote:
> Robert Morley wrote: ^numeric> >> That said, I also follow popular conventions of the language to some degree. >> So, if I WERE working in VB.NET, or I think C++ supports it as well, I might >> well initialize variables at declaration time. > > > One detail which keeps getting overlooked is that > in VB, unlike most other languages, declaring a variable DOES initialize it. HTH! Although strings are "sort of" initialized. They're at least functional, in
that they evaluate to an empty string (though I think they're actually initialized to vbNullString...as oxymoronic as that may be). It's not like they evaluate as Null, which to me would be a better representation of something that's completely uninitialized (okay, so yeah, like I've said before, I come from an Access background). Rob Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:%23RbrZWQYHHA.5044@TK2MSFTNGP05.phx.gbl... > Bob O`Bob <filter***@yahoogroups.com> wrote: >> Robert Morley wrote: >> >>> That said, I also follow popular conventions of the language to some >>> degree. >>> So, if I WERE working in VB.NET, or I think C++ supports it as well, I >>> might >>> well initialize variables at declaration time. >> >> >> One detail which keeps getting overlooked is that >> in VB, unlike most other languages, declaring a variable DOES initialize >> it. > ^numeric > HTH! > -- > .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 Right. They evaluate the same whether empty or NULL. But they're *initialized* (as > news:%23RbrZWQYHHA.5044@TK2MSFTNGP05.phx.gbl... >> Bob O`Bob <filter***@yahoogroups.com> wrote: >>> Robert Morley wrote: >>> >>>> That said, I also follow popular conventions of the language to some >>>> degree. >>>> So, if I WERE working in VB.NET, or I think C++ supports it as well, I >>>> might >>>> well initialize variables at declaration time. >>> >>> >>> One detail which keeps getting overlooked is that >>> in VB, unlike most other languages, declaring a variable DOES initialize >>> it. >> ^numeric >> HTH! > > Although strings are "sort of" initialized. They're at least functional, in > that they evaluate to an empty string (though I think they're actually > initialized to vbNullString...as oxymoronic as that may be). I understand the word) upon first assignment. Up to that point, they're just BSTR structures containing null pointers. > It's not like Dim s As String> they evaluate as Null, which to me would be a better representation of > something that's completely uninitialized Debug.Print s = "" Debug.Print StrPtr(s) Debug.Print s = vbNullString > (okay, so yeah, like I've said That explains a lot... <gd&r>> before, I come from an Access background). <gd&r>?
Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:%23ePnIoRYHHA.1244@TK2MSFTNGP04.phx.gbl... > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> "Karl E. Peterson" <k***@mvps.org> wrote in message >> news:%23RbrZWQYHHA.5044@TK2MSFTNGP05.phx.gbl... >>> Bob O`Bob <filter***@yahoogroups.com> wrote: >>>> Robert Morley wrote: >>>> >>>>> That said, I also follow popular conventions of the language to some >>>>> degree. >>>>> So, if I WERE working in VB.NET, or I think C++ supports it as well, I >>>>> might >>>>> well initialize variables at declaration time. >>>> >>>> >>>> One detail which keeps getting overlooked is that >>>> in VB, unlike most other languages, declaring a variable DOES >>>> initialize >>>> it. >>> ^numeric >>> HTH! >> >> Although strings are "sort of" initialized. They're at least functional, >> in >> that they evaluate to an empty string (though I think they're actually >> initialized to vbNullString...as oxymoronic as that may be). > > Right. They evaluate the same whether empty or NULL. But they're > *initialized* (as I understand the word) upon first assignment. Up to > that point, they're just BSTR structures containing null pointers. > >> It's not like >> they evaluate as Null, which to me would be a better representation of >> something that's completely uninitialized > > Dim s As String > Debug.Print s = "" > Debug.Print StrPtr(s) > Debug.Print s = vbNullString > >> (okay, so yeah, like I've said >> before, I come from an Access background). > > That explains a lot... <gd&r> > -- > .NET: It's About Trust! > http://vfred.mvps.org > Hahaha...now that's TOO much of a coincidence. Just yesterday, I asked my
Mom and my partner if either of them had the address of the wonderful site with the acronym dictionary, cuz I'd lost it...and lo and behold, YOU provide it! Thanks, Rob Show quoteHide quote "Karl E. Peterson" <k***@mvps.org> wrote in message news:es2HPNSYHHA.2436@TK2MSFTNGP06.phx.gbl... > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote: >> <gd&r>? > > http://www.acronymfinder.com/ > > <eg> > -- > .NET: It's About Trust! > http://vfred.mvps.org > Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
> Hahaha...now that's TOO much of a coincidence. Just yesterday, I asked my Hey, this is a *full-service* forum, I tell ya! ;-)> Mom and my partner if either of them had the address of the wonderful site > with the acronym dictionary, cuz I'd lost it...and lo and behold, YOU > provide it! > Hey, this is a *full-service* forum, I tell ya! ;-) Except for .NYET QuestionsDave O. <nob***@nowhere.com> wrote:
>> Hey, this is a *full-service* forum, I tell ya! ;-) Goes without saying, yeah.> > Except for .NYET Questions > Right. They evaluate the same whether empty or NULL. But they're Just to be anal-retentive:> *initialized* (as I understand the word) upon first assignment. Up to > that point, they're just BSTR structures containing null pointers. Dim s As String s = vbNullString So...this is initialized? <eg> Rob Robert Morley <rmor***@magma.ca.N0.Freak1n.sparn> wrote:
>> Right. They evaluate the same whether empty or NULL. But they're I'd have to say you've just de-initialized an uninitialized variable, there.>> *initialized* (as I understand the word) upon first assignment. Up to >> that point, they're just BSTR structures containing null pointers. > > Just to be anal-retentive: > > Dim s As String > s = vbNullString > > So...this is initialized? <eg> >>> Right. They evaluate the same whether empty or NULL. But they're Or will VB's evil type coercion coerce the vbNullString to the empty string >>> *initialized* (as I understand the word) upon first assignment. Up to >>> that point, they're just BSTR structures containing null pointers. >> >> Just to be anal-retentive: >> >> Dim s As String >> s = vbNullString >> >> So...this is initialized? <eg> > > I'd have to say you've just de-initialized an uninitialized variable, > there. before making the assignment to the String variable? Rick No, that much we know it won't do. If you look at StrPtr(s), it will return
0 if s is assigned vbNullString. Rob Show quoteHide quote "Rick Rothstein (MVP - VB)" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message news:%23763saTYHHA.688@TK2MSFTNGP03.phx.gbl... >>>> Right. They evaluate the same whether empty or NULL. But they're >>>> *initialized* (as I understand the word) upon first assignment. Up to >>>> that point, they're just BSTR structures containing null pointers. >>> >>> Just to be anal-retentive: >>> >>> Dim s As String >>> s = vbNullString >>> >>> So...this is initialized? <eg> >> >> I'd have to say you've just de-initialized an uninitialized variable, >> there. > > Or will VB's evil type coercion coerce the vbNullString to the empty > string before making the assignment to the String variable? > > Rick > > One detail which keeps getting overlooked is that True, but not always to what you'd WANT it to be initialized to. :)> in VB, unlike most other languages, declaring a variable DOES initialize > it. Rob Robert Morley wrote:
>> One detail which keeps getting overlooked is that At the same time A FAR CRY from just random bits.>> in VB, unlike most other languages, declaring a variable DOES initialize >> it. > > True, but not always to what you'd WANT it to be initialized to. :) > Bob -- What, you don't like random bits? You obviously haven't watched "I Robot"
enough! :P Rob Show quoteHide quote "Bob O`Bob" <filter***@yahoogroups.com> wrote in message news:Osnv%23sSYHHA.2556@TK2MSFTNGP02.phx.gbl... > Robert Morley wrote: >>> One detail which keeps getting overlooked is that >>> in VB, unlike most other languages, declaring a variable DOES initialize >>> it. >> >> True, but not always to what you'd WANT it to be initialized to. :) >> > > > At the same time A FAR CRY from just random bits. > > > > Bob > -- "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I watched it once, that was too much.news:OairM9SYHHA.1296@TK2MSFTNGP02.phx.gbl... > What, you don't like random bits? You obviously haven't watched "I Robot" > enough! :P Michael In article <O9hPQwTYHHA.***@TK2MSFTNGP04.phx.gbl>, nospam@nospam.com
says... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message Me, too. You should read the book instead.> news:OairM9SYHHA.1296@TK2MSFTNGP02.phx.gbl... > > What, you don't like random bits? You obviously haven't watched "I Robot" > > enough! :P > > I watched it once, that was too much. -- Remove the ns_ from if replying by e-mail (but keep posts in the newsgroups if possible). While I've yet to read it, it's certainly in my genre, so it'll get read at
some point. Having not read it, I wasn't looking for the movie to reflect the book, or even necessarily the same concepts, so I enjoyed the movie well enough (though nobody's going to put it on a level with LotR, to be sure). I liked it well enough to buy the DVD, much to my partner's dismay. Like many others, he hated it...mostly because it didn't reflect the books, and partly because Will Smith was in it, who's one of his "he makes a movie awful" actors. Rob Show quoteHide quote "David Kerber" <ns_dkerber@ns_WarrenRogersAssociates.com> wrote in message news:MPG.205b265850dc6300989ad6@news.conversent.net... > In article <O9hPQwTYHHA.***@TK2MSFTNGP04.phx.gbl>, nospam@nospam.com > says... >> "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message >> news:OairM9SYHHA.1296@TK2MSFTNGP02.phx.gbl... >> > What, you don't like random bits? You obviously haven't watched "I >> > Robot" >> > enough! :P >> >> I watched it once, that was too much. > > Me, too. You should read the book instead. > > > -- > Remove the ns_ from if replying by e-mail (but keep posts in the > newsgroups if possible). "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I'm sure the book was very interesting and I will read it some time. The news:%23UBGFMmYHHA.4000@TK2MSFTNGP02.phx.gbl... > While I've yet to read it, it's certainly in my genre, so it'll get read > at some point. Having not read it, I wasn't looking for the movie to > reflect the book, or even necessarily the same concepts, so I enjoyed the > movie well enough (though nobody's going to put it on a level with LotR, > to be sure). I liked it well enough to buy the DVD, much to my partner's > dismay. Like many others, he hated it...mostly because it didn't reflect > the books, and partly because Will Smith was in it, who's one of his "he > makes a movie awful" actors. movie was just a big punch up between robots and will smith. Michael On Wed, 7 Mar 2007 13:17:07 -0500, "Robert Morley"
<rmor***@magma.ca.N0.Freak1n.sparn> wrote: >Hehehe. I have no objection to the idea at all; I just learned a certain Interesting - Pascal does contain GoTo>rigidity, and despite bitching about it at the time, have found that it >works for me in general. I also don't randomly jump out of loops with >things like Exit Do or Exit For. They're effectively a form of GoTo, and >like Pascal taught, I find they're absolutely never necessary (and only very >rarely even useful) once you wrap your mind around doing without them. Like >I said, Pascal influenced my programming style significantly. :) - I don't object to it, but /only/ if it simplifies the code, otherwise I loathe it Pascal also has Break and Exit >That said, I also follow popular conventions of the language to some degree. Ghastly !>So, if I WERE working in VB.NET, or I think C++ supports it as well, I might >well initialize variables at declaration time. I've also seen such >strangeness in VB.NET as only dimensioning variables inside an If...Then >structure. Not sure I'll ever wrap my mind around that, but if it's popular >in the language, > I might get used to it. (PS, I know you can do exactly the I'm very much against declaring variables anywhere other than at the>same thing in VB6, but I've seen it a lot more in the VB.NET examples I've >seen than I ever have in VB6/VBA.) top of a block, I prefer to see at a glance what is going to be used.
Show quote
Hide quote
"J French" <erew***@nowhere.uk> wrote in message Where you declare variables is more than a style issue for those languagesnews:45efd143.4001610@news.btopenworld.com... > On Wed, 7 Mar 2007 13:17:07 -0500, "Robert Morley" > <rmor***@magma.ca.N0.Freak1n.sparn> wrote: > > >Hehehe. I have no objection to the idea at all; I just learned a certain > >rigidity, and despite bitching about it at the time, have found that it > >works for me in general. I also don't randomly jump out of loops with > >things like Exit Do or Exit For. They're effectively a form of GoTo, and > >like Pascal taught, I find they're absolutely never necessary (and only very > >rarely even useful) once you wrap your mind around doing without them. Like > >I said, Pascal influenced my programming style significantly. :) > > Interesting - Pascal does contain GoTo > - I don't object to it, but /only/ if it simplifies the code, > otherwise I loathe it > > Pascal also has Break and Exit > > >That said, I also follow popular conventions of the language to some degree. > >So, if I WERE working in VB.NET, or I think C++ supports it as well, I might > >well initialize variables at declaration time. I've also seen such > >strangeness in VB.NET as only dimensioning variables inside an If...Then > >structure. Not sure I'll ever wrap my mind around that, but if it's popular > >in the language, > > Ghastly ! > > > I might get used to it. (PS, I know you can do exactly the > >same thing in VB6, but I've seen it a lot more in the VB.NET examples I've > >seen than I ever have in VB6/VBA.) > > I'm very much against declaring variables anywhere other than at the > top of a block, I prefer to see at a glance what is going to be used. > that support compiler and runtime (GC) optimizers. In VB where it is just a style issue. But, IMHO, both declaring and defining variables on a single line and at the point of use makes sense during development, and for clarity and ease of maintenance in a released version. In another vein. Pascal was designed to be a teaching tool for top-down programming. Years ago when I was a self-proclaimed OO expert and I first heard about 'OO Pascal', aka Delphi. I thought it was a joke and knew it would never really amount to anything. (An amazing demonstration of my psychic abilities <g>). But they have pulled it off. FoxPro is another language/tool that has fascinating OOPL capabilities. It makes me sad as it illustrates very well what VB could have become. -ralph "J French" <erew***@nowhere.uk> wrote in message I've done this for years simply because it has been the common convention news:45efd143.4001610@news.btopenworld.com... > I'm very much against declaring variables anywhere other than at the > top of a block, I prefer to see at a glance what is going to be used. but I cannot see any benefit in it at all. I've completely gone away from this in dot net and declare all variables with the minimum possible scope. I'm not sure about vb.net but in C# you can delare a variable that has the scope of just a for loop, or just the scope of an if statement or just the scope of an else statement. eg: i is declared 4 times in this code and all are seperate variables. for(int i = 1; i < 10; i++) { Console.WriteLine(i.ToString()); } for(int i = 1; i < 10; i++) { Console.WriteLine(i.ToString()); } if(Environment.TickCount == 1) { int i = 5; Console.WriteLine(i.ToString()); } else { int i = 2; Console.WriteLine(i.ToString()); } Show quoteHide quote > >
Show quote
Hide quote
On Fri, 9 Mar 2007 09:30:37 +1100, "Michael C" <nospam@nospam.com> I see what you mean, if the scope is rigid then I've no objectionwrote: >"J French" <erew***@nowhere.uk> wrote in message >news:45efd143.4001610@news.btopenworld.com... >> I'm very much against declaring variables anywhere other than at the >> top of a block, I prefer to see at a glance what is going to be used. >I've done this for years simply because it has been the common convention >but I cannot see any benefit in it at all. I've completely gone away from >this in dot net and declare all variables with the minimum possible scope. >I'm not sure about vb.net but in C# you can delare a variable that has the >scope of just a for loop, or just the scope of an if statement or just the >scope of an else statement. eg: i is declared 4 times in this code and all >are seperate variables. It's really doing that in VB Classic, where it has no advantages that makes me queasy. "J French" <erew***@nowhere.uk> wrote in message But why does it make you queasy? Just because it's common convention? I've news:45f12144.4714279@news.btopenworld.com... > I see what you mean, if the scope is rigid then I've no objection > > It's really doing that in VB Classic, where it has no advantages that > makes me queasy. been declaring at the top for years just because it was the done thing. I'll still do it in vb just because it's done everywhere else in my projects and I'm not starting any new vb projects. However, I think in code like this below it's better not to: dim DoDad as DoDad foreach DoDad in DoDads Debug.Print DoDod.Name next dim Thingy as Thingy Foreach Thingy in Thingys Debug.Print Thingy.Name next In this case the dim is with the block of code that it applies to. It doesn't make sense to have all the Thingy code together except for 1 line. Michael On Fri, 9 Mar 2007 22:48:31 +1100, "Michael C" <nospam@nospam.com> Well I come from well before the 'Option Explicit' dayswrote: >"J French" <erew***@nowhere.uk> wrote in message >news:45f12144.4714279@news.btopenworld.com... >> I see what you mean, if the scope is rigid then I've no objection >> >> It's really doing that in VB Classic, where it has no advantages that >> makes me queasy. > >But why does it make you queasy? Even ignoring the helpfulness of Option Explicit, there's still the
possibility of using variables of different names unnecessarily. I would assume (big assumption here, especially since I know *nothing* of VB.NET's variable management) that the compiler would still reserve space for each distinct variable. I'm about 99% sure it would in classic VB. Thus, there would be the potential for wasted memory. Of course, it's probably going to be an exceptionally small waste of space compared to the overall size of the program, but there's always the possibility that it'll be some 20-dimension array or something, that's occupying vast amounts of memory unnecessarily. Rob Show quoteHide quote "J French" <erew***@nowhere.uk> wrote in message news:45f17665.26510414@news.btopenworld.com... > On Fri, 9 Mar 2007 22:48:31 +1100, "Michael C" <nospam@nospam.com> > wrote: > >>"J French" <erew***@nowhere.uk> wrote in message >>news:45f12144.4714279@news.btopenworld.com... >>> I see what you mean, if the scope is rigid then I've no objection >>> >>> It's really doing that in VB Classic, where it has no advantages that >>> makes me queasy. >> >>But why does it make you queasy? > > Well I come from well before the 'Option Explicit' days > >
Show quote
Hide quote
"Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message Perhaps you meant something else, but just in case ...news:erjPFMmYHHA.4000@TK2MSFTNGP02.phx.gbl... > Even ignoring the helpfulness of Option Explicit, there's still the > possibility of using variables of different names unnecessarily. I would > assume (big assumption here, especially since I know *nothing* of VB.NET's > variable management) that the compiler would still reserve space for each > distinct variable. I'm about 99% sure it would in classic VB. Thus, there > would be the potential for wasted memory. Of course, it's probably going to > be an exceptionally small waste of space compared to the overall size of the > program, but there's always the possibility that it'll be some 20-dimension > array or something, that's occupying vast amounts of memory unnecessarily. > > > Rob The "compiler" doesn't reserve space for variables. Variable 'names' are only symbols for addresses that make it easier for humans to code. Once an application is 'compiled' they are gone forever. However, it is possible to provide a symbol table, outside the actual compiled code (Note: Compiler Options in Project Properties), which can be used at runtime to associate variable names with their addresses in code. But in doing so you must turn off optimizations, thus creating a debug version. -ralph > The "compiler" doesn't reserve space for variables. Variable 'names' are Poor explanation on my part. What I meant was if you're using "local" > only symbols for addresses that make it easier for humans to code. Once an > application is 'compiled' they are gone forever. dimensioning, and doing something like dimensioning "intMyCounter" in one If...Then clause, but then dimensioning "intCounter" in another clause. In that case, assuming that the compiler uses traditional methods and allocates the stack space for the entire scope of the procedure and not just the scope of the If...Then, then you're using the space for two integers, where if you were declaring all your variables at the outset, you would probably have used the variable with the same name (assuming there's no overlap in usage, of course) instead of accidentally using a different one. Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I wouldn't assume any compiler uses seperate registers or memory for each news:O8LykCnYHHA.4440@TK2MSFTNGP03.phx.gbl... > Poor explanation on my part. What I meant was if you're using "local" > dimensioning, and doing something like dimensioning "intMyCounter" in one > If...Then clause, but then dimensioning "intCounter" in another clause. > In that case, assuming that the compiler uses traditional methods and > allocates the stack space for the entire scope of the procedure and not > just the scope of the If...Then, then you're using the space for two > integers, where if you were declaring all your variables at the outset, > you would probably have used the variable with the same name (assuming > there's no overlap in usage, of course) instead of accidentally using a > different one. variable. Most compilers, including VB, have a lot of optimisations. In your example with intMyCounter and intCounter, if the first was finished in use before the second was started to be used it would be likely they'd use the same register. In any case this should not dictate your coding style. Michael "Michael C" <nospam@nospam.com> wrote in message And here's the proof. Create a new project and add a module and paste the news:eJkM1%23qYHHA.4520@TK2MSFTNGP06.phx.gbl... > I wouldn't assume any compiler uses seperate registers or memory for each > variable. Most compilers, including VB, have a lot of optimisations. In > your example with intMyCounter and intCounter, if the first was finished > in use before the second was started to be used it would be likely they'd > use the same register. In any case this should not dictate your coding > style. code below in. Run it in the IDE and note that it gives the address of each of the functions. Now compile it and run the exe. Notice anything odd? :-) '-----------Form1 Private Function AddOf(ByVal Address As Long) As Long AddOf = Address End Function Private Sub Form_Load() Me.Caption = Hex$(AddOf(AddressOf One)) & " " & Hex$(AddOf(AddressOf Two)) End Sub '-------------- Module1 Option Explicit Public Function One() As Long Dim i As Long For i = 1 To 100 One = One + i Next Dim j As Long For j = 1 To 50 One = One + j Next End Function Public Function Two() As Long Dim i As Long For i = 1 To 100 Two = Two + i Next For i = 1 To 50 Two = Two + i Next End Function Show quoteHide quote > > Michael > First, I have a question, slightly on a tangent: What's the purpose of
AddOf()? It just returns what was passed to it, and testing the code without it, it works precisely the same. Now back on topic: I'm not sure what your code is doing to prove the point. While it's kind of strange that both procedures appear at the same address in the compiled code (why dynamically swap them?), that doesn't address the variable declaration example. What I'm talking about is: Private Sub Form_Load() If True Then Dim i As Long MsgBox Hex$(VarPtr(i)) For i = 1 To 100 Next MsgBox Hex$(VarPtr(i)) End If If True Then Dim j As Long MsgBox Hex$(VarPtr(j)) For j = 1 To 100 Next MsgBox Hex$(VarPtr(j)) End If MsgBox Hex$(VarPtr(i)) & " " & Hex$(VarPtr(j)) End Sub Not surprisingly, the addresses of i and j are different, and remain constant throughout (and if you change the True's to False's, also not surprisingly, they'll still be dimensioned and have different addresses). YOU knew you were done with the counter i after the first loop, and could've re-used it for the second loop, but the compiler knows nothing of the sort, so when you declare j in the second If block, it allocates more space for it. So by declaring counters locally to the block, you're more likely to mistakenly declare more variables than you need to, and thus waste more space. Rob Show quoteHide quote "Michael C" <nospam@nospam.com> wrote in message news:uDzckCrYHHA.1216@TK2MSFTNGP03.phx.gbl... > "Michael C" <nospam@nospam.com> wrote in message > news:eJkM1%23qYHHA.4520@TK2MSFTNGP06.phx.gbl... >> I wouldn't assume any compiler uses seperate registers or memory for each >> variable. Most compilers, including VB, have a lot of optimisations. In >> your example with intMyCounter and intCounter, if the first was finished >> in use before the second was started to be used it would be likely they'd >> use the same register. In any case this should not dictate your coding >> style. > > And here's the proof. Create a new project and add a module and paste the > code below in. Run it in the IDE and note that it gives the address of > each of the functions. Now compile it and run the exe. Notice anything > odd? :-) > > > '-----------Form1 > Private Function AddOf(ByVal Address As Long) As Long > AddOf = Address > End Function > > Private Sub Form_Load() > Me.Caption = Hex$(AddOf(AddressOf One)) & " " & Hex$(AddOf(AddressOf > Two)) > End Sub > > > '-------------- Module1 > Option Explicit > > Public Function One() As Long > Dim i As Long > For i = 1 To 100 > One = One + i > Next > > Dim j As Long > For j = 1 To 50 > One = One + j > Next > End Function > > Public Function Two() As Long > Dim i As Long > For i = 1 To 100 > Two = Two + i > Next > > For i = 1 To 50 > Two = Two + i > Next > End Function > > > >> >> Michael >> > > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message hmmm good point. It is required because you have to pass AddressOf into a news:O7dyBZrYHHA.3928@TK2MSFTNGP03.phx.gbl... > First, I have a question, slightly on a tangent: What's the purpose of > AddOf()? It just returns what was passed to it, and testing the code > without it, it works precisely the same. function but the hex$ is a function. I added the Hex later. > back on topic: I'm not sure what your code is doing to prove the point. VB6 is doing 2 optimisations. First it is saying that in the One function i > While it's kind of strange that both procedures appear at the same address > in the compiled code (why dynamically swap them?), that doesn't address > the variable declaration example. can be reused as j. It's then doing a second optimisation to say that the 2 functions are identical and therefore we don't need 2 functions. It's a simple test to see if 2 methods are 100% equivelant. So in this case we can see that i is reused as j. > Not surprisingly, the addresses of i and j are different, and remain You use them on the same line at the end so of course they *have* to be > constant throughout (and if you change the True's to False's, also not > surprisingly, they'll still be dimensioned and have different addresses). different. :-) I believe that varptr is also effectively changing the result you'd otherwise see. If you compiled this code without the varptr and had a look at it disassembled it would most definately optimise it down to 1 variable (or most likely register). > YOU knew you were done with the counter i after the first loop, and I guess this is true though, in some case it won't optimise and use extra > could've re-used it for the second loop, but the compiler knows nothing of > the sort, so when you declare j in the second If block, it allocates more > space for it. So by declaring counters locally to the block, you're more > likely to mistakenly declare more variables than you need to, and thus > waste more space. variables. Your program would have to be *extremely* optimised for this to be an issue though. Michael Interesting. I wasn't aware that VB6 did a duplicate function scan. I can
see how a simple loop like that would reduce easily, and that VB6 would then pick it up as a duplicate after the optimization, but I rather suspect that in a more complex loop, it would probably fail and allocate two memory spaces for the two variables. > You use them on the same line at the end so of course they *have* to be Actually, I hadn't at first, I added that later.> different. :-) > I believe that varptr is also effectively changing the result you'd At this simple level, yes, I suspect it would be using register > otherwise see. If you compiled this code without the varptr and had a look > at it disassembled it would most definately optimise it down to 1 variable > (or most likely register). optimization. Assuming it went beyond register optimization (i.e., if you had a whole lot more declarations), though, I'd be very surprised if it optimized memory usage...it's entirely possible that it would, though, you might be right. Even the little you proved that it could optimize took me by surprise. Admittedly, my knowledge of compiler technology is woefully out of date...primarily because I haven't had either the need or desire to make one in ages, and the little reverse-engineering I've done has all been on programs from the 80's and early 90's. I know .NET does a LOT of work in terms of figuring out what you were attempting to do and optimizing it (it has to, it's so slow in some ways), but I suspect that VB6's capabilities are more than a bit more limited in that regard, so probably more complex stuff would be more likely to not be well-optimized. > Your program would have to be *extremely* optimised for this to be an Which is what I said somewhere in the thread...something to the effect that > issue though. a small counter would probably make little difference, but a huge multi-dimensional array that didn't get properly re-used when it could've been would be more of an issue. Still, I think we've both got points on this issue...like I said above, what you proved VB6 could do was more than I thought it could. Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message You'd have to try it to see.news:uOCI4DsYHHA.3656@TK2MSFTNGP05.phx.gbl... > Interesting. I wasn't aware that VB6 did a duplicate function scan. I > can see how a simple loop like that would reduce easily, and that VB6 > would then pick it up as a duplicate after the optimization, but I rather > suspect that in a more complex loop, it would probably fail and allocate > two memory spaces for the two variables. > At this simple level, yes, I suspect it would be using register VB6 uses a modified version of microsoft's C compiler so I believe it is > optimization. Assuming it went beyond register optimization (i.e., if you > had a whole lot more declarations), though, I'd be very surprised if it > optimized memory usage...it's entirely possible that it would, though, you > might be right. Even the little you proved that it could optimize took me > by surprise. Admittedly, my knowledge of compiler technology is woefully > out of date...primarily because I haven't had either the need or desire to > make one in ages, and the little reverse-engineering I've done has all > been on programs from the 80's and early 90's. I know .NET does a LOT of > work in terms of figuring out what you were attempting to do and > optimizing it (it has to, it's so slow in some ways), but I suspect that > VB6's capabilities are more than a bit more limited in that regard, so > probably more complex stuff would be more likely to not be well-optimized. quite advanced. > Which is what I said somewhere in the thread...something to the effect Ok, I didn't see that. With the multi dimensional array it would make sense > that a small counter would probably make little difference, but a huge > multi-dimensional array that didn't get properly re-used when it could've > been would be more of an issue. to erase it or reuse it. > Still, I think we've both got points on this issue...like I said above, True.> what you proved VB6 could do was more than I thought it could. Michael "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message Not really. What makes goto so bad is that you can use it to jump *into* news:O6x6RUOYHHA.2316@TK2MSFTNGP04.phx.gbl... > Hehehe. I have no objection to the idea at all; I just learned a certain > rigidity, and despite bitching about it at the time, have found that it > works for me in general. I also don't randomly jump out of loops with > things like Exit Do or Exit For. They're effectively a form of GoTo, loops and hence violate the flow of the code (not sure of the technical term here). Using Exit For etc you can only jump out of loops. > and like Pascal taught, I find they're absolutely never necessary (and How do you search for something in a list and stop the search when you find > only very rarely even useful) once you wrap your mind around doing without > them. Like I said, Pascal influenced my programming style significantly. > :) it? Michael > Not really. What makes goto so bad is that you can use it to jump *into* Definitely true. Goto is a clear step worse than Break (Pascal), Exit > loops and hence violate the flow of the code (not sure of the technical > term here). Using Exit For etc you can only jump out of loops. Do/For, etc. > How do you search for something in a list and stop the search when you Counter = ListCount> find it? FoundIt = False Do If ListItem = SearchItem Then FoundIt = True Else Counter = Counter -1 End If Loop Until FoundIt Or (Counter = 0) ....or if you're worried about cutting down on your comparisons, Counter = ListCount Do If ListItem = SearchItem Then SomeVar = ListItem(Counter) Counter = 0 Else Counter = Counter -1 End If Loop Until Counter = 0 Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I did once code like this because I didn't like the exit for etc but gave it news:ej8d25ZYHHA.208@TK2MSFTNGP05.phx.gbl... > Counter = ListCount > FoundIt = False > Do > If ListItem = SearchItem Then > FoundIt = True > Else > Counter = Counter -1 > End If > Loop Until FoundIt Or (Counter = 0) up. It's less readable, uses an extra variable and is 3 times as much code. It can also get complicated if the loop has more code after this initial check. You might say in the second example you didn't need an extra var but you did because you need one for the loop counter and 1 to store the result. With a exit for you only need 1 var, eg for x = 1 to count if SomeArray(x) = SearchItem then exit for next if x <= count then DoStuff end if Also, what if you're searching a collection? The only way out is an exit for. Michael > for x = 1 to count This method pre-supposes that x will be equal to count + 1 at the end of the> if SomeArray(x) = SearchItem then exit for > next > if x <= count then > DoStuff > end if loop, which is implied, but not specifically stated in the documentation, though it dates back to MS BASIC. It's also language-specific; I believe the value is undefined after looping in some languages. Also, suppose <count> happens to be exactly the same as the maximum size of x's data type. I *believe* (but haven't checked) that the for loop will simply wrap around without checking (maybe, maybe not...certainly would if overflow checking is turned off). In that case, "if x <= count" will succeed where it shouldn't. > Also, what if you're searching a collection? The only way out is an exit How so? I've searched collections many times without difficulty, so I'm not > for. sure what it is you're referring to. Do you mean a For Each...Next loop? If so, I only ever use those where I KNOW I'm going to be iterating through the entire collection. I don't like them in general for searching because how do you find out the result after your Exit For? You have to have an extra variable to store the found result, and you have no index into the collection once you're done (unless the collection provides an index for you). Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote No index is needed, consider (3 or more textboxes on a form):> the entire collection. I don't like them in general for searching because > how do you find out the result after your Exit For? You have to have an > extra variable to store the found result, and you have no index into the > collection once you're done Dim tbx For Each tbx In Me.Controls If TypeOf tbx Is TextBox Then If tbx.Text = "Text2" Then Exit For End If End If Next With tbx .Text = UCase$(.Text) .BackColor = vbYellow End With LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in message In addition to that you can check if tbx is nothing. Then you know the loop news:OY1WPxfYHHA.3268@TK2MSFTNGP04.phx.gbl... > No index is needed, consider (3 or more textboxes on a form): > > Dim tbx > For Each tbx In Me.Controls > If TypeOf tbx Is TextBox Then > If tbx.Text = "Text2" Then > Exit For > End If > End If > Next > > With tbx > .Text = UCase$(.Text) > .BackColor = vbYellow > End With > completed without the item being found. Michael
Show quote
Hide quote
>> No index is needed, consider (3 or more textboxes on a form): Or simply handle the assignments at the time the control is found...>> >> Dim tbx >> For Each tbx In Me.Controls >> If TypeOf tbx Is TextBox Then >> If tbx.Text = "Text2" Then >> Exit For >> End If >> End If >> Next >> >> With tbx >> .Text = UCase$(.Text) >> .BackColor = vbYellow >> End With >> > > In addition to that you can check if tbx is nothing. Then you know the > loop completed without the item being found. Dim tbx As Control For Each tbx In Me.Controls If TypeOf tbx Is TextBox Then If tbx.Text = "Text2" Then With tbx .Text = UCase$(.Text) .BackColor = vbYellow End With Exit For End If End If Next If you still need to know that a control with that name wasn't found (in order to pop up a MessageBox or whatever), you can still test for that condition afterwards. Rick
Show quote
Hide quote
"Rick Rothstein (MVP - VB)" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in I will do that if the code within the if statement is simple like it is message news:uF5fwfiYHHA.2436@TK2MSFTNGP06.phx.gbl... > Or simply handle the assignments at the time the control is found... > > Dim tbx As Control > For Each tbx In Me.Controls > If TypeOf tbx Is TextBox Then > If tbx.Text = "Text2" Then > With tbx > .Text = UCase$(.Text) > .BackColor = vbYellow > End With > Exit For > End If > End If > Next here. If it's too many lines then I'll put it after the loop. If it starts another loop then I'll definately put it after :-) > If you still need to know that a control with that name wasn't found (in True.> order to pop up a MessageBox or whatever), you can still test for that > condition afterwards. Michael Ah, okay, true enough. I hadn't thought it through well enough.
Here again, though, I tend to write without the Exit For... i = 0 FoundIt = False While (i < Me.Controls.Count) And Not FoundIt Set tbx = Me.Controls(i) If TypeOf tbx Is TextBox Then If tbx.Text = "Text2" Then FoundIt = True End If Else i = i + 1 End If Wend This method assumes that you also want an index into the collection when you're done; it would be almost as short as your code if you didn't need it, though you'd still need i as the counter. So as you can see, it's not *necessary* to use an Exit For, just sometimes useful. Places where I *do* sometimes find it useful (though often I'll still code around the problem) is for things like recordsets where... Do 'DoStuff Loop Until rs.EOF Or (rs!MyField.Value = "Test") ....would be really nice to be able to do, but you can't since the logic is not short-circuited, and MyField will be checked even if the recordset isn't sitting on a valid record. With an Exit Do in there, however, you can skip the EOF check at the end and just exit the loop from inside if rs.EOF = True. Like I said, I usually code around that sort of problem, though, unless it would make the code absurdly messy...I *really* don't like exiting loops from somewhere other than the loop's condition. 'Not-too-messy coded around: Do 'DoStuff If Not rs.EOF Then s = rs!MyField.Value Loop Until rs.EOF or (s = "Test") Extra variables and coding, yes, but like I say, you ALWAYS know that one of your loop conditions has been satisfied in order to exit the loop. Rob Show quoteHide quote "Larry Serflaten" <serfla***@usinternet.com> wrote in message news:OY1WPxfYHHA.3268@TK2MSFTNGP04.phx.gbl... > > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote > > >> the entire collection. I don't like them in general for searching >> because >> how do you find out the result after your Exit For? You have to have an >> extra variable to store the found result, and you have no index into the >> collection once you're done > > No index is needed, consider (3 or more textboxes on a form): > > Dim tbx > For Each tbx In Me.Controls > If TypeOf tbx Is TextBox Then > If tbx.Text = "Text2" Then > Exit For > End If > End If > Next > > With tbx > .Text = UCase$(.Text) > .BackColor = vbYellow > End With > > > LFS > > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message That is true, I guess there is always a way around it. But I think you've news:%23GzNTXmYHHA.3272@TK2MSFTNGP03.phx.gbl... > This method assumes that you also want an index into the collection when > you're done; it would be almost as short as your code if you didn't need > it, though you'd still need i as the counter. So as you can see, it's not > *necessary* to use an Exit For, just sometimes useful. shown that the alternatives are always much more messy, obfuscated and difficult to read. > unless it would make the code absurdly messy...I *really* don't like But why? You said before that it is a form of goto, but If, Else, For, Do, > exiting loops from somewhere other than the loop's condition. While, calling a function etc are all forms of goto. Michael >> unless it would make the code absurdly messy...I *really* don't like I don't like Exit For/Exit Do because you can get out of the loop without >> exiting loops from somewhere other than the loop's condition. > But why? You said before that it is a form of goto, but If, Else, For, Do, > While, calling a function etc are all forms of goto. having satisfied the conditions for getting out of the loop. It might be appropriate if you're dealing with something like an error condition, but the only way out of 99% of my loops is to have satisfied their conditions. I realize that not everyone thinks this bay, but to me, having one or more Exit For's in addition to the loop condition is like having two or more Exit Sub's in the same Sub...it's perfectly legit, but in my books, it's bad form. Rob Robert Morley wrote:
> I don't like Exit For/Exit Do because you can get out of the loop without I see OOP zealots now and then these days, but it's been a decade, or> having satisfied the conditions for getting out of the loop. It might be > appropriate if you're dealing with something like an error condition, but > the only way out of 99% of my loops is to have satisfied their conditions. > I realize that not everyone thinks this bay, but to me, having one or more > Exit For's in addition to the loop condition is like having two or more Exit > Sub's in the same Sub...it's perfectly legit, but in my books, it's bad > form. perhaps even two, since I've noticed a structured programming zealot. Bob -- The real question is: would you know one if you saw one. I've seen all
KINDS of code that doesn't use Exit For/Exit Do, and I've seen several places that recommend you don't use multiple Exit Subs, but you don't tend to notice when someone DOESN'T use these techniques; you most definitely notice it when they do. To me, they stand out just as much as any GOTO. But that aside, when we started this whole tangent, I said that my second language was Pascal, and that it had affected my programming practices immensely...were you expecting anything less than structured programming? What's more, the use of Goto is STILL considered taboo in almost all modern languages, so to some extent, all programmers follow structured programming...it's just a matter of degree. Finally, I don't know that I'd call myself a zealot. I don't push my programming style on anybody else; it's simply what I practice for myself. Rob Show quoteHide quote "Bob O`Bob" <filter***@yahoogroups.com> wrote in message news:uzaezNsYHHA.1216@TK2MSFTNGP03.phx.gbl... > Robert Morley wrote: > >> I don't like Exit For/Exit Do because you can get out of the loop without >> having satisfied the conditions for getting out of the loop. It might be >> appropriate if you're dealing with something like an error condition, but >> the only way out of 99% of my loops is to have satisfied their >> conditions. I realize that not everyone thinks this bay, but to me, >> having one or more Exit For's in addition to the loop condition is like >> having two or more Exit Sub's in the same Sub...it's perfectly legit, but >> in my books, it's bad form. > > > I see OOP zealots now and then these days, but it's been a decade, or > perhaps even two, since I've noticed a structured programming zealot. > > > > Bob > -- In regards to code readability, here's a good example of why I don't use
Exit For/Exit Do: Example 1: Do 'DoStuff Loop Until EOF(MyFile) Example 2: Do 'DoStuff Loop Until EOF(MyFile) Or (s = "SomeString") In Example 1, I look at it and assume that it's reading the entire file without having to stop and decipher any code within to see if maybe it's not. In Example 2, I know it's reading the file, but it's immediately obvious that there's some kind of searching or file processing going on, and that the loop could conceivably stop before the end of the file. Of course, if I got the code from people like you, I'd search for any abnormal termination of the loop, but at least for myself and people who code like I do, a glance tells me what the loop is doing without any further reading. Rob Show quoteHide quote "Michael C" <nospam@nospam.com> wrote in message news:%23ubMm6qYHHA.4396@TK2MSFTNGP06.phx.gbl... > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message > news:%23GzNTXmYHHA.3272@TK2MSFTNGP03.phx.gbl... >> This method assumes that you also want an index into the collection when >> you're done; it would be almost as short as your code if you didn't need >> it, though you'd still need i as the counter. So as you can see, it's >> not *necessary* to use an Exit For, just sometimes useful. > > That is true, I guess there is always a way around it. But I think you've > shown that the alternatives are always much more messy, obfuscated and > difficult to read. > >> unless it would make the code absurdly messy...I *really* don't like >> exiting loops from somewhere other than the loop's condition. > > But why? You said before that it is a form of goto, but If, Else, For, Do, > While, calling a function etc are all forms of goto. > > Michael > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message In practice it's not an issue. I can not remember 1 single time where I got news:eXN7dtrYHHA.3848@TK2MSFTNGP02.phx.gbl... > In Example 1, I look at it and assume that it's reading the entire file > without having to stop and decipher any code within to see if maybe it's > not. In Example 2, I know it's reading the file, but it's immediately > obvious that there's some kind of searching or file processing going on, > and that the loop could conceivably stop before the end of the file. caught out with an exit loop statement. I remember 1 case where I missed an exit sub but I caught that pretty quick. In either case you need to look through anyway to see if there is an exit if you didn't write the code. > Of course, if I got the code from people like you, Most people do use exit statements. You'd be hard pressed to find any C code that didn't use return. > I'd search for any abnormal termination of the loop, but at least for If you glance at any code you're likely to get the wrong idea. I think that > myself and people who code like I do, a glance tells me what the loop is > doing without any further reading. this potential issue is far outweighted by the extra code that is required to avoid the exits. Michael > Most people do use exit statements. You'd be hard pressed to find any C In my experience, it's actually about 50/50 for VB whether people use Exit > code that didn't use return. or not. And let's not bring that other language into this...I detest that more than I detest VB.NET. > If you glance at any code you're likely to get the wrong idea. I think I see it differently because to me the extra code is usually negligible, and > that this potential issue is far outweighted by the extra code that is > required to avoid the exits. to my mind, the code becomes more readable, not less, since you don't ever have to look INTO the loop to know what it's doing. That and the fact that you know with certainty that loops will always be at a known point when they exit is well worth a couple of extra lines of typing to me. Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I disagree with that. The only time I've ever seen anyone actively avoid news:%232WzuGsYHHA.688@TK2MSFTNGP03.phx.gbl... > In my experience, it's actually about 50/50 for VB whether people use Exit > or not. exit statements is in my very early code and in yours. I've seen people post questions on whether or not exit was ok and the response was a big yes from everyone who replied. > And let's not bring that other language into this...I detest that more Well, in other languages I think you'd be hard pressed to find a single > than I detest VB.NET. developer who avoided return statements, break and continue. :-) > I see it differently because to me the extra code is usually negligible, I think you'd find it's just not a big deal and is far easier to make clear > and to my mind, the code becomes more readable, not less, since you don't > ever have to look INTO the loop to know what it's doing. That and the > fact that you know with certainty that loops will always be at a known > point when they exit is well worth a couple of extra lines of typing to > me. code. For example when doing a drag drop code 'aircode: Sub Grid2_DragDrop if Source is not Grid1 then exit sub if Item is not a cell then exit sub If Cell is blank then exit sub If DestCell is not blank then exit sub etc. it makes sense to use exit sub because if the right conditions are not met then you want to stop whatever you are doing immediately. It mimics what would happen in real life and shows that execution terminates immediately for this code. If you use an If statement then you have to scan to the end of the function to see if something else is executed afterward or see if there is an else statement. In one quick line of code I can see exactly what is happening. The same thing happens when avoiding Exit statements in loops. Interestingly this is the exact reason you don't like exit statements. :-) Michael > Sub Grid2_DragDrop In compiled code, there's no difference between that and nested If's, but > if Source is not Grid1 then exit sub > if Item is not a cell then exit sub > If Cell is blank then exit sub > If DestCell is not blank then exit sub > etc. yes, I agree that the above is more readable and I do sometimes use multiple Exit Subs in that context. What I object to violently is code where the Exit Subs are not out at the front, but scattered all over the place...cases where the procedure is simply exited and trusted to do its own cleanup, rather than going through a single point of exit that closes files, de-allocates memory, de-references objects, etc. > The same thing happens when avoiding Exit statements in loops. Provide an example...I've yet to see an Exit statement in a loop that I > Interestingly this is the exact reason you don't like exit statements. :-) thought looked cleaner than a loop that had all its conditions out front (or at the end if you're using Do...Loop Until/While). Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message That's the problem with VB, there is no clean way to do this. I don't mind news:uh1zVvsYHHA.1300@TK2MSFTNGP02.phx.gbl... > In compiled code, there's no difference between that and nested If's, but > yes, I agree that the above is more readable and I do sometimes use > multiple Exit Subs in that context. What I object to violently is code > where the Exit Subs are not out at the front, but scattered all over the > place...cases where the procedure is simply exited and trusted to do its > own cleanup, rather than going through a single point of exit that closes > files, de-allocates memory, de-references objects, etc. exit subs scattered throughout as long as objects are disposed of correctly. Often it's more than a simple test, for example with the previous code we might need to search a list if the item can be dropped. I know you're not a .net fan but with a try catch it can be done very cleanly, eg: dim x as new connection x.open "Blah" try 'do stuff including exit sub finally x.close end try In this code the connection is closed with 100% certainty once it is open. > Provide an example...I've yet to see an Exit statement in a loop that I We've already had several examples that were much cleaner with exit for, > thought looked cleaner than a loop that had all its conditions out front > (or at the end if you're using Do...Loop Until/While). here's one: For each Customer in Customers If Customer.Name = "Tanya" then exit for Next If Customer Is Something then 'DoStuffToCustomer End if Michael > I know you're not a .net fan but with a try catch it can be done very Yes, there are distinct advantages to some of .NET's stuff, I don't deny it. > cleanly, eg: > > dim x as new connection > x.open "Blah" > try > 'do stuff including exit sub > finally > x.close > end try My main objections to .NET are more to do with the lack of real upgrade path from VB6 and the fact that it's often produces fairly sluggish code. The language changes themselves I actually like, for the most part...but I tend to side more with the VFred camp, who see it as a new language that should've been called something else in the same way that Delphi wasn't called Pascal. > We've already had several examples that were much cleaner with exit for, This is a fundamental disagreement between us then. When I see a For Next > here's one: > > For each Customer in Customers > If Customer.Name = "Tanya" then exit for > Next > If Customer Is Something then > 'DoStuffToCustomer > End if or For Each loop, I see something that I expect to run from start to finish. When I see a Do or While loop, I see something that I expect to finish conditionally (ideally with all conditions in the loop, or if not, a loop-ending condition). While the For loop you've shown may be shorter, and at the three-line level, might be easier to read (still debatable to my mind), in a larger loop, if I'm skimming and I see "For Each Customer" then I want to see something that iterates...well...for each customer. It's not "clean" to my way of thinking. But in any event, we're really just talking about stylistic differences. As long as others can reasonably understand your code, the choice of whether to use a loop that's a couple of lines shorter or longer, or to "convert from dec to bin" in 20 lines or 5 or 1 is truly irrelevant (though even Rick agreed that the one-liner was NOT reasonably understandable <g>). About the only thing this rather long-winded debate has truly done is to establish that we're all long-time programmers, each with our own skills and our own ways of doing things. The rest is just semantics (literally, come to think of it). Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message That's really just your expectation. You're really just saying you don't news:ekR8sRtYHHA.1296@TK2MSFTNGP02.phx.gbl... > This is a fundamental disagreement between us then. When I see a For Next > or For Each loop, I see something that I expect to run from start to > finish. When I see a Do or While loop, I see something that I expect to > finish conditionally (ideally with all conditions in the loop, or if not, > a loop-ending condition). While the For loop you've shown may be shorter, > and at the three-line level, might be easier to read (still debatable to > my mind), in a larger loop, if I'm skimming and I see "For Each Customer" > then I want to see something that iterates...well...for each customer. > It's not "clean" to my way of thinking. like it because you don't like it. I don't have the expectation that it will complete. > But in any event, we're really just talking about stylistic differences. Fair enough, we've both made our points. Going any further would just be > As long as others can reasonably understand your code, the choice of > whether to use a loop that's a couple of lines shorter or longer, or to > "convert from dec to bin" in 20 lines or 5 or 1 is truly irrelevant > (though even Rick agreed that the one-liner was NOT reasonably > understandable <g>). About the only thing this rather long-winded debate > has truly done is to establish that we're all long-time programmers, each > with our own skills and our own ways of doing things. The rest is just > semantics (literally, come to think of it). going in circles. Good to see this didn't desolve into a flaming war. :-) Michael > That's really just your expectation. You're really just saying you don't The same argument applies in reverse, too, though. You don't like my code > like it because you don't like it. I don't have the expectation that it > will complete. because it's a couple of lines longer; I don't like your code because the exit conditions aren't part of the loop. > Fair enough, we've both made our points. Going any further would just be While a debate really wasn't what I needed tonight (long day), I didn't > going in circles. Good to see this didn't desolve into a flaming war. :-) really expect it to dissolve into a flame war. I may be set in my ways, but I'm not unaware of the logic of your arguments. You have some good points. Of course, if you'd really wanted to blow my argument to smithereens, you would've brought in assembly language...you really don't have much choice BUT to jump out of structures in any assembly language I've ever seen. :) Rob "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I very much like to make code the minimum number of lines without being news:Ofss2dtYHHA.3996@TK2MSFTNGP02.phx.gbl... > The same argument applies in reverse, too, though. You don't like my code > because it's a couple of lines longer; I don't like your code because the > exit conditions aren't part of the loop. silly about it. For example I don't see anything wrong with if x < 0 then x = 0 As long as the if and then parts are short then 1 line is good. :-) > While a debate really wasn't what I needed tonight (long day), I didn't I don't think that would have blown anything apart :-) The great thing about > really expect it to dissolve into a flame war. I may be set in my ways, > but I'm not unaware of the logic of your arguments. You have some good > points. Of course, if you'd really wanted to blow my argument to > smithereens, you would've brought in assembly language...you really don't > have much choice BUT to jump out of structures in any assembly language > I've ever seen. :) assembly is not only can you jump in and out of loops but you can jump into another function, even one in another dll :-) Show quoteHide quote > > > > Rob > > I very much like to make code the minimum number of lines without being It's a good policy to take, definitely. I admit to being anal retentive > silly about it. For example I don't see anything wrong with > > if x < 0 then x = 0 about my "rules", but every once in a while, I'll realize that I'm just being stupid about things. While I'm not there with Exit For/Exit Do yet, I did come to the conclusion that multiple Exit Subs could maybe be used in certain limited circumstances (as previously discussed) a few years ago. I think the main reason I impose these kinds of rules on myself is because I've seen what spaghetti code can look like (as I'm sure we all have), and jumping out of loops is one of the things I see the most. By not allowing myself to use them, I ensure (or at least try to) that my code will never look like "that". :) But to get to your specific example, yeah, I almost never put a single statement If...Then on multiple lines. About the only time I do that is if I reasonably expect to come back and add more code there later, or, as you say, sometimes if the conditions or statement are abnormally long. Rob >> If you glance at any code you're likely to get the wrong idea. I think You should never have to interpret what a loop is doing by its termination >> that this potential issue is far outweighted by the extra code that is >> required to avoid the exits. > > I see it differently because to me the extra code is usually negligible, > and to my mind, the code becomes more readable, not less, since you don't > ever have to look INTO the loop to know what it's doing. condition nor by trying to figure out what its internal code is doing... if you can't read a comment about the what, why and how of the loop in an initial set of comments, then I consider the code to be seriously defective. > That and the fact that you know with certainty that loops will always If you are artificially inflating (or deflating as the case may be) an > be at a known point when they exit is well worth a couple of extra > lines of typing to me. indexing variable in order to satisfy a known exit condition, then I don't see how that is particularly useful. On the other hand, if you have your code structured in such a way as it exits via some kind of "fall through" mechanism, then I'm not entirely sure that leaves things in a state that is markedly different than what results from using an Exit XXX statement. Rick > You should never have to interpret what a loop is doing by its termination Hahaha...great, someone else comes along and blasts both our arguments to > condition nor by trying to figure out what its internal code is doing... > if you can't read a comment about the what, why and how of the loop in an > initial set of comments, then I consider the code to be seriously > defective. hell. Don't you know, Rick, 1337 programmers don't USE comments! :P Okay, truth be told, I don't usually use comments to the level you're describing, but I'm not programming in a team environment, either. I tend to think that comments on "tricky" code are good, and comments describing the purpose and perhaps the general approach of a routine are enough. But that's for me and the environment I'm in...every programmer I've ever met uses a different level and style of commenting, and I admit to being on the sparse end of that scale. :) > If you are artificially inflating (or deflating as the case may be) an True...I actually try to avoid that when possible and use something more > indexing variable in order to satisfy a known exit condition, then I don't > see how that is particularly useful. like a FoundIt variable, but my posts were for the point of demonstration on POSSIBLE ways to avoid Exit For, which was originally deemed impossible to avoid. > On the other hand, if you have your code structured in such a way as it You're right, in terms of state, there's no difference between forcing a > exits via some kind of "fall through" mechanism, then I'm not entirely > sure that leaves things in a state that is markedly different than what > results from using an Exit XXX statement. fall-through by altering a variable in whatever manner, and using an Exit. Again, it comes back to the question of style and what you expect to see. I expect to see all termination conditions in the loop clause somewhere (at least, ideally...programming can sometimes be less than ideal, as we all know), preferably they should also be obvious as to what they do and how they get to that point, but that goes back to the "ideally" thing again. About the only possible advantage (and I admit, it ain't much of one) is that if you're using a fall-through condition, by definition, you're altering one of the variables in the loop condition and know its state...that's one less thing than you'd have to do given the same set of variables and an Exit. (Told you it wasn't much of an advantage...especially if you consider that you *might* not need as many variables if you use an Exit in your loop.) Rob Robert Morley wrote:
> Hahaha...great, someone else comes along and blasts both our arguments to Detailed comments on "tricky" code are required.> hell. Don't you know, Rick, 1337 programmers don't USE comments! :P Okay, > truth be told, I don't usually use comments to the level you're describing, > but I'm not programming in a team environment, either. I tend to think that > comments on "tricky" code are good, and comments describing the purpose and > perhaps the general approach of a routine are enough. But that's for me and > the environment I'm in...every programmer I've ever met uses a different > level and style of commenting, and I admit to being on the sparse end of > that scale. :) That's something I have actually cited when /terminating/ an employee who didn't work out (though not the sole, nor even most important factor) >> On the other hand, if you have your code structured in such a way as it Once in a great while, a certain "tricky" method is only available in some>> exits via some kind of "fall through" mechanism, then I'm not entirely >> sure that leaves things in a state that is markedly different than what >> results from using an Exit XXX statement. programming languages. Like the time I wrote a switch statement in C (similar to Select Case) in order to draw the "pips" on a graphical representation of playing dice. The '6' case drew two pips and "fell through" to the '4', which drew two more then fell into the '2' and so on. VB can't code that quite as efficiently. Bob -- > Detailed comments on "tricky" code are required. That is so true! I mean, how else would you know how your one-liners worked (the very next day) if you didn't tell yourself in a comment?<g> Rick "Bob O`Bob" <filter***@yahoogroups.com> wrote in message This facility is gone in C#. Every case must have a break or you'll get a news:eA%23KnOuYHHA.4692@TK2MSFTNGP04.phx.gbl... > Once in a great while, a certain "tricky" method is only available in some > programming languages. Like the time I wrote a switch statement in C > (similar to Select Case) in order to draw the "pips" on a graphical > representation > of playing dice. The '6' case drew two pips and "fell through" to the > '4', > which drew two more then fell into the '2' and so on. VB can't code that > quite as efficiently. compile error. This is pretty silly imo because they may as well just eliminate the fall through and eliminate break and have it work like vb6. Michael > This facility is gone in C#. Every case must have a break or you'll get a Yeah, that DOES sound kinda silly. Personally, I'd like the ability to have > compile error. This is pretty silly imo because they may as well just > eliminate the fall through and eliminate break and have it work like vb6. a Select Case fall through to other cases at times, but I can live without. Maybe rather than forcing a break for each case, they should've made a variation to the command (or a whole new one?) so you could pick between "Switch" and "Fall-through Switch"? Ah well, I'm not MS, so I don't get to decide. (If I did, a lot of programmers would be yelling at me about the lack of Exit Do and Exit For! <g>) Rob Robert Morley wrote:
>> This facility is gone in C#. Every case must have a break or you'll get a In Jovial, the default was that a new case statement functioned as a break>> compile error. This is pretty silly imo because they may as well just >> eliminate the fall through and eliminate break and have it work like vb6. > > Yeah, that DOES sound kinda silly. Personally, I'd like the ability to have > a Select Case fall through to other cases at times, but I can live without. > Maybe rather than forcing a break for each case, they should've made a > variation to the command (or a whole new one?) so you could pick between > "Switch" and "Fall-through Switch"? Ah well, I'm not MS, so I don't get to > decide. (If I did, a lot of programmers would be yelling at me about the > lack of Exit Do and Exit For! <g>) (as in VB) but we had an option. I think the keyword was "fallthru" but I haven't touched Jovial since about 1988. Bob -- > but I haven't touched Jovial since about 1988. Sounds like those were happy times back then. <g>Rick "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I think they way they've got it is probably the best way. Allowing fall news:%230FcpD1YHHA.4988@TK2MSFTNGP03.phx.gbl... > Yeah, that DOES sound kinda silly. Personally, I'd like the ability to > have a Select Case fall through to other cases at times, but I can live > without. Maybe rather than forcing a break for each case, they should've > made a variation to the command (or a whole new one?) so you could pick > between "Switch" and "Fall-through Switch"? Ah well, I'm not MS, so I > don't get to decide. (If I did, a lot of programmers would be yelling at > me about the lack of Exit Do and Exit For! <g>) through is one of the big causes of bugs in C apparently. Considering the potential for bugs, the number of times it would be useful and the way it makes code more difficult to read I think we're better off without fall through. I just don't like the way we have to type a redundant break statement over and over. :-) Michael
Show quote
Hide quote
On Sun, 11 Mar 2007 10:04:52 +1100, "Michael C" <nospam@nospam.com> Fall through sounds lethal to mewrote: >"Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message >news:%230FcpD1YHHA.4988@TK2MSFTNGP03.phx.gbl... >> Yeah, that DOES sound kinda silly. Personally, I'd like the ability to >> have a Select Case fall through to other cases at times, but I can live >> without. Maybe rather than forcing a break for each case, they should've >> made a variation to the command (or a whole new one?) so you could pick >> between "Switch" and "Fall-through Switch"? Ah well, I'm not MS, so I >> don't get to decide. (If I did, a lot of programmers would be yelling at >> me about the lack of Exit Do and Exit For! <g>) >I think they way they've got it is probably the best way. Allowing fall >through is one of the big causes of bugs in C apparently. Considering the >potential for bugs, the number of times it would be useful and the way it >makes code more difficult to read I think we're better off without fall >through. I just don't like the way we have to type a redundant break >statement over and over. :-) Also a bit unnecessary as multiple If .. Then s would do the trick and be clearer. "Bob O`Bob" <filter***@yahoogroups.com> wrote It would be interesting to see how you handled the other numbers because> Once in a great while, a certain "tricky" method is only available in some > programming languages. Like the time I wrote a switch statement in C > (similar to Select Case) in order to draw the "pips" on a graphical representation > of playing dice. The '6' case drew two pips and "fell through" to the '4', > which drew two more then fell into the '2' and so on. VB can't code that > quite as efficiently. you have to differentiate all combinations, at some point. VB can do it using 4 If/Then statements, which IMHO is efficient enough.... Given the pip positions: 1 2 3 4 5 6 7 If N And 1 Then Draw(4) If N > 1 Then Draw(3, 5) If N > 3 Then Draw(1, 7) If N = 6 Then Draw(2, 6) LFS Larry Serflaten wrote:
Show quoteHide quote > "Bob O`Bob" <filter***@yahoogroups.com> wrote Yeah, that's actually pretty good.> >> Once in a great while, a certain "tricky" method is only available in some >> programming languages. Like the time I wrote a switch statement in C >> (similar to Select Case) in order to draw the "pips" on a graphical representation >> of playing dice. The '6' case drew two pips and "fell through" to the '4', >> which drew two more then fell into the '2' and so on. VB can't code that >> quite as efficiently. > > It would be interesting to see how you handled the other numbers because > you have to differentiate all combinations, at some point. VB can do it using > 4 If/Then statements, which IMHO is efficient enough.... > > Given the pip positions: > > 1 2 3 > > 4 > > 5 6 7 > > > If N And 1 Then Draw(4) > If N > 1 Then Draw(3, 5) > If N > 3 Then Draw(1, 7) > If N = 6 Then Draw(2, 6) > It effectively combines 2 with 3 and 4 with 5. What I had (this was at least 20 years ago) was similar to case 6 draw 2, 6 (fall through) case 4 draw 1, 7 (fall through) case 2 draw 3, 5 break case 5 draw 1, 7 (fall through) case 3 draw 3, 5 (fall through) case 1 draw 4
Show quote
Hide quote
"Rick Rothstein (MVP - VB)" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in Well stated, clear, and succinct.message news:OIIpE6sYHHA.4008@TK2MSFTNGP05.phx.gbl... > >> <snipped> > > If you are artificially inflating (or deflating as the case may be) an > indexing variable in order to satisfy a known exit condition, then I don't > see how that is particularly useful. On the other hand, if you have your > code structured in such a way as it exits via some kind of "fall through" > mechanism, then I'm not entirely sure that leaves things in a state that is > markedly different than what results from using an Exit XXX statement. > > Rick > You have mercifully allowed me to delete a rambling multiple paragraph reply (with examples & footnotes) which didn't say anything more than what you did. <g> -ralph > You have mercifully allowed me to delete a rambling multiple paragraph LOL> reply > (with examples & footnotes) which didn't say anything more than what you > did. <g> Rick "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message It's set in stone now for vb but yes, many languages won't work. In well news:e$4EzWeYHHA.984@TK2MSFTNGP04.phx.gbl... > This method pre-supposes that x will be equal to count + 1 at the end of > the > loop, which is implied, but not specifically stated in the documentation, > though it dates back to MS BASIC. It's also language-specific; I believe > the value is undefined after looping in some languages. designed languages the loop var is out of scope anyway. > Also, suppose <count> happens to be exactly the same as the maximum size It will give an error, not wrap around. When using a byte, for x = 0 to 255 > of x's data type. I *believe* (but haven't checked) that the for loop > will simply wrap around without checking (maybe, maybe not...certainly > would if overflow checking is turned off). In that case, "if x <= count" > will succeed where it shouldn't. fails. For other languages I believe you'd have problems anyway, eg for(byte b = 0; b <= 255; b++) { } This loop will probably never exit because b is always 255 or less. So writing a for loop that goes to the limit of a variable is not possible anyway. > How so? I've searched collections many times without difficulty, so I'm Yep.> not sure what it is you're referring to. Do you mean a For Each...Next > loop? > If so, I only ever use those where I KNOW I'm going to be iterating Generally if I need the index then I won't use foreach. It's possible > through the entire collection. I don't like them in general for searching > because how do you find out the result after your Exit For? (although highly unlikely) that foreach won't return items in index order so incrementing your own index var is flawed, in theory at least. Foreach should only be used if the index is not required and only the object is required. > You have to have an extra variable to store the found result, and you have I don't think it makes much sense to avoid foreach just to avoid exit for.> no index into the collection once you're done (unless the collection > provides an index for you). Michael "Jeff Johnson" <i.get@enough.spam> wrote in message Well that's not long ago! I'm almost old enough to remember 19th century news:OomHpJBYHHA.4308@TK2MSFTNGP05.phx.gbl... > Colons as statement separators = 20th-century BASIC in my opinion. BASIC ;-) Mike "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I was about to write something about I use/abuse colons all the time, butnews:uITfVFBYHHA.992@TK2MSFTNGP02.phx.gbl... > > Dim res As String: res = "00000000" > > Dim i As Long: i = 8 > > Interesting way of declaring starting values for your variables...never seen > that style before. > > > Rob > one has to be very careful here. <g> The other nice thing about colons, besides the ability to declare and define variables in one place, is it preserves formatting to make your code even easier to read. So this this ... Dim idx As Long: idx = 100 Dim sWheelName As String: sWheelName = "abc" Dim r8Radius As Double: r8Radius = 5.6 becomes ... Dim idx As Long: idx = 100 Dim sWheelName As String: sWheelName = "abc" Dim r8Radius As Double: r8Radius = 5.6 -ralph Another interesting point. Personally, if there's more than two or three
declarations, I just tend to group all strings, all numbers (or if there are a lot, I'll group them out by specific type), etc., with a blank line in-between. But I can see the elegance of your style as well. Rob Show quoteHide quote "Ralph" <nt_consultin***@yahoo.com> wrote in message news:tcOdnWnv5O0RCnPYnZ2dnUVZ_g-dnZ2d@arkansas.net... > > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message > news:uITfVFBYHHA.992@TK2MSFTNGP02.phx.gbl... >> > Dim res As String: res = "00000000" >> > Dim i As Long: i = 8 >> >> Interesting way of declaring starting values for your variables...never > seen >> that style before. >> >> >> Rob >> > > I was about to write something about I use/abuse colons all the time, but > one has to be very careful here. <g> > > The other nice thing about colons, besides the ability to declare and > define > variables in one place, is it preserves formatting to make your code even > easier to read. > So this this ... > Dim idx As Long: idx = 100 > Dim sWheelName As String: sWheelName = "abc" > Dim r8Radius As Double: r8Radius = 5.6 > becomes ... > Dim idx As Long: idx = 100 > Dim sWheelName As String: sWheelName = "abc" > Dim r8Radius As Double: r8Radius = 5.6 > > -ralph > > "Robert Morley" <rmor***@magma.ca.N0.Freak1n.sparn> wrote in message I tend to group them by function eg:news:OQiF5ZOYHHA.1388@TK2MSFTNGP05.phx.gbl... > Another interesting point. Personally, if there's more than two or three > declarations, I just tend to group all strings, all numbers (or if there > are a lot, I'll group them out by specific type), etc., with a blank line > in-between. But I can see the elegance of your style as well. dim startdate as date, enddate as date dim x as long, y as long Michael Kardon Coupé wrote:
> Dear All, There's not enough information there to guess at.> > I'm looking for a way to convert a byte into decimal, the ultimate goal is > to read a byte from a file in binary, and convert it to a string of text, > I've googled around, and a lot of the snippets I find don't seem to meet my > needs. Reading bytes and converting to text is pretty trivial once you specify what you mean by "convert". Bob -- Bob O`Bob <filter***@yahoogroups.com> wrote:
> Kardon Coupé wrote: Yep, my first thought was, "What's wrong with Debug.Print?">> Dear All, >> >> I'm looking for a way to convert a byte into decimal, the ultimate goal is >> to read a byte from a file in binary, and convert it to a string of text, >> I've googled around, and a lot of the snippets I find don't seem to meet my >> needs. > > There's not enough information there to guess at. > > Reading bytes and converting to text is pretty trivial once you specify > what you mean by "convert". 
Other interesting topics
Registry on Vista
How to add a dynamic textbox with MultiLine??? HElP!!!! Class and object Excel automation late binding With and End With Help on registering a usercontrol Data Access via VPN How to Shut Windows Semi-OT (but helpful): Google Groups And Unexpanded Replies How to transfer controls to a picture box? |
|||||||||||||||||||||||
