Forum Discussion

amitbansal's avatar
amitbansal
Occasional Contributor
8 years ago

aqFile LinesCount fails to work

here is my function where I am using LinesCount and facing issue, language used is JScript

function getLines(){
 var sapFile;
 sapFile = aqFile.OpenTextFile("PHOENIX_ACTUALS", aqFile.faRead, aqFile.ctANSI);
 sapFile.SetPosition(0, 0);
 Log.Message(sapFile.LinesCount);
 sapFile.Close();
}

 

The PHOENIX_ACTUALS is a text file and has 211 lines, LinesCount is returning 1 instead.

  • amitbansal's avatar
    amitbansal
    8 years ago

    Thanks for your reply.

    when I use the FS object as in below function it reads the lines and I am able to count the lines in count variable.

     

    function ReadFile(AFileName)
    {
      const ForReading = 1;
      let FS = Sys.OleObject("Scripting.FileSystemObject");

      let F = FS.OpenTextFile(AFileName, ForReading);
    count =0;  

    while(! F.AtEndOfStream){
        let s = F.ReadLine();
        count++;

      }
      F.Close();
    }

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    By all means, use whatever works. But the file, as it stands, is not in a format that, by default, has "lines". Again, opening it in a simple notepad application indicates that there are no CF/LF characters on each line.  

    When I open it in WordPad or MS Word, then the formatting shows, but as a standard, flat, plain text file... nope, won't work.

     

    I tried your function using the FileSystem object and it works fine.  My guess is that there is some sort of encoding being used in your file that is encoding the CR/LF character differently than the aqFile methods recognize.

     

     

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    Actually, opening up the file you have attached in notepad opens up and, in my screen resolution shows over 300 lines... that is, if I don't have word-wrap turned on... with word wrap, it's actually longer...

     

    The reason being is that there are no carriage return/line feed characters in the file to indicate an end of line so, technically, it's all one line.  The problem is not in aqFile but in the process that is generating PHOENIX_ACTTUALS in that it's not actually putting characters in to indicate end of line.

    • amitbansal's avatar
      amitbansal
      Occasional Contributor

      Thanks for your reply.

      when I use the FS object as in below function it reads the lines and I am able to count the lines in count variable.

       

      function ReadFile(AFileName)
      {
        const ForReading = 1;
        let FS = Sys.OleObject("Scripting.FileSystemObject");

        let F = FS.OpenTextFile(AFileName, ForReading);
      count =0;  

      while(! F.AtEndOfStream){
          let s = F.ReadLine();
          count++;

        }
        F.Close();
      }

      • Ravik's avatar
        Ravik
        Super Contributor

        Instead of open file in read mode and read one by one line, why not open it in Append mode ?

        ( If you line is having 1000s of line then its time consuming process.)

         

        When you open any file in Append mode your cursor is move on last line and using .Line Function you can get line number.

  • amitbansal's avatar
    amitbansal
    Occasional Contributor
    can someone from smartbear take a note of the possible bug in aqfile ?
    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor

      Honestly, I don't think this is a bug in aqFile.  As noted, opening the file up in Windows Notepad displays with no line breaks.  This means that the file is formatted differently than what is typically done for a flat text file. If notepad can't find linebreaks, then it's not a standardly formatted text file.  Again, nothing wrong with using the Scripting.FileSystem object that you are using.

      Question: What is the source of PHOENIX_ACTUALS?  Is there a way that the file generation can be tweaked to a different format?

    • HKosova's avatar
      HKosova
      SmartBear Alumni (Retired)

      It's not a bug. aqTextFile.LinesCount is working as intended.

       

      Windows platform uses the CR+LF ('\r\n' or 0x0D0A) character combination as a line break, so LinesCount counts the lines based on CR+LF. CR or LF alone are not recognized as line breaks.

       

      If you wish you can submit a feature request to have aqFile recognize other line separators.