aqFile LinesCount fails to work

[amitbansal]

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.

[tristaanogre]

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 · Accepted solution]

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]

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.

[amitbansal]

can someone from smartbear take a note of the possible bug in aqfile ?

[tristaanogre]

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]

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.

[Ravik]

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.

[tristaanogre]

---

@Ravik wrote:

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.

---

In this case, this still won't work.  The line terminator of CR/LF is not present in the file so the aqFile.OpenTextFile method still will only see one line.  As mentioned, the file needs to be generated to have both CR and LF at the end of each line for the line count to be accurate.