4 Replies - 508 Views - Last Post: 27 August 2018 - 06:05 AM

#1 Sheepings   User is offline

  • D.I.C Lover
  • member icon

Reputation: 224
  • View blog
  • Posts: 1,260
  • Joined: 05-December 13

ElementAt<> Always One Behind

Posted 26 August 2018 - 01:18 PM

Here's a quick example of something that bothers me. Not really sure why ElementAt<> doesn't actually return the line numbers of a file properly, even if you specify the correct line. For example, you have a TextFile in your debug folder called TextTest.txt and it will consist of the following:
Line 1 here
Line 2 here
Line 3 here
Line 4 here
Line 5 here

    Private Function ReadLine(ByVal ePath As String, ByVal iLine As Integer) As String

        If File.Exists(ePath) = True Then
            Dim ourLineStr As String = File.ReadAllLines(ePath).ElementAt(iLine).ToString
            Console.WriteLine(ourLineStr)
            Return ourLineStr
        End If

    End Function

    Private Sub Button5_Click(sender As Object, e As EventArgs) Handles Button5.Click
        
        ReadLine(ePath:=System.IO.Directory.GetCurrentDirectory & "\TestText.txt", iLine:=3)

    End Sub



If you want any of the lines, you need to specify the line before as the point ElementAt<> otherwise it will always output the line after the one you'd think ElementAt is actually at...

If I want Line 4, you need to choose iLine:=3) to get the forth line. Just one of them odd things I stumbled over today while using some LinQ expressions.

Ahh can't change title, should be one behind

Is This A Good Question/Topic? 0
  • +

Replies To: ElementAt<> Always One Behind

#2 modi123_1   User is online

  • Suitor #2
  • member icon



Reputation: 15432
  • View blog
  • Posts: 61,819
  • Joined: 12-June 08

Re: ElementAt<> Always One Behind

Posted 26 August 2018 - 06:21 PM

It his an issue where collections, arrays, etc start counting at 0?
Was This Post Helpful? 0
  • +
  • -

#3 Sheepings   User is offline

  • D.I.C Lover
  • member icon

Reputation: 224
  • View blog
  • Posts: 1,260
  • Joined: 05-December 13

Re: ElementAt<> Always One Behind

Posted 26 August 2018 - 06:49 PM

I honestly don't know Modi, to be honest. I don't think so, but I'm sure someone might know.

After scouring the msdn I didn't find an awful lot of information on .ElementAt<> to help me understand why it is so.
Was This Post Helpful? 0
  • +
  • -

#4 modi123_1   User is online

  • Suitor #2
  • member icon



Reputation: 15432
  • View blog
  • Posts: 61,819
  • Joined: 12-June 08

Re: ElementAt<> Always One Behind

Posted 26 August 2018 - 07:23 PM

Hint.. Yes.

Look at how collections are indexed.

https://docs.microso...le.readalllines
https://docs.microso...rable.elementat

File.ReadAllLines returns an array of strings.
Arrays start indexing at 0.
LINQ's "element at" pulls from the sequence of the collection.
QED - indexing starts at zero.

        Dim foo() As String = {"a", "b", "c"}

        Console.WriteLine(foo.ElementAt(0))
        Console.WriteLine(foo.ElementAt(2))

        'exception - out of bounds of the array.. Console.WriteLine(foo.ElementAt(5))



a
c

Was This Post Helpful? 1
  • +
  • -

#5 Sheepings   User is offline

  • D.I.C Lover
  • member icon

Reputation: 224
  • View blog
  • Posts: 1,260
  • Joined: 05-December 13

Re: ElementAt<> Always One Behind

Posted 27 August 2018 - 06:05 AM

Ah yes, thats why, I knew about the arrays being one behind, but this never dawned on me to check the method. But I should have debugged it instead of jumping on here. :)

So in this case, It's obviously one behind because of how the array of strings is forwarding it to ElementAt<>.

So to summarise; the ElementAt<> is taking the integer value I passed at the point the array is at while the code reaches ElementAt<> and not at the point I think its at in the file its reading. (If that makes sense)

But I get it.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1