Null String Problem

I have a string that is loaded from a collection that is inturn loaded from a fixed length file. Sometimes the string is null, and when I use an IF statement to test this condition I get unexpected results. In the file, the string exists as a field of 15 spaces, sometimes blank sometimes not. When loading into my collection I use the trim() function to remove the spaces (or atleast I thought).

Here's the weird part, when I reference (display the value) of the string it will show a null value "". But if I use the Len() function, it returns a 15. and blows right through my IF statement when testing for null. I've even tried assigning it out to another var, and it tests the same way.

Code:

---

                If Trim(WlNum) = "" Then
                    WlNum = "(None)"
                Else
                    WlNum = item.WellNum
                End If

---

Even when WlNum is = "" it blows right through to ELSE.

A space is a valid character. Therefore, if something contains a space, it is not null. Regardless of what it "looks" like to you, the computer sees a valid, non null, character. Try this

Code:

---

                If WlNum = Space(15) Or WlNum = String.Empty Then
                    WlNum = "(None)"
                Else
                    WlNum = item.WellNum
                End If

---

Thanks for your solution, but why does a trim statement remove spaces that are surrounding a string but does not nullify a string that only contains spaces?

<Later>

It's still blowing through, even Hack's version doesn't make it work, something strange is going on and I'm not sure what it is. I'll keep you all updated.
I've even moved the code to the Class Property and used it as a validator, still no results.

Code:

---

With NewMG
    '...
  .WellNum = InputLine.Substring(112, 15)   
    '...
End With


' From Immediate Win

? Len(NewMG.WellNum)
15
? NewMG.WellNum
""

---

It appears that a "" with a len of 15 comes right out of the file, and no matter how I try to trap the null, I'm unsuccessful.

Is it a function of not writing a null to this particular file type that's giving me my problem, I guess I could write a routine that puts values in those file fields but It probably would not detect the nulls either. I probably could use the len() to locate the nulls, but at this point i'm amazed that none of the above works, and I'd really love to know why?

I think the problem has stemed from an earlier file type. This file used to be a random access file and was converted to a filestream. I think somewhere along the line, something happened to the null fields. So today I'm going to loop through the file and rewrite all the null fields. The following code is the only thing I've found that will trap the nulls.

Code:

---

Public Property WellNum() As String
        Get
            Return _WellNum
        End Get
        Set(ByVal value As String)
            If Len(value) = 15 Or Len(value) = 0 Then
                value = "(None)"
            End If
            _WellNum = value
        End Set
    End Property

---

To solve this problem I loaded the suspect fields into a datagrid, at that point the null fileds displayed as "IIIIIIIII" (not I's, but a cluster of small vertical lines) It resembled a mini barcode. All null fields displayed these characters and at that point I knew what needed fixed.

If you get strange characters in the grid, it means that the string contains non displayable characters, such as 8, which is a Basckspace.

Some applications display those characters as bars (the Grid), others as little squares, other disregard them (the debugger). Trim does not remove them because they could be used for some purpose or to display special characters in particular environments.

Those caracters could have appeared there for many reasons. Two common ones is data imported from a mainframe or from a file in another language than English. These sometimes do not use the standard ASCII (search the Internet for "ASCII code page" if you are curious), and some caracters are not translated correctly when converted to Unicode, which is the standard used in modern systems, including Windows and .NET.

You might want to trap one of those "null" fields and see what you get as the first character with Asc(yourString.Substring(0, 1)). Assuming that all your nulls are the same format, you could thus identify them through the ASCII value of their first character.

Try not to use nulls in any of your work. They often lead to strange problems. An empty string is as valid as a marker as a null, and usually does not bring those conflicts.

Thanks, I met similar problem in my java bar code and it is solved now. Now I would not consider space as null.