Dataset1.Filter := 'State' = 'CA'

Dataset1.Filter := 'State = CA'. 

procedure TEditForm.Exit1Click(Sender: TObject);
begin
  FrameForm.Exit1Click(Sender);
end;

   1. Choose Project|Options to access...

TMessage-
   wParam : Word; //wrong. it is of type  WPARAM - a longint...

      Default:   {$Z1}
                 {$MINENUMSIZE 4}

The Delphi Help entry for Val says Val will convert only whole number -- this is not true, it will do Reals also, complete with "E" notation, as in "123.456E3".

Description

Reported by Graham Wideman; checked by Reinier Sterkenburg

Help says:

procedure Val(S; var V; var Code: Integer);

[...] S is a string-type expression; it must be a sequence of characters that form a signed whole number.

The help file states that TTable.KeyFieldCount is zero-based. This is incorrect, it is one-based.

Description

Reported by Karl Waclawek; checked by Reinier Sterkenburg

To reproduce this, follow these steps:

• Put a TTable, TDataSource and TDBGrid on the form. for the TTable use the table items.db from the DBDEMOS sample database. Connect everything and open the table.
• Then, add a TButton and a TEdit component. Write the following handler for the button's OnClick event:

  procedure TForm1.Button1Click(Sender: TObject);
    begin
    with Table1 do
      begin
      SetRangeStart;
      KeyFieldCount := StrToInt(Edit1.Text);
      FieldByName('OrderNo').Value := 1004;
      SetRangeEnd;
      KeyFieldCount := StrToInt(Edit1.Text);;
      FieldByName('OrderNo').Value := 1005;
      ApplyRange;
      end;
    end;

• Run the app.

First, what would we expect for a partial field match on the first field? We would expect to see all records with OrderNo values 1004 and 1005.

Secondly, what would we expect for a match on all fields? Since we are only assigning a non-Null value to the first field we should expect a range based on the limits (1004, Null) and (1005, Null). Null is always considered to be less than non-Null, therefore we expect to see all records with OrderNo = 1004 and only those with OrderNo = 1005 whose ItemNo value is Null (none in this case).

Now, try all four tests, using 0, 1, 2, and 3 typed into the edit box and then clicking on the button. The results are:

0:
Help file interpretation: partial match on first field of index Actual behaviour: match on all fields

1:
Help file interpretation: partial match on two (= all) fields of index Actual behaviour: partial match on first field of index

2:
Help file interpretation: illegal (probably raises an exception) Actual behaviour: match on all (two) fields of the index

3:
Help file interpretation: illegal Actual behaviour: illegal, raises "Number Out of Range" exception

P.S.: I am only reporting this because I always thought that somebody must have reported it already (since it's so obvious), but the bug is still present today.
Karl.

The help file states that TTable.KeyExclusive defaults to True. This is incorrect, it defaults to False.

Description

Reported by Karl Waclawek; checked by Reinier Sterkenburg

Reproducing it is simple:

• Create new application.
• Put a TTable on a Form1, set DatabaseName = 'DBDEMOS', TableName = 'orders.db', Active = True.
• Put a TButton on Form1, wite the followin OnClick handler:

  procedure TForm1.Button1Click(Sender: TObject);
    begin
    with Table1 do
      begin
      SetRangeStart;
      if not KeyExclusive then beep;
      sleep(100);
      FieldByName('OrderNo').Value := 1004;
      SetRangeEnd;
      if not KeyExclusive then beep;
      FieldByName('OrderNo').Value := 1005;
      ApplyRange;
      end;
    end;

• Run the app and click the button.

If you can hear two beeps then KeyExclusive defaulted to False. In addition, you can put a TDBGrid on the form, link it to the TTable through a TDatasource and observe that the records with the OrderNo values 1004 and 1005 are included in the range. Why do I think it is a documentation bug? Because in my opinion the default behaviour of including the limits in the range is the most intuitive one.

TypeLib documentation wrong:
You can't implement imported interfaces

Description

By Brad Aisa; not independently checked
Maybe this is not just a documentation bug; where else in the bug list would a warning for this bug be appropriate (RPS)?
The Delphi TypeLib documentation states that you can choose implementation interfaces for CoClasses defined in a library from any interfaces defined or imported into the library (Developer's Guide, p. 42-8). However in fact, the list of interfaces only shows interfaces declared in the type library, not imported into it. Therefore, it is extremely difficult to partition interfaces.

Reproducing the problem:
Create a COM Project1 with a type library, and implement a CoClass and declare an interface. Compile the project and register the library.
Create a second project with a type library, and add the first type library to its import list. Declare a CoClass. Declare an interface. Notice that you can choose to inherit it from any Interface imported, including Project1. Implement an interface on the Coclass -- the list only includes the interface declared in the library.

There are quite a few shortcomings and errors in Chapter 13, the Graphics example.

Description

Reported by Harley Flanders

There are quite a few errors and shortcomings in Chapter 13, the Graphics example:

• p. 306. Figure 13.10. The various glyphs are not easy to find, and Borland gives no hints. Some are not in the library of bitmaps. I found them in the demos\doc\graphex directory.
• p. 306. The line before "Creating a group..." should be at the bottom of the page.
• p. 311. The code in the middle of the page has MovePt.X and MovePt.Y for the dtRectangle case, but X and Y for the ellipse and round rect cases.
• p. 313. At top, FormMouseUp should have the guard "if Drawing then" like MouseMove has.
• p. 314. line 2. You are supposed to add a color grid, but there is no hint of where to find it. In Samples actually.
  This is a common fault in all examples. These programs are supposed to be tutorial, and Borland could tell you which component list to look at in each case.
• p. 323. Printing Graphics. What is suggested doesn't work. The resulting printout is smaller than most postage stamps. Apparently the code
  

  Printer.Canvas.Draw(0, 0, Image.Picture.Graphic)

  translates one screen pixel to one printer pixel. At 600 dpi, the screen goes to about 1 inch x 1 inch on the paper.
  Further elaboration on printing has been submitted but not yet checked.

Can't get the "Jump start" GDS program to work

Description

Can't get the "Jump start" GDS program to work.
Problem #1: Display grid displays no data.
Problem #2: OnFilterRecord property seems too short to take the long "Accept:=......" line in the book.

Solution / workaround

#1: Remember that the Active default is always False. Go into the GDSDataModule, click on the Customers table icon and set the Active Property to True. Do the same for the orders table.
#2: Double click on OnFilterRecord property in the Object Inspector and the unit code for OnfilterRecord will appear. And add the line to the Unit's code, not to the entry space in the Object Inspector.

ControlAtPos requires client coordinates, not screen coordinates.

Description

For the ControlAtPos method (Keyword: ControlAtPos), the documentation states that the Pos parameter is in screen coordinates.

Correction:

Coordinates passed in the Pos parameter should be in client coordinates of the control being used.

Cursors Property example is incorrect.

Description

The example for the Curosors Property topic (Keyword: Cursors Property, choose Example link) incorrectly shows a LoadCursor API call with the Instance parameter being passed as 1.

Correction:

The Instance parameter should be the instance of the application. This value is stored in a global variable, hInstance, available from the System unit. The line should read:

  Screen.Cursors[crMyCursor] := LoadCursor(hInstance, 'NewCursor');

MDIChildren example code causes GPF.

Description

The example for the MDIChildren Property topic claims that the following code will close all of the MDI children of Form1:

var
  I: Integer;
begin
  with Form1 do
    for I := 0 to MDIChildCount-1 do
      MDIChildren[I].Close;
end;

This code actually causes a GPF. The reason is that the MDIChildren list property is recalculated after children are closed and opened. So, if there were two MDI child windows and the first were closed in the first iteration of the above loop, in the second iteration there is only one window, and it is referenced as MDIChildren[0]. However, the loop will attempt to call MDIChildren[1].Close.

Correction:

The following code will correctly close all MDI child windows by looping down through the children instead of up:

var
  I: Integer;
begin
  with Form1 do
    for I := MDIChildCount-1 downto 0 do
      MDIChildren[I].Close;
end;

OnCreate event incorrectly lists order of events at object creation.

Description

The OnCreate Event topic lists the order of events that occur when an object is created as:

1. OnActivate
2. OnShow
3. OnCreate
4. OnPaint

Correction:

The actual order of events is:

1. OnCreate
2. OnShow
3. OnActivate
4. OnPaint

The Clear method does not Free the corresponding objects.

Description

The documentation for TStringList.Clear, etc. strongly implies that when you free a TStringList entry (or clear the list), the "corresponding object will be freed."
This does not appear to be the case. It is only the list-entry, and its object-pointer, that is freed. The object referenced by that pointer, if any, is not affected by the TStringList.

In the Online help for KeyDown, it is mentioned that you can stop the handling of a key by setting the Key variable to zero. This does not always work.

Description

By Christoph; checked and commented by Arjen Broeze
In the Online help it is mentioned, that you can stop the handling of a key in the OnKeyDownEvent, by simply setting the Key variable to zero. This doesn't seem to work. Trying to catch the return key with this simple code is ignored:

procedure TForm1.Edit1KeyDown(Sender: TObject; 
  var Key: Word; Shift: TShiftState);
begin
  if key=VK_RETURN then key:=0;
end;

Comment from checker:
The bug you reported is not a Delphi bug, but rather some strange Windows behavior.
For some reason, you can't change 'regular' keys from the KeyDown event (or more specific; from the WM_KEYDOWN message). With regular keys I mean the keys that generate 'output' on your screen ('a'..'z', space, enter etc). These keys generate a KeyPress event (WM_CHAR message) no matter what you do to the WM_KEYDOWN message. This behavior is by (Windows) design.
All other keys (arrow keys, home, end etc) can be changed from the WM_KEYDOWN message (KeyDown event) since they never generate a WM_CHAR (KeyPress event).

Browse buttons are missing on the Win32 SDK help files, rendering the Knowledge Base and overviews useless.

Description

Reported by Jani Järvinen

Solution / workaround

I have a simple and yet very effective (almost a hack, should I say) solution to this:

• Open Help Workshop (\delphi 2.0\help\tools)
• Enable Help Author mode in the File menu
• Open your Win32 API help file

Now you can use the keys CTRL+SHIFT+LEFT/RIGHT ARROW (see Help Workshop documentation) to navigate on the help files almost like with Browse Buttons. For example, open the topic "Using the Registry" using the Index. Now press the magic keys, and you can read the whole article, with no patches at all!

Creating the (Win95 style) help index takes very long (more than 15 minutes on some machines) and at the end it can fail

Description

Creating the (Win95 style) help index doesn't only take very long, but sometimes after 15(+) minutes you get an error message that there isn't enough memory (25 MB internal memory doesn't even seem to be enough). The 2.01 helpfiles didn't fix this.

By Arjen Broeze
Background information:
When you generate the help index for Delphi.hlp, WinHelp looks in the contents file (Delphi.cnt) to find out for which .hlp files .fts (full text search) databases should be build. Therefore when you specify to create the help index for delphi.hlp, .fts are built for cwg.hlp, delphi.hlp, guide.hlp, kbase.hlp, mapi.hlp, mm.hlp, mstools.hlp, obpascal.hlp, ole.hlp, opengl.hlp, rpc.hlp, vcl.hlp, win32.hlp and win32s.hlp. After creating all these files WinHelp creates a .ftg (full text guide?) for delphi.hlp with references to all the .fts files. In total, the size of all the created files is almost 22 MB !!!! That's why this takes so long.

Solution / workaround

If you have problems creating all the .fts files in one step, create them for each help file independently (with Delphi.hlp as the last one). Simply open the help file (e.g. cwg.hlp) by double-clicking on it in Explorer and click the 'Find'-tab. This will create the .fts file for that file only.

Delphi can't find the Help file

Description

Reported by Reinier Sterkenburg

When invoking the on line help, Delphi displays the message:
"Cannot find the delphi3.hlp file. Do you want to try to find the file yourself? (Yes / No)"
On choosing Yes it is indeed (mostly) possible to find it myself and go into the help system, but after closing the Help (not Delphi), asking for help again, mostly (not always) results in that same message and searching for the help again. Also, in some cases browsing to the the help file does NOT work! This latter seems to happen always when a topic is looked for that has no entry in the help file.
Maybe it is relevant to note here that I have got Delphi 2 installed on the same machine (and Delphi 1 too, by the way).

Solution / workaround

• Reinstall Delphi. This worked, but I had to have administrator privileges to get it right. See entry on the installation page.
• Possibly the same result could be achieved by adding the registry entry:
  HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Help; key: DELPHI.HLP; value: c:\Program Files\Borland\Delphi 3\Help

No keyword-files (*.kwf) are supplied with Delphi 3

Description

Reported by Michael Dreidoppel

The German version of Delphi 3.01 does not contain the following keyword-files (*.kwf):
dbexplr3, delphi3, ibctrls, imagedit, mapi, mm, mstools, obpascl3, ole, opengl, pvcs, quickrpt, rpc, teechart, vcl3, win32, win32s.
The UK version of Delphi 3.02 doesn't have them either; RPS
This is unlike Delphi 2.01.
This causes an unnecessary check whenever the help-system is activated (because the delphi.hdx cannot be built?) and does not allow to integrate new help-files.

Borland has commented on this:
There are no KWF files provided with Delphi 3.02 and if you want to generate your own KWF files you need to own the original RTF files - which are not released (and I do not think that they would be ever published for public)
And (translated from German):
"The files are not needed"

Compiler Error 202 missing.

Description

Attempting to view help for Compiler Error 202: Property cannot be published results in a Topic Does Not Exist error message.

Correction:

More information can be found on publishing properties by searching the help for "published parts". The most likely cause of this error is attempting to publish a property with a type that Delphi does not know how to read and/or write to a stream. To stream the data for non-standard data types, override the component's DefineProperties method and register a property reader and writer routine. See the source of TStringList for an example of how this is done.

The TDataSetState section defines TDataSetState wrong

Description

By Ronald Hinds; confirmed by Arjen Broeze
There is an error in the Delphi 3 (Build 5.53) Help file. The TDataSetState Type section in the help files defines the set as:

type TDataSetState = (dsInactive, dsBrowse, dsEdit, dsInsert, dsSetKey,
  dsCalcFields, dsUpdateNew, dsUpdateOld, dsFilter);

(This is a leftover of the implementation of TDataSetState in Delphi 2.0.)
elsewhere, the DataSet.State Section defines it correctly (according to the source in db.pas) as:

type
  TDataSetState = (dsInactive, dsBrowse, dsEdit, dsInsert, dsSetKey,
    dsCalcFields, dsFilter, dsNewValue, dsOldValue, dsCurValue);

property State: TDataSetState;

TListBox Properties popup is incomplete.

Description

The TListBox component topic has a popup topic, accessed through the Properties link. This popup topic lists all properties for the component and links to the appropriate topics explaining each property. Unfortunately, someone forgot to actually link each of the properties to the topics.

Correction:

You will have to use the search dialog of WinHelp for the particular property you need help with. For example, if you need help with the BorderStyle property, press the Search button and entery BorderStyle in the resulting dialog.

The documentation for TCanvas.Pixels doesn't mention that -1 can be returned as result.

Description

Reported by Frank Heyne and Stefan Hoffmeister

The documentation for TCanvas.Pixels fails to mention that the result of a "Canvas.Pixels" MAY be -1, implying that the coordinate queried is not within the clipping area or the device does not support this operation. In particular this will affect the TPaintBox component during a redraw (OnPaint). Code relying on Canvas.Pixels returning always a valid RGB colour will fail. A runtime error indicating this erroneous situation will only occur if range checking has been enabled ({$R+}).

Correction:

Either make sure that the coordinate that is queried for colour information is always within the clipping area and the device has these capability or (preferrably) test the value returned by Canvas.Pixel:

  with PaintBox1.Canvas do
  begin
    theColour := Pixels[0, 0];
    if theColour <> -1 then { inside clipping area }
    begin
      { valid value in theColour }
      Pixels[0, 0] := theColour;
    end
    { else ... }
  end;

TFieldDefs.Add is missing REQUIRED parameter.

Description

The Add method for the TFieldDefs object (Keyword: Add, choose Add Method for Field Definitions link) is missing a parameter.

Correction:

The declaration for the procedure should read:

procedure Add(const Name: string; DataType: TFieldType; Size: Word; Required: Boolean);

The Required parameter is described as:

"to assign (or not assign) a constraint to the field that is equivalent to the SQL constraint NOT NULL." -- Steve Koterski (koterski@borland.com)

For those of you like me who know little about SQL, this means that new records are required to contain a value in this field (i.e. it may not be "NULL").

TFont.Height and TFont.Size reversed description of pixel and point size.

Description

The topics for TFont.Size and TFont.Height (Keyword: TFont, choose Size or Height link) seem to be reversed.

Correction:

The description of TFont.Size actually applies to TFont.Height, and TFont.Height applies to TFont.Size.

Also, the formula shown for calculating a TFont.Size (shown in the TFont.Height topic) will not compile because of the use of the / operator and storing the result to an integer variable. You can use the following line if you need to calculate the height in pixels of a font:

  PixelHeight := Trunc(-Font.Height * Font.PixelsPerInch / 72);

The documentation of the ExitWindows function (unit WinProcs) has the arguments in the wrong order.

Description

By Charlie Burris
The documentation for the ExitWindows procedure in the WINPROCS unit lists the function declaration as follows:
function ExitWindows(Reserved: LongInt; ReturnCode: Word): Boolean;
I discovered through trial and error that the actual declaration is:
function ExitWindows(ReturnCode: Word; Reserved: LongInt): Boolean;
Note: This is also the order that the arguments are explained in.

The Delphi 1.02 help documentation for the Files property of TOpenDialog and TSaveDialog is incorrect concerning the returned value of the FileName property when ofAllowMultiSelect is set.

Description

Reported by Chris Cheney; checked by Reinier Sterkenburg

The Files property help topic says 'To ... select multiple file names in the dialog box, include ofAllowMultiSelect in the Options property ... The entire list of names is returned as the value of the FileName property. If the list of names is long, FileName contains only the first 127 characters.'

The help topic for TFileName, which is the type of the FileName property of TOpenDialog, states that is is declared as String[79]. It is therefore impossible for FileName to contain as many as 127 characters.

Inspection of the VCL code and empirical testing shows that only a single file name is returned as the value of the FileName property when ofAllowMultiSelect is set in the Options property and multiple filenames are selected in the files list box.

Test program to show that FileName returns only a single file:

• Create a new, default project and set the following as the main froms OnShow event routine:

  procedure TForm1.FormShow(Sender: TObject);
  var
    OpenDlg: TOpenDialog;
  begin
    OpenDlg := TOpenDialog.Create(Self);
    with OpenDlg do
      begin
        Title := 'FileName returns only a single file from MultiSelect Open Dlg';
        Options := Options + [ofAllowMultiSelect];
        InitialDir := 'c:\windows';
        FileName := '*.*';
        while Execute do
          begin
            ShowMessage(Format('FileName=%s, length=%d, Files.Count=%d',
                               [FileName, Length(Filename), Files.Count]));
            FileName := '*.*';
          end
      end;
    OpenDlg.Free;
    Close
  end;

• (Compile and) Run.
• Select multiple files (drag down the file list box or use Shift or Ctrl + click).
• Click OK
• (Click Cancel to exit)

Comment by checker:
It looks like the Help author made a small 'slip of the pen': The Delphi 2 help says it correctly: "The first item in the list of names is returned as the value of the FileName property. If the list of names is long, FileName contains only the first 127 characters."

Link to Explorer help is missing

Description

Reported by Sergey Mishkovsky; checked by Andy Salva

To reproduce:

• start Delphi
• go to "Environment Options..." menu
• click on Help button
• click on Environment Options link
• there will be no Explorer link on that help page

Solution / workaround

If you go to the Explore tab first, then press the Help button, the Explorer help appears

The documentation says:
"A class can have only one default property, which descendant classes cannot change or hide."
This is not correct. In fact, this is only true for Delphi 1.

Description

Reported by Peter N. Roth; checked by Reinier Sterkenburg

The following code shows how this can be done:

  TMap = class(TStringList)
  private
    function GetItem(key: string): TObject;
    procedure SetItem(key: string; const Value: TObject);
  public
    property Item[key: string]: TObject read GetItem write SetItem; default;
  end; // TMap

where a _string_ is used as an 'index' into an 'array'. The accessors are private, the property Item is protected, and I've defined a new default property of the descendent class.

Comment by Reinier Sterkenburg
The fact that it is possible to create a new default property could be considered as an asset. But it is rather unfortunate that this hides the 'old' default property, so the fact remains that there can only be one default property at a time.
As long as the access methods have different parameter lists, a compiler could be made to accept this, analogous to the overloading mechanism that is already present.

The NT-specific comments in the on-line documentation for the TRegistry.MoveKey method are incorrect.

Description

Reported by James Rofkar

To reproduce:

1. Create a Delphi project that uses TRegistry under NT.
2. Use the TRegistry.MoveKey method against a registry key that contains subkeys, and notice the resulting behavior. It is inconsistent with the documentation.

The documentation states:

   Call MoveKey to copy or move an existing key, its subkeys, and data 
   values to a different location. Under Windows 95, copying is    
   recursive. If a key contains subkeys and data values, they too, are    
   copied. When the operation is complete, the new key is closed. Under    
   Windows NT, subkeys must be moved explicitly with separate calls to    
   MoveKey.

This is not the case. Using MoveKey with subkeys under Windows NT does not require explicit separate calls to MoveKey, since the subkeys get moved under Windows NT. What they apparently meant to say was:

   The Delete parameter specifies whether to delete the old key after 
   the copy operation. If Delete is True, the key specified by OldName 
   is deleted after it is copied. Otherwise the old key is closed. Under 
   Windows 95, Delete will delete the key and all its subkeys.  Under 
   Windows NT, the subkeys must be explicitly deleted by separate calls 
   to the TRegistry.DeleteKey method.

I have verified this using Delphi 3.02 under Windows 95 and Windows NT 4.0 (SP3)

The help for TMsgDialogButtons fails to mention mbYesToAll and mbNoToAll as possible values

Description

Reported by Erik Berry; checked by Reinier Sterkenburg

The declaration in dialogs.pas is:

  TMsgDlgBtn = (mbYes, mbNo, mbOK, mbCancel, mbAbort, mbRetry, mbIgnore,
    mbAll, mbNoToAll, mbYesToAll, mbHelp);
  TMsgDlgButtons = set of TMsgDlgBtn;

The help states incorrectly that the Thread object may be freed in the OnTerminate event handler.

Description

Reported by Heinz Höfling; checked by Reinier Sterkenburg

The Help entry for TThread.OnTerminate states: "The OnTerminate event is triggered after the thread's Execute method has returned and before the thread is destroyed.

type TNotifyEvent = procedure (Sender: TObject) of object;
property OnTerminate: TNotifyEvent;

Description
The OnTerminate event handler is called in the context of the main VCL thread, which means VCL methods and properties can be called freely. The thread object may also be freed within the event handler.
The TNotifyEvent type is the type for events that have no parameters. These events simply notify the component that a specific event occurred, in this case an OnTerminate event."

The underlined part is wrong: Freeing the thread object in the OnTerminate event handler is not always safe.
An example program in which the problem is demonstrated was submitted by Heinz Höfling, together with the explanation.
The explanation lies in the source of Classes.pas, procedures TThread.DoTerminate, TThread.CallOnTerminate and TThread.Synchronize:

procedure TThread.DoTerminate;
begin
  if Assigned(FOnTerminate) then Synchronize(CallOnTerminate);
end;

procedure TThread.CallOnTerminate;
begin
  FOnTerminate(Self);
end;

procedure TThread.Synchronize(Method: TThreadMethod);
begin
  FSynchronizeException := nil;
  FMethod := Method;
  SendMessage(ThreadWindow, CM_EXECPROC, 0, Longint(Self));
  if Assigned(FSynchronizeException) then raise FSynchronizeException;
end;

What happens here is that the SendMessage call causes the OnTerminate event handler to be executed. If OnTerminate frees the thread object (Self), its member fields become invalid. FSynchronizeException is a member field, but it is used after returning from SendMessage (OnTerminate). This is wrong and in the example code this causes Access Violations.

Searching in the TextDemo program not correct

Description

To reproduce the bug:
Run the TEXTDEMO demo and type
"this is a test"
Go to the beginning and search for "test". It won't find it. Go to the end and search for "this" and it won't find it.

Solution / workaround

The solution is to increment the "search count" variable by one. In SEARCH.PAS, these lines used to read:
line 107

    SearchCount := BufLen - SelStart - Length(SearchString);

line 115

    SearchCount := SelStart;

Just change them to add one to the search count calculation:
line 107

    SearchCount := succ(BufLen - SelStart - Length(SearchString));

line 115

  SearchCount := succ(SelStart);

Memory/resource leaks in Delphi 4 sample code projects

Description

Reported by Atanas Stoyanov; checked by Glenn Crouch

Atanas Stoyanov has started a dedicated Web Page on which memory/resource leaks in the Delphi 4 VCL and sample code are listed. The URL is: http://www.nidlink.com/~astoyanov/index.htm

The procedure CopyFile does not set the destination file's date/time equal to the source file's. It also unconditionally adds a backslash after a directory (even when it already has one).

Description

; checked by Glenn Crouch

The second bug about handling whether the destination ends in a backslash has been fixed in or before Delphi 4.02

Solution / workaround

1. In the part where the destination file is closed, add a line FileSetDate(Dest, FileGetDate(Source));
2. Check whether the Destination ends with a backslash.
When these corrections are applied, the code of CopyFile is as follows:

begin
  Destination := ExpandFileName(DestName); { expand the destination path }
  if HasAttr(Destination, faDirectory)
  then { if destination is a directory... }
    if Destination[Length(Destination)] = '\'
    then Destination := Destination + ExtractFileName(FileName)
    else Destination := Destination + '\' + ExtractFileName(FileName);
  GetMem(CopyBuffer, ChunkSize); { allocate the buffer }
  try
    Source := FileOpen(FileName, fmShareDenyWrite); { open source file }
    if Source < 0 then raise EFOpenError.Create(FmtLoadStr(SFOpenError, [FileName]));
    try
      Dest := FileCreate(Destination); { create output file; overwrite existing }
      if Dest < 0 then raise EFCreateError.Create(FmtLoadStr(SFCreateError, [Destination]));
      try
        repeat
          BytesCopied := FileRead(Source, CopyBuffer^, ChunkSize); { read chunk }
          if BytesCopied > 0 then { if we read anything... }
          FileWrite(Dest, CopyBuffer^, BytesCopied); { ...write chunk }
        until BytesCopied < ChunkSize; { until we run out of chunks }
      finally
        FileSetDate(Dest, FileGetDate(Source));
        FileClose(Dest); { close the destination file }
        {SetFileTimeStamp(Destination, TimeStamp); { clone source's time stamp }{!!!}
      end;
    finally
      FileClose(Source); { close the source file }
    end;
  finally
    FreeMem(CopyBuffer, ChunkSize); { free the buffer }
  end;
end;

The function HasAttr gives incorrect results when a file doesn't exist.

Description

In the FMXUtils unit (under the DEMOS\DOC\FILEMANEX subdirectory), the HasAttr function incorrectly suggests that a non-existent file has all attributes set rather than none.

Solution / workaround

By Dave Langstaff
The solution I found was to re-write HasAttr as follows:

function HasAttr(const FileName: string; Attr: Word): Boolean;
begin
   if FileExists(FileName) or DirectoryExists(FileName) 
   then Result := (FileGetAttr(FileName) and Attr) = Attr
   else Result := false;
end;

... adding FileCtrl to the uses clause of the implementation part.