ansaurus

Question

Answer 1

+11 A:

Try LoadFromStream and do something like:

fileStream := TFileStream.Create(aFileName, fmShareDenyNone);
myTStringList.LoadFromStream(fileStream);
fileStream.Destroy();

Drejc 2009-01-15 06:54:02

Do not call Destroy directly in an application. Instead, call Free, which checks that the TFileStream reference is not nil and only then calls Destroy.

inzKulozik 2009-01-16 18:43:09

You are rigth it should be Free not Destroy ...

Drejc 2009-01-19 10:03:15

Correction: Destroy is quite acceptable in the above example. `MyObject.Free` is equivalent to `if MyObject <> nil then MyObject.Destroy`. The reason you use `Free` is to provide a check whether the reference has been assigned. In the above example you can safely guarantee that by reaching line 3 that `fileStream` references an object that was correctly created. What is missing however (an much more of an issue) is the `try..finally` statement. Also, depending on the scope of the `fileStream` variable, it may be advisable to clear it: `finally fileStream.Destroy; fileStream := nil; end;`

Craig Young 2009-12-18 12:51:59

before a discussion about Free or Destroy starts you may want to read this: http://blogs.embarcadero.com/abauer

Joe Meyer 2010-02-11 05:39:30

I was always somehow confused why there are two methods available, and honestly I almost in every case use Destroy over Free. This is because it will throw an exception in cases I have not assigned the object and so bugs are faster detected.

Drejc 2010-02-11 08:11:08

Answer 2

+1 A:

Also, try..except and try..finally are good friends at these times. Encapsulate your file reading code in these types of blocks and tell the user about the problem that arises.

Niklas Winde 2009-01-15 07:05:25

Yes I know. But I want to search many log-files in a directory. If I have a try except for every file load maybe it slow down the execution. It is already rather slow.../Roland

Roland Bengtsson 2009-01-15 07:18:20

You actually want a try / finally for every file. Unless you are reading a lot of really small files I don't see it impacting performance significantly. If it does, then you may want to consider a different mechanism all together.

Jim McKeeth 2009-01-15 09:51:57

@Niklas: NO! NO! NO! and NO again! Do not abuse try..except! Hiding errors with try..except leads to a huge amount of insidious bugs in the long run.

Craig Young 2009-12-18 12:56:01

@Craig Young: Did you miss the part of my answer that says "...and tell the user about the problem that arises"? That is not hiding errors, that is handling them gracefully in my book.

Niklas Winde 2010-01-13 12:58:52

Answer 3

A:

Thanks a lot! This was the fastest answer ever in a forum.

Now I can continue with other parts of my application.

Sinceraly Roland

Roland Bengtsson 2009-01-15 07:15:40

If Drejc's answer's the one you liked, you should really accept his answer, and thus up his reputation.

Frank Shearar 2009-08-01 18:23:36

Answer 4

+4 A:

fmShareCompat should probably be marked as deprecated. You want fmShareDenyNone (as Drejc said)

fmShareCompat comes from 16 DOS days I believe. On Windows, it is treated the same as fmShareExclusive. When Linux was supported it was treated the same as fmShareDenyNone.

Jim McKeeth 2009-01-15 09:50:40

ansaurus

tags:

views:

answers:

Want to read a file to a TStringList

related questions