Delphi findclose ошибка

• Подписаться на тему
• Сообщить другу
• Скачать/распечатать тему

• Предыдущая тема
• Delphi: Общие вопросы
• Следующая тема

EDIT —  I’ve just re-checked the declaration and find that the second project is using a different FilUtilh.inc file which declares FindClose as
Procedure FindClose (Var F : TUnicodeSearchrec);

I haven’t specified anything different as far as ‘INC’ paths are concerned  in fact that is another question I have been meaning to ask — where DO you set a specific ‘INC’ folder?  but more important for now how can I force the first project’s FilUtilh.inc file to be used?

Second EDIT  —  On closer reading I now see that FindClose is declared twice in the same .INC file.

Is there anything wrong with me commenting out the ‘TUnicodeSearchrec’ version?   along with the FindFirst and FindNext TUnicodeSearchrec versions?

======================================
I have two projects using similar code to read filenames from disk. FindFirst is followed by FindNext and finally FindClose.

One project (with this procedure) :

compiles and runs perfectly.

The second — with this code :

Won’t compile, complaining Error: Incompatible type for arg no. 1: Got «TRawbyteSearchRec», expected «QWord» at FindClose(FileInfo).

I’ve checked that both projects are set to the same ‘bittness’ (actually tried both 32 and 64).

I’ve also checked the declaration of FindClose in FilUtilh.inc which is :
Procedure FindClose (Var F : TRawByteSearchrec);
so fail to understand why it’s expecting a QWord.

In the second project, I need to go on to find other files (with a different extension) so assume that I need to call FindClose before doing so.

« Last Edit: June 13, 2017, 08:10:17 pm by J-G »

Logged

FPC 3.0.0 — Lazarus 1.6 &
FPC 3.2.2  — Lazarus 2.2.0 
Win 7 Ult 64

I have two projects using similar code to read filenames from disk. FindFirst is followed by FindNext and finally FindClose.

Just to nit-pick, but you are calling FindClose() in the wrong place.  It should be inside the first ‘if’ block.  Don’t call FindClose() if FindFirst() fails:

Also, a better way to write the loops you have shown would look more like this instead:

1.

2.

Alternatively:

Won’t compile, complaining Error: Incompatible type for arg no. 1: Got «TRawbyteSearchRec», expected «QWord» at FindClose(FileInfo).

That means the compiler is trying to call the Win32 API FindClose() function instead of the RTL’s SysUtils FindClose() function.  The Win32 API function takes a HANDLE as input, that is where the QWord is coming from (when you are compiling for 64bit).  You likely have the Windows unit after the SysUtils unit in your ‘uses’ clause, causing the Win32 API function to take priority.  Either swap the units around, or else quality which function you intended to call:

I’ve checked that both projects are set to the same ‘bittness’ (actually tried both 32 and 64).

Bitness has nothing to do with this.  It is a naming comflict.  Delphi has the same problem.

In the second project, I need to go on to find other files (with a different extension) so assume that I need to call FindClose before doing so.

You always have to call FindClose() regardless, or else you will leak OS resources.

« Last Edit: June 13, 2017, 08:17:11 pm by Remy Lebeau »

Logged

…Error: Incompatible type for arg no. 1: Got «TRawbyteSearchRec», expected «QWord»[/color] at FindClose(FileInfo).

Specify explicitly SysUtils.FindClose. In the second case, most likely you have the function Windows.FindClose.
Additional. In the first example, you skip half of all files, because each FindNext retrieves one file at a time. Two calls FindNext (FileInfo) = 0 and FindNext (FileInfo) <> 0, but one addition of the file.
There should be the following scheme:

@Remy Lebeau
In FPC, unlike Delphi, FindClose should be called regardless of the success of FindFirst. See docs.

Logged

@Remy Lebeau
In FPC, unlike Delphi, FindClose should be called regardless of the success of FindFirst. See docs.

That’s not: unlike Delphi
That’s always the case. Specifically under windows the handle won’t get released until program termination….
Remy should know better.

Logged

I actually get compliments for being rude… (well, Dutch, but that is the same)

In FPC, unlike Delphi, FindClose should be called regardless of the success of FindFirst. See docs.

The statement in the doc is a little ambiguous to me.  Does it mean that FindClose() must always be called even if FindFirst() fails, or only if it succeeds?  Does FindFirst() always allocate memory that is then not freed if FindFirst() subsequently fails?  If so, why does it not free the memory before exiting?  That smells like a design bug to me.

Logged

In FPC, unlike Delphi, FindClose should be called regardless of the success of FindFirst. See docs.

The statement in the doc is a little ambiguous to me.  Does it mean that FindClose() must always be called even if FindFirst() fails, or only if it succeeds?  Does FindFirst() always allocate memory that is then not freed if FindFirst() subsequently fails?  If so, why does it not free the memory before exiting?  That smells like a design bug to me.

The best docs for that are on MSDN. But anyway, to answer your question: if the allocation of the handle fails, findclose is not necessary. Because there’s nothing to close… https://msdn.microsoft.com/en-us/library/windows/desktop/aa364413(v=vs.85).aspx
ASerge was merely incomplete but essentially correct.
So note that the same goes for Delphi.

« Last Edit: June 13, 2017, 08:27:08 pm by Thaddy »

Logged

I actually get compliments for being rude… (well, Dutch, but that is the same)

That’s not: unlike Delphi
That’s always the case. Specifically under windows the handle won’t get released until program termination….
Remy should know better.

Actually, I do know better.  In Delphi, if FindFirst() fails, it calls FindClose() before exiting (and always has), thus any subsequent FindClose() in user code would be a no-op.  FindClose() in user code is only meaningful if FindFirst() succeeds.  I would expect FPC to have the same behavior, for compatibility when porting Delphi code to FPC.

Logged

The best docs for that are on MSDN. But anyway, to answer your question: if the allocation of the handle fails, findclose is not necessary. Because there’s nothing to close… https://msdn.microsoft.com/en-us/library/windows/desktop/aa364413(v=vs.85).aspx

I understand that.  But at least in Delphi, FindFirst() does more than then call FindFirstFile() by itself.  It may ALSO call FindNextFile() (potentially more than once) to take the ExcludeAttr into account, so it may have to skip files before returning the first matching file. If THAT fails, FindFirst() calls FindClose() before exiting.  FindNext() also performs the same ExcludeAttr skipping loop, so it may have to call FindNextFile() more than once.  But, if that fails, FindNext() does not call FindClose() before exiting, it requires the caller to call it instead.

I would expect the same from FPC.

« Last Edit: June 13, 2017, 08:31:15 pm by Remy Lebeau »

Logged

Actually, I do know better.  In Delphi, if FindFirst() fails, it calls FindClose() before exiting (and always has), thus any subsequent FindClose() in user code would be a no-op.  FindClose() in user code is only meaningful if FindFirst() succeeds.  I would expect FPC to have the same behavior, for compatibility when porting Delphi code to FPC.

So you rely on implementation detail? Anyway. In this case (but I will check it, because I am not convinced) this would work in most but not all cases:
Because it does not check the fail reason and if findfirst fails because of a failing handle allocation that is sh*t code because there is nothing to close anyway????

Agree??

Logged

I actually get compliments for being rude… (well, Dutch, but that is the same)

So you rely on implementation detail?

Yes, because that is the most accurate way to know how something really works.  Documentation is not always accurate.

Anyway. In this case (but I will check it, because I am not convinced) this would work in most but not all cases

I assure you, it works the way I described.  I have Delphi’s RTL/VCL/FMX source code for almost all Delphi versions from Delphi 5 all the way up to 10.0 Seattle (I’m missing 1-4, 7-8, and 2005).  I looked at them before posting my replies here.

If you look at the various Delphi implementations over the years, you can see that any failure inside of FindFirst() will call FindClose() before exiting if the search handle has been allocated.

« Last Edit: June 13, 2017, 11:58:28 pm by Remy Lebeau »

Logged

Which is dumb programming? Agree?? By now I have looked at the code (and in my own copies of D5, D7, D2006 and XE2). Since that is copyrighted. Plz edit your post.

Logged

I actually get compliments for being rude… (well, Dutch, but that is the same)

According to FPC documentation, you should always call FindClose. This contradicts the general idea (also supported by Microsoft) that if there is an error in resource allocation, you do not need to release it. Delphi supports this concept within itself, ie. there it is correct to do, like you, call FindClose only after a successful FindFirst. Moreover, in earlier versions of Delphi there was a run-time error if there was an «extra» FindClose. Then they were safe from such a mistake, because many newcomers did not understand the concept.
In FPC, there is no implementation for such idea, so you always need to call FindClose.

Logged

It seems I’m adept at stirring a Hornet’s Nest 

Many thanks to Remy for pointing out where my error lay — quite right about Windows being after SysUtils. I only added Windows when I needed to test for the internet being available and stupidly simply added it to the end of my Uses Clause — I hope that is a useful lesson learned  —  just never occurred to me 

Also thanks to ASerge and Remy for pointing out the inefficient loops — all now replaced.

Logged

FPC 3.0.0 — Lazarus 1.6 &
FPC 3.2.2  — Lazarus 2.2.0 
Win 7 Ult 64

In FPC, there is no implementation for such idea, so you always need to call FindClose.

Nope. Nonsense. You should just check on findfirst… on all platforms. I will put in a bug report. If findfirst fails, also on fpc, no need to call findclose.
You do not understand the stupidity of the Delphi code…. But you are smart, You read what MSDN says…. The Delphi code does basically nothing in the most likely case. And circumvented that later by preventing a second call… That’s why… Now, you agree too

Note this stupidity is not platform specific. It is stupid on ANY file handle.
[edit]
I put in the bug report against documentation.
https://bugs.freepascal.org/view.php?id=32012

« Last Edit: June 13, 2017, 11:16:00 pm by Thaddy »

Logged

I actually get compliments for being rude… (well, Dutch, but that is the same)

If findfirst fails, also on fpc, no need to call findclose.

NEED!

In Delphi no leak.

Logged