I'm trying to write the return statement of my function like this
Return (Not IsDbNull(result)) And (CType(result, String) = "1")
However, when result is DbNull, it throws me an InvalidCastException
Writing (Not IsDbNull(result)) And 2/0 = 1 in my watch works so it seems to me like the CType function has something special that makes it be evaluated before the rest of expression.
am I seeing things or CType doesn't respect the evaluation order in VB.NET? Is there a way around this problem that doesn't involve splitting my expression into several parts and assigning them into variables?
You should almost always use AndAlso instead of And (and OrElse instead of Or).
A logical operation is said to be short-circuiting if the compiled
code can bypass the evaluation of one expression depending on the
result of another expression. If the result of the first expression
evaluated determines the final result of the operation, there is no
need to evaluate the second expression
And on the other hand will evaluate both expression which causes this exception:
In a Boolean comparison, the And operator always evaluates both
expressions
You could also use Convert.ToString that treats Nothing or DbNull as empty string:
Return Convert.ToString(result) = "1"
In your case - converting to string - you don't need DbNull checking and converting to string.
Code below will be enough.
Return result.ToString().Equals("1")
Because DbNull.ToString() returns empty string.
In case result returned by ExecuteScalar - where Nothing(null) value is possible, as pointed out by Tim Schmelter, you can add validation for null
Dim checkedResult = If(result, String.Empty)
Return checkedResult.ToString().Equals("1")
Or use static Object.Equals method
Return Equals(result, "1")
If result is item of DataRow type then suggest using extension method for converting values to the proper type
Dim value As Integer = datarow.Field(Of Integer)("IntegerColumnName")
Dim value As String = datarow.Field(Of String)("StringColumnName")
DataRow will return empty string if value is DbNull
Related
Question: Can I assume that Str(myString) will always return the same result as Str(CDbl(myString)) (assuming that myString is statically typed as a string)?
Context:
I am trying to understand VBA's implicit conversions. So far, it appears to me that Str(myString)
implicitly parses myString into a double (culture-sensitive) and then
converts the result into a culture-insensitive string.
For example, using a German locale (i.e. using , as the decimal separator), it holds that
" 1.2" = Str(1.2) = Str("1,2") = Str(CDbl("1,2"))
Since these implicit conversions contain a lot of "magic" to me, I am trying to rewrite a procedure that uses an implicit conversion (Str(myString)) to one using explicit conversion without changing the behavior.
Unfortunately, the documentation is wrong and, thus, useless. (The documentation claims that the argument to Str is interpreted as a Long, which is obviously rubbish: If that were the case Str(1.2) could never yield " 1.2".)
Your statement is true. Str(x) and Str(Cdbl(x)) give identical result provided that x is String data type and contains a valid number.
I made a small test to get convinced.
I used Excel, but it holds the same with Access.
Public Function myStr(txt As String) As String
myStr = Str(txt)
End Function
Public Function myStrCDbl(txt As String) As String
myStrCDbl = Str(CDbl(txt))
End Function
I tried with some key values (0, 1.2, 1E+307, 1E-307, ...) : result of myStr and myStrCDbl are always identical.
I also agree with you that the documentation is wrong. If Str() argument would be interpreted as Long, then Str(1.2) would give "1", because Long is an integer type.
In the mean time, I've found the VBA language specification and can confirm that the spec also answers the question with "yes":
CDbl, when receiving a string, performs a Let-coercion to Double:
If the value of Expression is not an Error data value return the Double data value that is the result of Expression being Let-coerced to Double.
Str, when receiving a string, first performs a Let-coercion to Double and then applies Str:
[If Number is a String,] the returned value is the result of the Str function applied to the result of Let-coercing Number to Double.
I've got the following LINQ Statement:
Dim PSNum As Integer = 66
Dim InvSeq = (From invRecord In InvSeqDataSet.RptInvSeqDT.AsQueryable() _
Where IIf(invRecord.IsPack_NumNull(), False, invRecord.Pack_Num = PSNum) _
Select New With _
{.Inv = invRecord.Invoice_Num, .Seq = invRecord.Inv_Seq}).FirstOrDefault()
invRecord.Pack_Num is a field of type Integer. This means that when I try to access it, if it is DBNull I get a StronglyTypedException. The above code throws this exception. If, however, I remove the "invRecord.Pack_Num = PSNum" and in its place put something like "True", the code works fine.
So I guess my question is, why is that that invRecord.IsPack_NumNull() returns False when the value is in fact DBNull and what can I use as a conditional instead? I've been beating my head against the wall for a while now and I can't find a solution to this problem.
In VB.NET, IIf() evaluates every one of its arguments since it's a function, not a language statement. So inv.Record.Pack_Num = PSNum will always be evaluated.
You can use If() instead of IIf() (same syntax) which uses short-circuiting evaluation so everything will work as expected.
On a side node, be careful with And and Or which have the same behavior. Use AndAlso and OrElse instead if you need short-circuiting evaluation.
I want to run a check on a String right before I append it to a StringBuilder to make sure only numeric characters are in the string. What's a simple way to do that?
Use Integer.TryParse() it will return true if there are only digits in the string. Int32 max value is 2,147,483,647 so if your value is less then that then your fine.
http://msdn.microsoft.com/en-us/library/f02979c7.aspx
You can also use Double.TryParse() which has a max value of 1.7976931348623157E+308 but it will allow a decimal point.
If your looking to get the value that isnt an integer you can always go through the string one at a time
string test = "1112003212g1232";
int result;
bool append=true;
for (int i = 0; i < test.Length-1; i++)
{
if(!Int32.TryParse(test.Substring(i,i+1),out result))
{
//Not an integer
append = false;
}
}
If append stays true then the string is an integer. Probably a more slick way of doing this but this should work.
Coding in VB.Net to check whether a string contains only numeric values or not.
If IsNumeric("your_text") Then
MessageBox.Show("yes")
Else
MessageBox.Show("no")
End If
Use regular expressions:
Dim reg as New RegEx("^\d$")
If reg.IsMatch(myStringToTest) Then
' Numeric
Else
' Not
End If
UPDATE:
You could also use linq to accomplish the same task if you're doing it in VB.Net 2008/2010.
Dim isNumeric as Boolean = False
Dim stringQuery = From c In myStringToTest
Where Char.IsDigit(c)
Select c
If stringQuery.Count <> myStringToTest.Length Then isNumeric = False
If you do not wish to use RegEx, a simple check on each character with char.IsNumber works.
You can combine it with the All extension method (in C#, I don't know how to write it in VB.net):
string value = "78645655";
bool isValid = value.All(char.IsNumber);
Check out other char method, like IsDigit.
2 other compact solutions :
Without LINQ :
Dim foo As String = "10004"
Array.Exists(foo.ToCharArray, Function(c As Char) Not Char.IsNumber(c))
With LINQ (just VB.Net equivalent of the C# version in another answer) :
foo.All(Function(c As Char) Char.IsNumber(c))
Negative values haven't been mentioned, which Integer.TryParse would accept.
I prefer UInteger.TryParse which will reject a negative number. However, there is an additional check required in case the value starts with "+":
Dim test As String = "1444"
Dim outTest As UInteger
If Not test.StartsWith("+") AndAlso UInteger.TryParse(test, outTest) Then
MessageBox.Show("It's just digits!")
End If
or ULong.TryParse for a larger number.
Pattern matching! See this, this (about.com) and this (VB.NET dev article).
You can use regular expression or Integer.TryParse and I prefer the regular expression check
Presuming you're looking at relatively short strings which will never have a number greater than the Max Int32 value, use Gage's solution. If it's a variable length and sometimes you could overflow, use Regex (System.Text.RegularExpressions)
The regex for checking against just numbers is fairly routine: ^[0-9]+$
Check here for a very good explanation of Regex.
Is there a better way of testing if a string can be converted to an integer other than something like the following?
Public Function IsInt(ByVal value As Object) As Boolean
Try
Dim temp As Integer = CInt(value)
Return True
Catch ex As Exception
Return False
End Try
End Function
by "better" I mean less verbose and/or w/o an exception.
TryParse would be the way to go, but I'm using the compact framework 2.0 and tryparse doesn't seem to be implemented....
Thanks anyways.
It seems that MarkJ is correct and the above seems to be functionally the same as IsNumeric, so I suppose that's my answer. I don't know why I thought CInt was more strict than IsNumeric. I guess it's better to test using CInt verses IsNumeric since that's the function I'm using to do the conversion?
You can use the built in IsNumeric Function
Dim CanConvert as Boolean = IsNumeric(value)
http://msdn.microsoft.com/en-us/library/6cd3f6w1(VS.71).aspx
Since TryParse isn't supported on the Compact Framework, regex is your next best option.
The first example doesn't allow decimals. The second one does.
Regex.IsMatch(value, "^-?\d+$")
Regex.IsMatch(value, "^-?\d+(?:\.\d+)?$")
If you need to allow for scientific notation, you need to tweak it a little more. It really just isn't that bad. You've got the beginning of the string ^, an optional dash -?, one or more digits \d+, a non-capturing group (?:) that looks for a single decimal point \. and one or more digits \d+. Another ? to allow either zero or one instances of the non-capturing group, and then the end of the string $.
Edit:
One thing I didn't think about before: this method is a little imprecise because you could get a really huge number that is numerically a valid integer but can't be converted to an Int32. If that's a possibility, you could constrain the number of characters. Instead of \d+, you could do \d{1,8}, for example.
Public Function IsInt(ByVal value As Object) As Boolean
Dim i As Integer
Return Integer.TryParse(Convert.ToString(value), i)
End Function
you can use Integer.TryParse, which will return a bool indicating whether the conversion was successfull or not
well if you want to avoid using exceptions you could match it against a regular expression that allows only digit characters before converting.
If you're only performing the conversion infrequently, what you have is fine (assuming there's no TryParse() available to you) - it's not going to affect performance.
If you're going to perform millions of conversions, and a large number of them might fail then the exception you're catching could be a perf issue (maybe).
If you can't use TryParse() probably the best thing to do (perf-wise) is to simply check each character in the string and if it's not a digit return false. Don't forget to account for a possible negative sign and group separators (if you want to support them).
Otherwise, parse the string to an int, which will succeed in 99% of the cases. you'll only get an exception if it won't fit. If you really want to avoid the exception that Parse() might generate, it's not hard to actually parse the sting of digits yourself, and return failure if it goes out of range.
Jon Skeet did a quick analysis of this back before the Framework contained TryParse():
Checking if a string can be converted to Int32
None of this fixes the verbosity, though. but as long as it's a self-contained method, there's no real problem with a little verbosity.
Dim s as String = "23"
Dim i as Integer
If Int32.TryParse(s, i) Then
' String was a valid integer... '
End If
Use the TryParse shared method of the Integer type.
For example:
Private Function CanStringBeCastAsInteger(ByVal myString As String) As Boolean
Dim myInt As Integer = 0
Return Integer.TryParse(myString, myInt)
End Function
The benefit of using the TryParse method is that it avoids having to throw and subsequently catch an Exception when the cast fails. Throwing and catching exceptions is an expensive operation.
Not only will the TryParse method return a True/False result, telling you if the conversion will succeed or not, it will also return, in the myInt parameter in my example, the resulting conversion for you, all in one line of code.
Here is something very similar to what you have already but uses the Convert class instead of CType and does not use TryParse
Public Function IsInt(ByVal value As Object) As Boolean
Try
Convert.ToInt32(value)
Return True
Catch ex As System.FormatException
Return False
End Try
End Function
You'd need to roll your own regex e.x.: Regex.IsMatch("4354354", "\d+"), and still include the try/catch block as a backup.
Do as follow
If myString <> "" And IsNumeric(myString) = True Then
If CDbl(myString) - Int(CDbl(myString)) > 0 Then
.... myString is integer
End If
End If
In Visual Basic, is there a performance difference when using the IIf function instead of the If statement?
VB has the following If statement which the question refers to, I think:
' Usage 1
Dim result = If(a > 5, "World", "Hello")
' Usage 2
Dim foo = If(result, "Alternative")
The first is basically C#'s ternary conditional operator and the second is its coalesce operator (return result unless it’s Nothing, in which case return "Alternative"). If has thus replaced IIf and the latter is obsolete.
Like in C#, VB's conditional If operator short-circuits, so you can now safely write the following, which is not possible using the IIf function:
Dim len = If(text Is Nothing, 0, text.Length)
IIf() runs both the true and false code. For simple things like numeric assignment, this isn't a big deal. But for code that requires any sort of processing, you're wasting cycles running the condition that doesn't match, and possibly causing side effects.
Code illustration:
Module Module1
Sub Main()
Dim test As Boolean = False
Dim result As String = IIf(test, Foo(), Bar())
End Sub
Public Function Foo() As String
Console.WriteLine("Foo!")
Return "Foo"
End Function
Public Function Bar() As String
Console.WriteLine("Bar!")
Return "Bar"
End Function
End Module
Outputs:
Foo!
Bar!
Also, another big issue with the IIf is that it will actually call any functions that are in the arguments [1], so if you have a situation like the following:
string results = IIf(Not oraData.IsDBNull(ndx), oraData.GetString(ndx), string.Empty)
It will actually throw an exception, which is not how most people think the function works the first time that they see it. This can also lead to some very hard to fix bugs in an application as well.
[1] IIf Function - http://msdn.microsoft.com/en-us/library/27ydhh0d(VS.71).aspx
According to this guy, IIf can take up to 6x as long as If/Then. YMMV.
Better use If instead of IIf to use the type inference mechanism correctly (Option Infer On)
In this example, Keywords is recognized as a string when I use If :
Dim Keywords = If(String.IsNullOrEmpty(SelectedKeywords), "N/A", SelectedKeywords)
Otherwise, it is recognized as an Object :
Dim Keywords = IIf(String.IsNullOrEmpty(SelectedKeywords), "N/A", SelectedKeywords)
On top of that, readability should probably be more highly preferred than performance in this case. Even if IIF was more efficient, it's just plain less readable to the target audience (I assume if you're working in Visual Basic, you want other programmers to be able to read your code easily, which is VB's biggest boon... and which is lost with concepts like IIF in my opinion).
Also, "IIF is a function, versus IF being part of the languages' syntax"... which implies to me that, indeed, If would be faster... if for nothing else than that the If statement can be boiled down directly to a small set of opcodes rather than having to go to another space in memory to perform the logic found in said function. It's a trite difference, perhaps, but worth noting.
I believe that the main difference between If and IIf is:
If(test [boolean], statement1, statement2)
it means that according to the test value either satement1 or statement2 will executed
(just one statement will execute)
Dim obj = IIF(test [boolean] , statement1, statement2)
it means that the both statements will execute but according to test value one of them will return a value to (obj).
so if one of the statements will throw an exception it will throw it in (IIf) anyway but in (If) it will throw it just in case the condition will return its value.
...as to why it can take as long as 6x, quoth the wiki:
Because IIf is a library function, it
will always require the overhead of a
function call, whereas a conditional
operator will more likely produce
inline code.
Essentially IIf is the equivalent of a ternary operator in C++/C#, so it gives you some nice 1 line if/else type statements if you'd like it to. You can also give it a function to evaluate if you desire.
Those functions are different! Perhaps you only need to use IF statement.
IIF will always be slower, because it will do both functions plus it will do standard IF statement.
If you are wondering why there is IIF function, maybe this will be explanation:
Sub main()
counter = 0
bln = True
s = iif(bln, f1, f2)
End Sub
Function f1 As String
counter = counter + 1
Return "YES"
End Function
Function f2 As String
counter = counter + 1
Return "NO"
End Function
So the counter will be 2 after this, but s will be "YES" only. I know this counter stuff is useless, but sometimes there are functions that you will need both to run, doesn't matter if IF is true or false, and just assign value from one of them to your variable.