|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Inputbox QuestionI want to control my input not to accept null or no value upon clicking OK button. Since Inputbox function accepts input, I use it but upon clicking Cancel button, the msgbox error also appear. I have attached my script for you to check out. Private Sub cmdAdd_Click() strInput = Trim(InputBox("Enter Name: ", "Append Name")) If strInput = "" Then MsgBox ("Null not allowed... Please try again"), vbCritical, "Error Message" Else . statements . . . End If End Sub Hoping for your response. regards, Me A P wrote:
> Hi! Use Trim$> > I want to control my input not to accept null or no value upon > clicking OK button. Since Inputbox function accepts input, I use it > but upon clicking Cancel button, the msgbox error also appear. I have > attached my script for you to check out. > > Private Sub cmdAdd_Click() > strInput = Trim(InputBox("Enter Name: ", "Append Name")) > If strInput = "" Then Use Len(strInput) = 0If StrPtr(strInput) = 0 Then MsgBox "You pressed cancel" else> MsgBox ("Null not allowed... Please try again"), vbCritical, "Error Message" End If > Else > . > statements > . > . > . > End If > End Sub -- Regards, Michael Cole StrPtr is not recognized. is it mistyped?
Show quoteHide quote "Michael Cole" <no***@hansen.com> wrote in message news:u3NGUN1gFHA.720@TK2MSFTNGP14.phx.gbl... > A P wrote: > > Hi! > > > > I want to control my input not to accept null or no value upon > > clicking OK button. Since Inputbox function accepts input, I use it > > but upon clicking Cancel button, the msgbox error also appear. I have > > attached my script for you to check out. > > > > Private Sub cmdAdd_Click() > > > > > strInput = Trim(InputBox("Enter Name: ", "Append Name")) > > Use Trim$ > > > If strInput = "" Then > > Use Len(strInput) = 0 > If StrPtr(strInput) = 0 Then > MsgBox "You pressed cancel" > else> MsgBox ("Null not allowed... Please try again"), > vbCritical, "Error Message" > > End If > > > Else > > . > > statements > > . > > . > > . > > End If > > End Sub > > -- > Regards, > > Michael Cole > > A P wrote:
> StrPtr is not recognized. is it mistyped? VarPtr and StrPtr are both unrecognised, but they do exist. Copy thefollowing to a module and run "test" in the immediate window. -- Option Explicit Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" ( _ ByRef Destination As Any, _ ByRef Source As Any, _ ByVal Length As Long) Sub test() Dim lng As Long, i As Integer, s As String Dim b(1 To 10) As Byte Dim sp As Long, vp As Long Dim ct As Long s = "help" sp = StrPtr(s) Debug.Print "StrPtr:" & sp CopyMemory ct, ByVal sp - 4, 4 Debug.Print "Length field: " & ct vp = VarPtr(s) Debug.Print "VarPtr:" & vp ' Verify that sp = xxxx and vp = aaaa ' by moving the long pointed to by vp (which is xxxx) ' to the variable lng and then comparing it to sp CopyMemory lng, ByVal vp, 4 Debug.Print lng = sp ' To see that sp contains address of char array, ' copy from that address to a byte array and print ' the byte array. We should get "help". CopyMemory b(1), ByVal sp, 10 For i = 1 To 10 Debug.Print b(i) & " (" & Chr$(b(i)) & ") "; Next End Sub -- Regards, Michael Cole "Michael Cole" <no***@hansen.com> wrote in message [Hoshi Patricia Friedman] And I was thinking StrPtr was only supported by news:O4cGHm2gFHA.3256@TK2MSFTNGP12.phx.gbl... >A P wrote: >> StrPtr is not recognized. is it mistyped? > > > VarPtr and StrPtr are both unrecognised, but they do exist. version 6.0 and maybe also 5.0. I have 4.0, you see, but it suits my needs. "Compu-Celebi" <c o m p u - c e l e b i @ v a l i n t . n e t> wrote in If you don't have access to the strptr function you can use the CopyMemory message news:11cs19m587pnea@corp.supernews.com... > [Hoshi Patricia Friedman] And I was thinking StrPtr was only supported by > version 6.0 and maybe also 5.0. I have 4.0, you see, but it suits my > needs. API to solve the problem. Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long) Private Sub Command1_Click() Dim s As String s = InputBox("Blah blah") Dim x As Long CopyMemory x, s, 4 If x = 0 Then MsgBox "Cancel pushed!" End Sub Show quoteHide quote > > No need for copymem if using VB4, the declare is:
Private Declare Function StrPtr Lib "vb40032.dll" (pAny As Any) As Long -- Show quoteHide quoteRandy Birch MS MVP Visual Basic http://vbnet.mvps.org/ ---------------------------------------------------------------------------- Read. Decide. Sign the petition to Microsoft. http://classicvb.org/petition/ ---------------------------------------------------------------------------- "Michael C" <mculley@NOSPAMoptushome.com.au> wrote in message news:%23TXUwH4gFHA.1052@TK2MSFTNGP10.phx.gbl... : "Compu-Celebi" <c o m p u - c e l e b i @ v a l i n t . n e t> wrote in : message news:11cs19m587pnea@corp.supernews.com... : > [Hoshi Patricia Friedman] And I was thinking StrPtr was only supported by : > version 6.0 and maybe also 5.0. I have 4.0, you see, but it suits my : > needs. : : If you don't have access to the strptr function you can use the CopyMemory : API to solve the problem. : : Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" : (Destination As Any, Source As Any, ByVal Length As Long) : : Private Sub Command1_Click() : Dim s As String : s = InputBox("Blah blah") : Dim x As Long : CopyMemory x, s, 4 : If x = 0 Then MsgBox "Cancel pushed!" : End Sub : : > : > : : Michael Cole wrote:
> > If strInput = "" Then Even better, use LenB(strInput) when simply checking for an empty> > Use Len(strInput) = 0 string. Len() is implemented as "LenB() \ 2", so using LenB() does not require the division. Also, any place where "" *IS* needed, you should use the constant "vbNullString" instead. "DenBorg" <den_b***@yahoo.com> wrote in message No, you shouldn't. vbNullString is documented as being available for use innews:1120824716.542650.296040@o13g2000cwo.googlegroups.com > Michael Cole wrote: >>> If strInput = "" Then >> >> Use Len(strInput) = 0 > > Even better, use LenB(strInput) when simply checking for an empty > string. Len() is implemented as "LenB() \ 2", so using LenB() does not > require the division. > > Also, any place where "" *IS* needed, you should use the constant > "vbNullString" instead. calling external API procedures that need to differentiate between "" and a null pointer; it is not documented as being a substitute for "". In the VB environment the implementation of vbNullString ends up being effectively identical to "" but they are not the same thing and you should not confuse the two. (It mattered more when there was a chance that there'd be a VB7 since you'd be running the risk of code not working if the implementation changed so it's really a moot point now.) -- Reply to the group so all can participate VB.Net: "Fool me once..." Bob Butler wrote:
> > Also, any place where "" *IS* needed, you should use the constant I wasn't confusing the two ("" and vbNullString), but as you've pointed> > "vbNullString" instead. > > No, you shouldn't. vbNullString is documented as being available for use in > calling external API procedures that need to differentiate between "" and a > null pointer; it is not documented as being a substitute for "". In the VB > environment the implementation of vbNullString ends up being effectively > identical to "" but they are not the same thing and you should not confuse > the two. (It mattered more when there was a chance that there'd be a VB7 > since you'd be running the risk of code not working if the implementation > changed so it's really a moot point now.) out, as implemented in VB they are *effectively* the same. When you use the literal value "", you are introducing bloat into your program. Each BSTR you define consumes an additional 4 bytes of memory. Using a *constant* in its place reduces this bloat. So, YES, you *should* use a constant instead of having hundreds of ""'s throughout your code. And if you are scared of using vbNullString, then simply define your own constant and use it instead of adding literal zero-length strings throughout your code. The idea is to use a constant, instead of a literal value, in order to reduce unnecessary bloat in your program.
Show quote
Hide quote
"DenBorg" <den_b***@yahoo.com> wrote in message That I agree with; and it's not being scared, just recognizing that they arenews:1120832207.614703.20460@g49g2000cwa.googlegroups.com > Bob Butler wrote: >>> Also, any place where "" *IS* needed, you should use the constant >>> "vbNullString" instead. >> >> No, you shouldn't. vbNullString is documented as being available >> for use in calling external API procedures that need to >> differentiate between "" and a null pointer; it is not documented as >> being a substitute for "". In the VB environment the implementation >> of vbNullString ends up being effectively identical to "" but they >> are not the same thing and you should not confuse the two. (It >> mattered more when there was a chance that there'd be a VB7 since >> you'd be running the risk of code not working if the implementation >> changed so it's really a moot point now.) > > I wasn't confusing the two ("" and vbNullString), but as you've > pointed out, as implemented in VB they are *effectively* the same. > > When you use the literal value "", you are introducing bloat into your > program. Each BSTR you define consumes an additional 4 bytes of > memory. Using a *constant* in its place reduces this bloat. > > So, YES, you *should* use a constant instead of having hundreds of > ""'s throughout your code. And if you are scared of using > vbNullString, then simply define your own constant and use it instead > of adding literal zero-length strings throughout your code. The idea > is to use a constant, instead of a literal value, in order to reduce > unnecessary bloat in your program. not the same and that it's incorrect to say that vbNullString is an appropriate replacement for "". IMO it isn't. -- Reply to the group so all can participate VB.Net: "Fool me once..." Bob Butler wrote:
> ... and that it's incorrect to say that vbNullString is an Well, IMHO, I would say that it would depend up on how and what it is> appropriate replacement for "". IMO it isn't. being used for, as to whether it is an appropriate replacement or not. IOW, the context would make that determination. In some situations, the difference may be critical. In other situations, the difference is completely meaningless. "DenBorg" <den_b***@yahoo.com> wrote in message Does that mean you no longer believe the original advice?news:1120832928.978156.232940@o13g2000cwo.googlegroups.com > Bob Butler wrote: >> ... and that it's incorrect to say that vbNullString is an >> appropriate replacement for "". IMO it isn't. > > Well, IMHO, I would say that it would depend up on how and what it is > being used for, as to whether it is an appropriate replacement or not. > IOW, the context would make that determination. In some situations, > the difference may be critical. In other situations, the difference is > completely meaningless. "Also, any place where "" *IS* needed, you should use the constant "vbNullString" instead." The difference is critical only in API calls. In all other cases VB6 treats the two as essentially identical but that's a side effect of the implementation and not a part of the language. That's the issue I have with it; relying on side effects is rarely a good choice in my experience. As I said before, given that VB is a dead language I know it's a moot point. -- Reply to the group so all can participate VB.Net: "Fool me once..." Bob Butler wrote:
>Does that mean you no longer believe the original advice? No, the original point / advice still stands. Reread my comment>"Also, any place where "" *IS* needed, you should use the constant >"vbNullString" instead." *carefully*, and you'll see that I said the context determines whether vbNullString is an *appropriate replacement* for "". After you reread it, you'll clearly see that I did not say that it was not appropriate to replace the literal value with a constant. IOW, the question is: "Is vbNullString an appropriate replacement for a literal zero-length string? Or would a *different replacement* be appropriate?" The context, IMO, would make that determination. Never once did I even hint that it would ever be a bad idea to replace literal zero-length strings with a constant. Even you said that relying upon side effects may be a good choice in rare occassions("... rarely a good choice ..."), though that would be the exception and not the rule. And I would agree. The question then becomes, is vbNullString an appropriate replacement for zero-length literals when API calls are not involved, since VB sees vbNullString and "" as essentially the same thing? If you think "No", then your choices are to either create your own constant and use that, or use the literal value and thus create bloat in your program. The choice is yours. FWIW, I don't see VB as a "dead language". Despite the fact that Microsoft will not be enhancing and making newer versions of VB, it will still be in use for a long time because of the thousands of existing programs. VB is no more a "dead language" than is COBOL. The cost of rewriting existing applications into a different language is most often too high to be cost effective. "DenBorg" <den_b***@yahoo.com> wrote in message OK, I didn't make note of the emphasis on *IS* (I guess it depends on whatnews:1120837766.597887.91530@g44g2000cwa.googlegroups.com > Bob Butler wrote: >> Does that mean you no longer believe the original advice? >> "Also, any place where "" *IS* needed, you should use the constant >> "vbNullString" instead." > > No, the original point / advice still stands. Reread my comment > *carefully*, and you'll see that I said the context determines whether > vbNullString is an *appropriate replacement* for "". After you reread > it, you'll clearly see that I did not say that it was not appropriate > to replace the literal value with a constant. your definition of IS is <g>) > Even you said that relying upon side effects may be a good choice in I think we can both let this go as we seem to generally agree, just have> rare occassions("... rarely a good choice ..."), though that would be > the exception and not the rule. And I would agree. different emphasis/priorities on it. > FWIW, I don't see VB as a "dead language". Despite the fact that Agreed; I meant it only in terms that it won't be changing. If new releases> Microsoft will not be enhancing and making newer versions of VB, it > will still be in use for a long time because of the thousands of > existing programs. VB is no more a "dead language" than is COBOL. The > cost of rewriting existing applications into a different language is > most often too high to be cost effective. of VB were likely then relying on side effects is riskier because you never know what version will break your code. I'm still using VB6 and will be for some time to come since I've got no clear alternative. -- Reply to the group so all can participate VB.Net: "Fool me once..." Bob Butler wrote:
>> No, the original point / advice still stands. Reread my comment I guess my original comment was not worded the best. I assumed that the>> *carefully*, and you'll see that I said the context determines whether >> vbNullString is an *appropriate replacement* for "". After you reread >> it, you'll clearly see that I did not say that it was not appropriate >> to replace the literal value with a constant. > >OK, I didn't make note of the emphasis on *IS* (I guess it depends on >what your definition of IS is <g>) context of this thread excluded calls to API routines.
Show quote
Hide quote
"DenBorg" <den_b***@yahoo.com> wrote in message LOL, which would be the only place where vbNullString is appropriate andnews:1120840772.148358.42590@g47g2000cwa.googlegroups.com > Bob Butler wrote: >>> No, the original point / advice still stands. Reread my comment >>> *carefully*, and you'll see that I said the context determines >>> whether vbNullString is an *appropriate replacement* for "". After >>> you reread it, you'll clearly see that I did not say that it was >>> not appropriate to replace the literal value with a constant. >> >> OK, I didn't make note of the emphasis on *IS* (I guess it depends on >> what your definition of IS is <g>) > > I guess my original comment was not worded the best. I assumed that > the context of this thread excluded calls to API routines. where it can not be substituted for "" so we've come full circle! <g> -- Reply to the group so all can participate VB.Net: "Fool me once..." > FWIW, I don't see VB as a "dead language". Despite the fact that The point Bob was trying to make is that relying on side effect in a> Microsoft will not be enhancing and making newer versions of VB, it > will still be in use for a long time because of the thousands of > existing programs. VB is no more a "dead language" than is COBOL. "live" language is dangerous as the relied on functionality could be changed in a future revision to the language (thus breaking your code). However, with VB now being a "dead" language (no more language changes in the future), the point is moot since the side effect is now frozen in place and, for all practical purposes, guaranteed as if it were a documented effect. Rick
Show quote
Hide quote
"Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message Yes, what he said! <g>news:%23YKBiY9gFHA.3300@TK2MSFTNGP15.phx.gbl >> FWIW, I don't see VB as a "dead language". Despite the fact that >> Microsoft will not be enhancing and making newer versions of VB, it >> will still be in use for a long time because of the thousands of >> existing programs. VB is no more a "dead language" than is COBOL. > > The point Bob was trying to make is that relying on side effect in a > "live" language is dangerous as the relied on functionality could be > changed in a future revision to the language (thus breaking your > code). However, with VB now being a "dead" language (no more language > changes in the future), the point is moot since the side effect is > now frozen in place and, for all practical purposes, guaranteed as if > it were a documented effect. "Static" would probably have been a better choice than "dead". -- Reply to the group so all can participate VB.Net: "Fool me once..." "DenBorg" <den_b***@yahoo.com> wrote in message news:1120837766.597887.91530@g44g2000cwa.googlegroups.com... The only problem here is that using "" an place of vbNullString does *NOT* result in any "Bloat." In fact, once compiled, they> > If you think "No", then your choices are to either create your own > constant and use that, or use the literal value and thus create bloat > in your program. The choice is yours. > both result in exactly the same executable. WinDiff sees no difference in the executables, other than the file date. That said, the decision comes down exclusively to one of personal preference, since it has no effect on the size or performance of the executable. -- Al Reid Al Reid wrote:
>The only problem here is that using "" an place of vbNullString That is an incorrect assumption.>does *NOT* result in any "Bloat." In fact, once compiled, they >both result in exactly the same executable. WinDiff sees no >difference in the executables, other than the file date. Create a new project, add a command button to Form1, and add the following sub: Private Sub Command1_Click() Dim S As String S = "" End Sub Copy the "S=" line so that there are 100 of them. Compile to Project1.exe Then replace all literal zero-length strings with either vbNullString or with your own constant. Compile to Project2.exe. The file size of Project1.exe and Project2.exe is different by 4K. Using literal zero-length strings does induce bloat into your program, and the decision is truly more than merely one of personal preference.
Show quote
Hide quote
"DenBorg" <den_b***@yahoo.com> wrote in message Not on my systems; the files are different but are the same size whether Inews:1120840194.504029.106230@z14g2000cwz.googlegroups.com > Al Reid wrote: >> The only problem here is that using "" an place of vbNullString >> does *NOT* result in any "Bloat." In fact, once compiled, they >> both result in exactly the same executable. WinDiff sees no >> difference in the executables, other than the file date. > > That is an incorrect assumption. > > Create a new project, add a command button to Form1, and add the > following sub: > > Private Sub Command1_Click() > Dim S As String > > S = "" > End Sub > > Copy the "S=" line so that there are 100 of them. Compile to > Project1.exe > > Then replace all literal zero-length strings with either vbNullString > or with your own constant. Compile to Project2.exe. > > The file size of Project1.exe and Project2.exe is different by 4K. use vbNullString, my onw constant or "". I used native code optimized for small code size with VB6 SP5. -- Reply to the group so all can participate VB.Net: "Fool me once..."
Show quote
Hide quote
"Bob Butler" <tiredofit@nospam.com> wrote in message news:OtmQky9gFHA.2700@TK2MSFTNGP15.phx.gbl... I just tried DenBorg's example and concur with your findings. No difference at all between "" and vbNullString.> "DenBorg" <den_b***@yahoo.com> wrote in message > news:1120840194.504029.106230@z14g2000cwz.googlegroups.com > > Al Reid wrote: > >> The only problem here is that using "" an place of vbNullString > >> does *NOT* result in any "Bloat." In fact, once compiled, they > >> both result in exactly the same executable. WinDiff sees no > >> difference in the executables, other than the file date. > > > > That is an incorrect assumption. > > > > Create a new project, add a command button to Form1, and add the > > following sub: > > > > Private Sub Command1_Click() > > Dim S As String > > > > S = "" > > End Sub > > > > Copy the "S=" line so that there are 100 of them. Compile to > > Project1.exe > > > > Then replace all literal zero-length strings with either vbNullString > > or with your own constant. Compile to Project2.exe. > > > > The file size of Project1.exe and Project2.exe is different by 4K. > > Not on my systems; the files are different but are the same size whether I > use vbNullString, my onw constant or "". I used native code optimized for > small code size with VB6 SP5. > > -- > Reply to the group so all can participate > VB.Net: "Fool me once..." > -- Al Reid
Show quote
Hide quote
> >> The only problem here is that using "" an place of vbNullString Are they the same number of physical bytes? Or are you just looking at> >> does *NOT* result in any "Bloat." In fact, once compiled, they > >> both result in exactly the same executable. WinDiff sees no > >> difference in the executables, other than the file date. > > > > That is an incorrect assumption. > > > > Create a new project, add a command button to Form1, and add the > > following sub: > > > > Private Sub Command1_Click() > > Dim S As String > > > > S = "" > > End Sub > > > > Copy the "S=" line so that there are 100 of them. Compile to > > Project1.exe > > > > Then replace all literal zero-length strings with either vbNullString > > or with your own constant. Compile to Project2.exe. > > > > The file size of Project1.exe and Project2.exe is different by 4K. > > Not on my systems; the files are different but are the same size whether I > use vbNullString, my onw constant or "". I used native code optimized for > small code size with VB6 SP5. the sector size that Windows Explorer reports? It seems that DenBorg's 4K difference is a sector size difference leading me to believe that the physical byte size of the files is, in fact, different. With that said... Who cares! The difference, if there really is one, under any or all compile conditions, has got to be so small as to be meaningless given the size of RAM and hard disks on current systems. Seems to me that it is time for this thread to end, no? Rick
Show quote
Hide quote
"Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message news:%23Qb9%2359gFHA.2456@TK2MSFTNGP10.phx.gbl... Rick,> > >> The only problem here is that using "" an place of vbNullString > > >> does *NOT* result in any "Bloat." In fact, once compiled, they > > >> both result in exactly the same executable. WinDiff sees no > > >> difference in the executables, other than the file date. > > > > > > That is an incorrect assumption. > > > > > > Create a new project, add a command button to Form1, and add the > > > following sub: > > > > > > Private Sub Command1_Click() > > > Dim S As String > > > > > > S = "" > > > End Sub > > > > > > Copy the "S=" line so that there are 100 of them. Compile to > > > Project1.exe > > > > > > Then replace all literal zero-length strings with either > vbNullString > > > or with your own constant. Compile to Project2.exe. > > > > > > The file size of Project1.exe and Project2.exe is different by 4K. > > > > Not on my systems; the files are different but are the same size > whether I > > use vbNullString, my onw constant or "". I used native code optimized > for > > small code size with VB6 SP5. > > Are they the same number of physical bytes? Or are you just looking at > the sector size that Windows Explorer reports? It seems that DenBorg's > 4K difference is a sector size difference leading me to believe that the > physical byte size of the files is, in fact, different. > > With that said... Who cares! > > The difference, if there really is one, under any or all compile > conditions, has got to be so small as to be meaningless given the size > of RAM and hard disks on current systems. Seems to me that it is time > for this thread to end, no? > > Rick > > In my case, I used WinDiff to compare the files AND went as far as running a disassembler and comparing the code visually. They are identical. In the case of a boolean compare (a = "")' vs. (a = vbNullString) they both compare a to "0". So as far as I can see, the compiler optimizes them both to the same machine code. -- Al Reid On Fri, 8 Jul 2005 13:07:54 -0400, "Al Reid"
<arei***@reidDASHhome.com> wrote: <snip> >In my case, I used WinDiff to compare the files AND went as far as running a disassembler and comparing the code visually. They are I did some tests on this a few months ago>identical. > >In the case of a boolean compare (a = "")' vs. (a = vbNullString) they both compare a to "0". > >So as far as I can see, the compiler optimizes them both to the same machine code. The results were a bit spooky An unititialized string - just Dimmed - is a vbNullString set it to "" and it is different Use VarPtr and StrPtr to check that Personally I would suggest that one does not use vbNullString unless one is acutely aware of what one is doing. "J French" <erew***@nowhere.uk> wrote in message It's better to use "If Len(myString) = 0" anyway, it is many orders of news:42cfbd03.101814325@news.btopenworld.com... > Personally I would suggest that one does not use vbNullString unless > one is acutely aware of what one is doing. magnitude faster. If you do "If myString = vbNullString" or "If myString = """ you are asking vb to do a byte by byte comparison of the string when all you need to do is check the length, which is stored right at the start of the string. Michael "Michael C" <mculley@NOSPAMoptushome.com.au> wrote in message Better, yes. Is it "many orders of magnitude faster"? I don't know about news:%23$JeqWahFHA.2372@TK2MSFTNGP14.phx.gbl... > "J French" <erew***@nowhere.uk> wrote in message > news:42cfbd03.101814325@news.btopenworld.com... >> Personally I would suggest that one does not use vbNullString unless >> one is acutely aware of what one is doing. > > It's better to use "If Len(myString) = 0" anyway, it is many orders of > magnitude faster. that. > If you do "If myString = vbNullString" or "If myString = """ you are Yes, but is that "many orders of magnitude faster"? Not hardly. It's > asking vb to do a byte by byte comparison of the string when all you need > to do is check the length, which is stored right at the start of the > string. definately more efficient to just check the length of the string, and as a rule, that's what you should do to determine if a string is 0-length. But unless you're doing this in a loop of many iterations, you're not likely to notice any perceivable difference in performance (possibly a small measureable difference, but it's perceivable difference that really matters). Personally, I just find it more self-documenting to check the length of the string against 0 than to compare the string to "". That's the main reason why I use that syntax. -- Mike Microsoft MVP Visual Basic MikeD wrote:
> "Michael C" <mculley@NOSPAMoptushome.com.au> wrote Here's what I got on my 1 GHz, VB6, Win98SE:>>"J French" <erew***@nowhere.uk> wrote >>>Personally I would suggest that one does not use vbNullString unless >>>one is acutely aware of what one is doing. >>It's better to use "If Len(myString) = 0" anyway, it is many orders of >>magnitude faster. > > Better, yes. Is it "many orders of magnitude faster"? I don't know about > that. Private Sub Command2_Click() Dim n As Long, t1 As Single, s1 As String s1 = "hello world" t1 = Timer For n = 1 To 10000000 If Len(s1) = 0 Then 'do nothing End If Next n MsgBox Timer - t1 'rough averages after 6 runs 'ide 1.38 'pcode .75 'native code, ' - fast code, ' - all optimizations .11 End Sub Private Sub Command3_Click() Dim n As Long, t1 As Single, s1 As String s1 = "hello world" t1 = Timer For n = 1 To 10000000 If s1 = vbNullString Then 'do nothing End If Next n MsgBox Timer - t1 'rough averages after 6 runs 'ide 1.87 'pcode 1.15 'native code, ' - fast code, ' - all optimizations .55 End Sub Mike "mscir" <ms***@yahoo.com> wrote in message Your test appear to not be completely accurate. I got 4697ms compared to news:H8adndjmrauhI0zfRVn-vg@pghconnect.com... > Here's what I got on my 1 GHz, VB6, Win98SE: 1082ms when compiled. Not as big a difference as I though but still a fairly big difference. Option Explicit Private Declare Function GetTickCount Lib "kernel32" () As Long Private Sub Form_Load() Dim t As Long Dim x As Long Dim y As String y = "Hello world" t = GetTickCount For x = 1 To 100000000 If y = "" Then MsgBox "Y" End If Next MsgBox GetTickCount - t t = GetTickCount For x = 1 To 100000000 If Len(y) = 0 Then MsgBox "Y" End If Next MsgBox GetTickCount - t End Sub "A P" <a*@textguru.ph> wrote in message While you can use the StrPtr hack to test the return your best option isnews:uMEmBB1gFHA.1248@TK2MSFTNGP12.phx.gbl > Hi! > > I want to control my input not to accept null or no value upon > clicking OK button. Since Inputbox function accepts input, I use it > but upon clicking Cancel button, the msgbox error also appear. I have > attached my script for you to check out. > > Private Sub cmdAdd_Click() > strInput = Trim(InputBox("Enter Name: ", "Append Name")) > If strInput = "" Then > MsgBox ("Null not allowed... Please try again"), vbCritical, really to use your own form to handle the input rather than the hokey InputBox function -- Reply to the group so all can participate VB.Net: "Fool me once..."
Show quote
Hide quote
"A P" <a*@textguru.ph> wrote in message Is this really worthy of a vbCritical?news:uMEmBB1gFHA.1248@TK2MSFTNGP12.phx.gbl... > Hi! > > I want to control my input not to accept null or no value upon clicking OK > button. Since Inputbox function accepts input, I use it but upon clicking > Cancel button, the msgbox error also appear. I have attached my script for > you to check out. > > Private Sub cmdAdd_Click() > strInput = Trim(InputBox("Enter Name: ", "Append Name")) > If strInput = "" Then > MsgBox ("Null not allowed... Please try again"), vbCritical, "Error > Message" > Else Michael "A P" <a*@textguru.ph> wrote in message [Hoshi Patricia Friedman] I have that problem, too. Wish I could help you.news:uMEmBB1gFHA.1248@TK2MSFTNGP12.phx.gbl... > I want to control my input not to accept null or no value upon clicking OK > button. Since Inputbox function accepts input, I use it but upon clicking > Cancel button, the msgbox error also appear. I have attached my script for > you to check out. "A P" <a*@textguru.ph> wrote in message You want it to continually ask until the users enter valid data? This may news:uMEmBB1gFHA.1248@TK2MSFTNGP12.phx.gbl... > Hi! > > I want to control my input not to accept null or no value upon clicking OK > button. Since Inputbox function accepts input, I use it but upon clicking > Cancel button, the msgbox error also appear. I have attached my script for > you to check out. drive people a bit nutty so use at your own risk <g> '========= Private Sub Command1_Click() Dim sStr As String Do sStr = Trim$(InputBox("Enter some stuff")) If Len(sStr) = 0 Then MsgBox "Try again" End If Loop While Len(sStr) = 0 End Sub '========= Also note that this advice.... > > strInput = Trim(InputBox("Enter Name: ", "Append Name")) Will make zero difference. You can use Trim or Trim$ and still check the > Use Trim$ length of strings. -- Ken Halter - MS-MVP-VB - http://www.vbsight.com DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Please keep all discussions in the groups..
Show quote
Hide quote
> > I want to control my input not to accept null or no value upon I don't know why, but I kind of prefer having the anticipated codeclicking OK > > button. Since Inputbox function accepts input, I use it but upon clicking > > Cancel button, the msgbox error also appear. I have attached my script for > > you to check out. > > You want it to continually ask until the users enter valid data? This may > drive people a bit nutty so use at your own risk <g> > '========= > Private Sub Command1_Click() > Dim sStr As String > > Do > sStr = Trim$(InputBox("Enter some stuff")) > If Len(sStr) = 0 Then > MsgBox "Try again" > End If > Loop While Len(sStr) = 0 > > End Sub > '========= executed first and use the loop as my "error trap" if you will. Something like this... Dim sStr As String sStr = Trim$(InputBox("Enter Name: ")) Do Until LenB(sStr) sStr = Trim$(InputBox("Enter Name (NOT A BLANK): ")) Loop > Also note that this advice.... True... but I would still use the $-sign version of String functions> > > > strInput = Trim(InputBox("Enter Name: ", "Append Name")) > > Use Trim$ > > Will make zero difference. You can use Trim or Trim$ and still > check the length of strings. when assigning text returned from them to String variables. Obviously, the difference is miniscule; but still, as long as the difference exists, I consider it better to have the $-sign version of a String function return a String value directly into a String variable as opposed to having the non-$-sign version of these functions return a Variant with a sub-type of String for this same type of assignment. Rick "Rick Rothstein" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message Then you've introduced repeat code. Ken's method called InputBox only once. news:%23nAkI%238gFHA.3540@TK2MSFTNGP14.phx.gbl... > I don't know why, but I kind of prefer having the anticipated code > executed first and use the loop as my "error trap" if you will. > Something like this... > > Dim sStr As String > sStr = Trim$(InputBox("Enter Name: ")) > Do Until LenB(sStr) > sStr = Trim$(InputBox("Enter Name (NOT A BLANK): ")) > Loop If you wanted to change anything about the inputbox line you'd have to know to maintain it in 2 locations, which is not good. Michael
Show quote
Hide quote
> > I don't know why, but I kind of prefer having the anticipated code I know... old (real old) habits die hard.> > executed first and use the loop as my "error trap" if you will. > > Something like this... > > > > Dim sStr As String > > sStr = Trim$(InputBox("Enter Name: ")) > > Do Until LenB(sStr) > > sStr = Trim$(InputBox("Enter Name (NOT A BLANK): ")) > > Loop > > Then you've introduced repeat code. Ken's method called InputBox only once. > If you wanted to change anything about the inputbox line you'd have to know > to maintain it in 2 locations, which is not good. Rick 
Other interesting topics
VB6 app crashes on XP
Subclassing Help Write Read to memory. Find Directory VB, SQL & Word Listview - Performance fine except when adding first item voice key - raising a "flag" when a voice input is recoeved. New and annoying error message compare value from DTPicker and now() Code for time limiting a demonstration program |
|||||||||||||||||||||||
