Calculate size of string in bytes

Calculate size of string in bytes

• Neology

  I've played a bit with this - it seems that if you use a streamreader it will buffer data from the underlying stream so it's position doesn't represent the line you're currently reading, so no luck here.

  Random thought, though: How big is this file likely to be If you know it to not be too big, and most of the time is spent processing what you do with each line, why not read the entire file, break it into lines, and base the progress bar on the number of lines you've processed vs the total number of lines

  Dim tfs As New IO.StreamReader(fs)
  dim lines() as string = tfs.ReadToEnd().Split(vbNewLine)

  
  
  

• anjee

  Richard_Wolf wrote:

  For line sequential ASCII files, shouldn't it be your input string.length + 2 (CrLf ends each line). And isn't there a system property you can read to determine if the OS is using DBCS or not If so then it's relatively easy to assume that the length is (string.length * 2) + 2, correct

  DBCS is more tricky to work out than that. The way DBCS works is if the first value is above 0x80 then a second byte is added. So mostly English text would only have one byte per character.

  
  
  

• dnaman

  For line sequential ASCII files, shouldn't it be your input string.length + 2 (CrLf ends each line). And isn't there a system property you can read to determine if the OS is using DBCS or not If so then it's relatively easy to assume that the length is (string.length * 2) + 2, correct

  And Andreas had a good point about updating your display. Something simple, such as counting the number of lines you've read in, then:

  If LinesRead Mod 100 = 0 Then
  'update progress bar
  Application.DoEvents()
  End If

  can really improve the performance on lengthy files. If all of your files are going to be short then it doesn't really matter.

  
  

• bsh

  That's why I used 'assume'

  This would be a good class for someone with more .NET knowledge than myself to come up with. And assuming (again) that he's using a SreamReader.ReadLine doesn't it define a line as CrLf or will it stop at a lone CR and/or lone LF

  
  

• aztecpride

  Guys, The following snippet works but is not an exact science, but near enough for the job
  
  Cheers Guys,
  
  
  
  Dim FileSizeBytes As Long = 0, BytesUploaded As Long = 0, RowCounter As Integer = 0, RowString As String = "", RowArray() As String, i As Integer = 0, FileStream As StreamReader
  
  
  Try
  UpdateList("Finding file....")
  If Dir(FilePath) <> "" Then
  FileSizeBytes = My.Computer.FileSystem.GetFileInfo(FilePath).Length
  
  Me.txtUpload.Text = FilePath
  Me.txtFilename.Text = My.Computer.FileSystem.GetFileInfo(FilePath).Name
  Me.txtSize.Text = FileSizeBytes
  
  UpdateList("Opening file....")
  FileStream = File.OpenText(FilePath)
  
  Try
  Dim ascii As New System.Text.ASCIIEncoding()
  
  Me.ProgressImport.Visible = True
  
  Do While Not FileStream.EndOfStream
  RowCounter += 1
  RowString = FileStream.ReadLine()
  RowArray = Split(RowString, ",")
  
  BytesUploaded += ascii.GetByteCount(RowString)
  
  Me.ProgressImport.Value = CInt((BytesUploaded / FileSizeBytes) * 100)
  Me.ProgressImport.Refresh()
  Me.lblRowCount.Text = BytesUploaded & " bytes of " & FileSizeBytes & " bytes uploaded "
  Me.lblRowCount.Refresh()
  Loop
  
  'Execute loader upload to database
  finally
  
  end try
  
  

• Madhukar_KR

  Here is how I was thinking.

  You do not really know if the textfile was created with CR, LF or CRLF as linebreak. Counting only 1 byte as linebreak will keep you from overflowing the max value of a progressbar if it is set to the byte length of the textfile.

  
  
  

• Sameer Khan

  Determining the size of a file is easy. If you for example have opened a FileStream, check its Length property.

  The second part is more tricky. It depends on the encoding used for the strings in the file and what kind of newline characters are used.

  
  
  

• skidoo

  You could do an approximation. If your textfile contains ascii you can count String.Length + 1 as the size read.

  This might result in that your progress bar is at 90% or so when it is actually finished. If the textfile is unicode it will probably be even less like 50% when finished. I do not think the users mind that it completes 50% in no time compared to the first 50% but they will not be able to rely on the indication the progress bar gives.

  As Mattias mentions, it is complex to calculate the exact size of each line and you should not spend time on that when you have other processing to do.

  Maybe it is enough to display the number of lines that has been read This will give the user an indication that your application is working and making progress.

  Also consider to not update the interface for every line that is processed if there are many lines processed relativly fast, several per second. This will be bad for you performance as your controls and forms will need updating and consuming power that your process need for real work.

  
  
  
• Calculate size of string in bytes