File handle from successfull FileOpen() is always "1"?

[Malkey]

From this question arose.

With a successful FileOpen() call, does everyone always obtain a "1" as the returned file handle? If so, does "FileClose(1) " close all unclosed, opened files?

Local $hFile2 = FileOpen("TestOpen.txt", 2)
ConsoleWrite('File "handle" from FileOpen mode 2 is ' & $hFile2 & @LF)
FileClose($hFile2)

Local $hFile0 = FileOpen("TestOpen.txt", 0)
ConsoleWrite('File "handle" from FileOpen mode 0 is ' & $hFile0 & @LF)
FileClose($hFile0)

FileDelete("TestOpen.txt")

#cs
   Running:(3.3.8.0) or (3.3.9.4), my WIN_XP/Service Pack 3  returns:-
    File "handle" from FileOpen mode 2 is 1
    File "handle" from FileOpen mode 0 is 1
#ce

[guinness]

How I've interpreted it is it's a similar situation as with AutoIt's native controls returning Control IDs rather than Handles. The term handle is used in the documentation for FileOpen but it's more of an identifier that is used in conjunction with the internal array of AutoIt (though I can only speculate this is the case.)

As you know AutoIt is very forgiving for 'sloppy coding' so it has to keep a record of open handles etc... that can be closed on exit.

Edited April 12, 2012 by guinness

[guinness]

See >>

Local $hFile_1 = FileOpen("TestOpen1.txt", 2)
Local $hFile_2 = FileOpen("TestOpen2.txt", 2)
Local $hFile_3 = FileOpen("TestOpen3.txt", 2)
ConsoleWrite('File "handle" from FileOpen mode 2 is ' & $hFile_1 & @LF)
ConsoleWrite('File "handle" from FileOpen mode 2 is ' & $hFile_2 & @LF)
ConsoleWrite('File "handle" from FileOpen mode 2 is ' & $hFile_3 & @LF)
FileClose($hFile_1)
FileClose($hFile_2)
FileClose($hFile_3)

FileDelete("TestOpen1.txt")
FileDelete("TestOpen2.txt")
FileDelete("TestOpen3.txt")

Edited April 12, 2012 by guinness

[Malkey]

@guinness

I believe you are correct - thank-you.

Malkey

Edited April 12, 2012 by Malkey

[guinness]

Yeh, see the example above yours too. It's kind of the same approach in instead of just adding to an array each time, instead grab an available 'slot' as it were. As is noted in your first example, instead of using 2 it uses 1 because this became available due to the 'handle' being closed before.

[Melba23]

Hi,

If I remember correctly from my 8086 assembler programming days, a file handle has always been an integer value which is returned by the OS from the Int21h call to open/create the file. The value returned was limited to 0xFF by the size of the register used to return the value (AX) - I assume the arrival of the 386 and the EAX register increased this value but I had moved on to other languages by then. I do believe that there is still a limit of 512 open file handles per process - I remember a thread here where forgetting to close the opened files meant that the script failed at some point.

This integer handle was indeed an index to a more complex data structure, but this index was managed by the OS and not by AutoIt as is the case with the ControlIDs. You got the same integer values regardless of the language used to get the handle as they all convert to assembler/machine code in the end.

That is how I recall it - but it was a long time ago and I will have to dig my old assembler books out of the cupboard later today to check on the details.

M23