The wish list has been moved to a separate page.

      Application.Initialize;

File time stamp of .dfm file not updated

Description

Reported by Reinier Sterkenburg

It happens that the Delphi IDE makes modifications to .dfm files but preserves the file date. One example of this is when you load a form that was made with Delphi 2. Delphi 3 then adds the property Font.Charset. When the .dfm file is saved (and no other changes are made), the file time stamp is not updated.

Bad watch of for loop index variable

Description

By John Brydon, checked by Duncan Murdoch
In some for loops (e.g. the loop index variable isn't referenced in the loop, or if it is just used to store data to successive entries in an array), the compiler will substitute a LOOP construct that executes the correct number of repetitions of the loop with a count downwards in the ECX register, even if the original loop was supposed to count upwards. This is perfectly acceptable; the code still does the same thing.

However, the debugger doesn't handle this well if you display the loop index variable in a watch window. Instead of calculating the correct value to display, it displays the value of ECX, making it appear that the loop is executed backwards.

Step-by-step instruction on how to reproduce the bug:

1. Compile a project with the following code attached to a button click event:

   procedure TForm1.Button1Click(Sender: TObject);
   var
     i, outbuffindex: integer;
     inbuffer, outbuffer: array[1..10] of integer;
   begin
     for i := 1 to 10 do
       inbuffer[i] := i;
     outbuffindex := 1;
     for i := 1 to 10 do
     begin
       OutBuffer[OutBuffIndex] := InBuffer[i];
       OutBuffIndex := OutBuffIndex +1;
     end; 
     showmessage(format('outbuffer=%d,%d,%d,...',
                        [outbuffer[1],outbuffer[2],outbuffer[3]]))
   end;

2. Put a breakpoint on the first line, and set a watch on the variables i, OutBuff, and OutBuffIndex. Single step through the code.

In the first loop, you'll see i counting up from 1 to 10 as expected. In the second loop, you'll see OutBuffIndex counting up, and i counting down, but OutBuffer will be filled correctly, and the showmessage will show that the right values ended up in the Outbuffer array.

Solution / workaround

Known workaround:
If you turn off optimization, then the transformation isn't made, so the value is displayed properly. However, this isn't a problem in the code, it's just a misleading display from the debugger, so this probably isn't worth doing.

Installing a tool in the IDE Tools menu: Delphi does not allow you to concatenate command-line macros into a single command-line parameter. (D1, D2, D3)

Description

By Patrick Philippot, checked by Chris Rankin

I want to install a tool in the IDE Tools menu. This tool is a text editor that can accept the follwoing command line syntax:
myeditor filename (col,row) - it then jumps to the specified line and column
or
myeditor filename col,row
This normally translates as follows when using the tool macros:
$EDNAME ($COL,$ROW) or $EDNAME $COL,$ROW
This just generates garbage or incomplete commands. By the way, this works perfectly in the BC++ Tools menu.
Note from checker: there are NO SPACES between $COL, the comma "," and $ROW

Solution / workaround

(PP): I also tried $EDNAME ($COL(),$ROW()) or $EDNAME() ($COL,$ROW) to no avail.

(CR): For good measure, I tried $COL+","+$ROW. This also failed. The only workaround I think of from here is to write a launcher program that accepts the parameters $EDNAME $COL $ROW and then converts $COL $ROW to (col,row) itself before calling the REAL tool program. I presume that this is a bug, since I can't find anything in the manuals saying that you CAN'T join macros together like this.

Browser occasionally misses overridden methods

Description

By David Bernstein, checked by Duncan Murdoch

Step-by-step instructions to reproduce the bug:

• Create a new project.
• Add a new unit to the project.
• Replace everything in the new unit from "Implementation" downwards with this code:

type
  TBase = class
  protected
    procedure Virt; virtual ;
    procedure Stat;
  end;

  TDerive = class (TBase)
  protected
    procedure Virt; override ;
    procedure Stat; // hide
  end;

implementation

procedure TBase.Virt;
begin
end;
procedure TBase.Stat;
begin
end;
procedure TDerive.Virt ;
begin
   inherited; // comment this out, and Virt will "reappear" in TBase
end;
procedure TDerive.Stat;
begin
   inherited; // comment this out, and Stat will "reappear" in TBase
end;

end.

• Compile and run the program, then quit from it.
• Put the cursor on TBase, click F10 to "browse symbol at cursor". At this point, the Virt and Stat methods won't show up.

Comment from checker: Sometimes the object browser doesn't show all the methods. This appears to be an intermittent bug; my first attempt to duplicate it showed no problem, my second attempt showed it.

Solution / workaround

You can browse TBase.Stat and TBase.Virt, and double clicking on Self will bring up the full listing for TBase. Minor changes to the code (like those in the comments above) will also make the methods show up.

When searching for a string without having text selected an error comes up: "Tried to search marked block but it is invalid".

Description

Reported by Jeroen Stolting

Whether you can call it a lifesize bug, I'm not sure, but it _can_ be irritating (especially if you encounter it for the first time, and have no idea what's going on):
When the previous search in the IDE is of type "scope : selected text", searching for a string without having text selected in the editor will generate the error "Tried to search marked block but it is invalid".

Solution / workaround

Manually setting the scope to global

After deleting the USES part from the .dpr source, the IDE can get confused.

Description

By Reinier Sterkenburg

After deleting the USES part from the .dpr source (e.g. when you make a simple console application), when you want to change the Project Options (choose menu item or speedbutton), Delphi issues an error: "Error in module Test209. USES clause is missing or incorrect." And it's not possible to access the project options anymore.
Similar problems occur in unit sources: it becomes impossible to add components to the form.

Solution / workaround

Add a dummy unit, set the project options the way you like and then delete the dummy unit again.

There are a few problems with inheritance from the repository.

Description

These problems only occur under Windows NT 3.51, and seem to have been fixed in Delphi 3

Clipping of inherited Dialog Form

Longer description follows

Order of menu items changed

Reported by Katy Mulvey, checked by Reinier Sterkenburg
If the parent form contains a TMainMenu, and the child form adds some items to the menu, the order of the menu items is changed when you view the form as text and then as a form again.

ImageList is initialized twice

Reported by Katy Mulvey, checked by Reinier Sterkenburg
Given a parent form contains a TImageList that has images in it, and a child form inheriting from the parent. At run-time, the child form will initialize the TImageList *twice*, and contain the wrong set of images (some will be repeated).

Clipping of inherited Dialog Form

Reported by various persons, checked by Reinier Sterkenburg

When using a Form that is inherited from a Dialog Form, its size is truncated to the size of its ancestor.
Steps to reproduce:

Start a new project

Choose New...from the File menu. Now the Repository appears.

Choose one of the Dialog froms from the Dialog tab (e.g. Standard dialog)

Check the "Inherit" radiobutton (in stead of the default: Copy) and click OK

Now change (increase) the Width or the Height property of the newly created form.

You'll see a very strange appearance of the window: only the upper left part of it is displayed, with the size limited to its ancestor's size.

The reports tell that this behaviour only occurs under Windows NT 3.51; under Windows 95 and NT 4.0 the behaviour is normal.

Solution / workaround

Not investigated; copying instead of inheriting probably works.

Find & Replace does not work correctly with backslash (\)

Description

The find and replace commands do not like the substrings \c, \d, \t, and \x. If you search for a string with any of these in it, Delphi will incorrectly report that it cannot find the string. If you are using regular expressions, Delphi will not treat the characters as literals as the documentation claims.

Solution / workaround

The search will perform correctly if you turn case sensitivity on, except for \c. This seems to search for the next word.

EXE size optimization causes problems

Description

When EXE optimization is turned 'on', one may get messages like:

      Cannot optimize (myprog.exe)
      File is not an .EXE file."

      Unable to rename (myprog).$$$ to (myprog).DPR

Solution / workaround

This is a workaround. Use the standalone app W8LOSS.EXE (in your bin directory) to optimize your EXE. Does the same thing, it just isn't as pretty (it's a DOS utility) or automatic.
Note: W8LOSS.EXE is only installed if you install the command-line compiler.

If there is code written in the initialization part of a unit (the BEGIN..END.) Delphi will stick automatically-created procedures in the begin..end part.

Description

If there is code written in the initialization part of a unit (the BEGIN..END.) Delphi will stick automatically-created procedures in the begin..end part.

Solution / workaround

You can solve this by using an INITIALIZATION..END. part for your initialization section (this is documented somewhere in the languages changes section of the on-line help).

It's possible to hang Delphi with awkward window sizing and "show compiler progress".

Description

Reported by Diego Canepa

To reproduce:

• Check SHOW COMPILER PROGRESS in the Options window
• Resize the source window to a size bigger than the compiler window
• Put your source window in the middle of the screen in normal size (not maximized, not minimized) in a position that totally overlaps the compiler window
• Force a compiler error anywhere in your code
• Minimize the source window
• Compile

The source window appears over the compiler window, which is in modal mode, so there's no way to click the Ok button in the compiler window!!!

Solution / workaround

In Windows 95:

Select tile horizontally or vertically from the window's task bar. Now you can see the compiler window!!!

In Windows NT:

Minimize and maximize (or vice versa) the Program Manager. Same effect. Or switch to another application with Alt-Tab and then back again.

Setting the TForm.ActiveControl property to a control which is not visible (e.g. on another tab sheet) makes it impossible to reload the Form after saving and exiting. Longer description

Description

By Jani Järvinen

When you create a form which has a Win 95 style TPageControl, and set the form's ActiveControl to a control which is no longer visible (on another tab sheet), Delphi fails to load the form completely the next time you try to load your project. Problem example:
Create a new project. On the form, drop a TPageControl component. Create two new TTabSheets on it. Create two TEdits, one on each tab sheet. Set the form's ActiveControl property to Edit1 (on either tab sheet). Be sure the tab sheet on which Edit1 is is active. Then save your project. Now close the project, and load it again. Everything is OK. Next, simply change the active tab sheet to the other one (on which Edit2 is). Save the project again, close it, and try to reload it. Delphi just informs you: "Error creating form: Cannot focus a disabled or invisible window."
The problem is that you cannot even view or edit the form anymore to set the original tab sheet back.

Solution / workaround

#1: Time to restore the backups... ;-)
#2: Open the Form file manually as text, and remove the line which sets the form's ActiveControl property:
Choose Open from the File menu. Choose to list only form files (*.dfm), and open the form which is causing problems. (Note that you must close the project causing problems, otherwise Delphi will try to show the form again.) The form will be shown as text. Remove the line which sets the ActiveControl property. Usually this is the 6th line in the file. Save the form, and re-open your project. Everything should be OK now.

Problem with the editor after a failed compilation in a special case.

Description

By Jani Järvinen

There's a problem with the editor after a failed compilation in a special case. If a line has an opening quotation mark, but no closing quotation mark, the editor is shifted one position too far to the left, causing the editor to misbehave.
Problem example:
Place the character ' (quotation mark) to its own line in your code. Compile the code, and you get two error messages: "Unterminated string" and "Missing operator or semicolon". Notice how the focus is shifted to the left. If you now try to select an area or scroll the screen, you notice bizarre effects in the left margin.

Solution / workaround

Try to avoid the situation. Normal behaviour can be returned by moving the cursor, minimizing the editor window and then restoring it back.

Cannot add Interfaces from included type libraries to a CoClass

Description

Reported by Kevin Smith; checked by Arjen Broeze

Steps to reproduce:

• Start Delphi 3
• Create a new ActiveX Library
• Add an ActiveX Type Library
• On the USES tab of the Type Library right click and "Show All Type Libraries"
• Select (check) another Type Library that has interfaces
• Create a new CoClass
• On the MEMBERS tab of the CoClass right click and "Insert Interface"
• Only interfaces defined in this type library are shown

Why is this wrong?
The manual states that all interface should be shown (Developers Guide, first paragraph of page 42-8) including those in the type libraries checked in the USES tab.
But you only get a list of interfaces declared in this type library. It may seem inconsequential in the generated pascal code but it is very important to the type library when you need to do OutOfProcess COM and Remote COM and expect the OS to do interface marshelling for you You can verify that the interfaces are available to this type library by creating an interface and drop down the parent interface list - all included interfaces are available here. Works in MIDL and imported MIDL.

Solution / workaround

The workaround (recommended by Borland) is to create an interface in your type library that descends from the interface you need to use (you don't need to add anything to it) - then insert this new interface into your CoClass
NOTE: if you want to be able to query for the ancestor interface you will still need to declare the ancestor interface _and_ the new interface in your objects class declaration. Like this:

    (* IMyDummy descends from IParent *)
    (* IMyDummy is defined in the type library for the current project *)
    (* IParent comes from some other type library *)
  type
    TMyObject = class( TTypedComObject, IMyDummy, IParent )

Another work around is to use MIDL - you can add your interfaces to the MIDL source and then import back into Delphi (and, yes, Delphi's type library editor will properly show all the interfaces in the MEMBERS tab of the CoClass)

If you have the Main Delphi windows (that is the one containing the menu, speedbuttons and component palette) positioned at the bottom of your screen and activate the fields editor of a Table or Query, (or I guess descendants as well), it appears off the displayable area.

Description

Reported by Brian Goldberg; checked by Reinier Sterkenburg

Actually, it is under the task bar, so if you "shrink" the taskbar, you will see it there, then you can move it to your visible screen area, and restore the taskbar. If you prefer to hide the taskbar when not active, or have it in a position other than the bottom, and position the Delphi window all the way at the bottom of the screen, the fields editor is unaccessible completely, although I presume it is somewhere on a non-displayable section of the screen. I am using D3.02 on Win NT, though I have seen this behaviour in all three releases of D3 on both NT and 95.

Certain watch expressions could crash the IDE while debugging.

Description

Reported by Ivan Zernovac; checked by Reinier Sterkenburg

It's easy to reproduce this problem:

var c,d:array[0..20] of char;
begin
  c:='Hello';
  d:='Hi';     // place breakpoint here and enter  c=d  in the watch
// list window. The Delphi will crash causing an access violation (under
// NT 4.0, I don't know whether it behaves the same way under Win95)

Various instabilities in Delphi 4 IDE

Description

Reported by various people

There are quite some reports about the Delphi 4 IDE giving Access Violations and other instabilities.
A few of these problems have been confirmed (see elsewhere on the IDE bugs page). But there are also some that have been attributed to bad video drivers or bad third party components, but they have been reported so frequently that I think it should be mentioned on the Delphi Bug List.

Until I get definitive confirmations of these cases, I will categorize them as a Gotcha (purple).

Please submit information you have on 'abnormal' IDE behaviour. (Also if you find the behaviour is correct on your machine; that may indicate the bug is not in Delphi but somewhere else).

Reported problems:

• (reported by various people on news:borland.public.delphi.non-technical)
  Positions of docked windows are not saved. (While Tools-Environment options-Preferences-Autosave options-Desktop is checked)
  Can anybody confirm that this problem is dependent on the video card / driver? I don't have this problem on my machine (ATI 3D Rage II).
• (reported by Rune Moberg)
  The D4 IDE is acting up on me sometimes. At one point I had to kill it, because it threw an Access Violation Exception every time I tried to close it down or if I tried to click on the view menu (no menu appeared, the access violation crept up immediately!) It complained about this happening in either coride40.bpl or crbide40.bpl. I'll see if I can provoke it so that it can be reproduced... (I think I had just processed bug #147 and had chosen "Close all files" when it struck)
• Reported by Reinier Sterkenburg
  (This happened only once): I clicked File-New Application and got an Access Violation at address 2403940C in module 'VCLIDE40.bpl'. Read of address 00000000. Before that had looked in the help files. I had also opened a help file outside the IDE.
• Problems with video drivers, by Paul Gallagher; see entry on the 'external causes' page
  

Some people get this error on exiting Delphi 4:
"A component named DockSite0 already exists."

Description

Reported by Larry Park (?); confirmed by several people on the newsgroups

When exiting Delphi 4 running under NT 4 with service pack #3, sometimes the following error occurs.:
"A component named DockSite0 already exists."
When I go back into Delphi 4, it had trashed my window settings.
This seems only to happen when you exit Delphi 4 without saving your project first and Delphi asks if you want to save your project and you answer 'yes'.

This error is not reproducible on all Delphi 4 installations, but too many people have reported this to occur to ignore this problem. Maybe they have certain settings in the IDE (certain docking configurations perhaps) that cause this problem. If anyone can narrow this down further, please let it know!

Components are not registered if the "Register" procedure is not spelled in mixed case

Description

Reported by Cary Moore; confirmed by several people on the newsgroups

If you have written a component that you weant to install in the component palette, using the "Register" procedure, this will not work if you spelled "Register" as "register" (or any other way different from "Register").
The 'project' will compile and the package will also be installed, but the component will not become visible in the component palette.

Additional information by Ray Quay:
What is happening is that this register procedure is not called during the install process, which means the registercomponent() procedure is not called to register the component. The IDE is using a case sensitive search through the units procedure table for a procedure called "Register".

Project group reverts to projectgroup1 when there's only one project in the group

Description

Reported by Franc v/d Westelaken; checked by Reinier Sterkenburg

To reproduce:

• Create a new project.
• Go to the project manager and save the project group file to a locaction.
• Close delphi and start it up again.
• Your last project is opened but the project group file is reverted to the delphi directory and has the name name: projectgroup1. You have to open your project group file manually.

If you add a second project to the project group the project group file is loaded normally when starting delphi.

Dragging radio items in the menu designer can cause an infinite loop

Description

Reported by Rick Beerendonk; checked by Reinier Sterkenburg

Reproducing the problem:
Every step described should be done in the menu designer. No code writing!

Create a main menu item with 2 sub menu items called smi1 and smi2. Both sub menu items will have the following properties:

Checked = True;
RadioItem = True;

The upper sub menu item (smi1) is given 'GroupIndex := 1' and smi2 gets 'GroupIndex := 2'. When we are done we drag smi2 to the first position. smi1 and smi2 should swap positions now, but instead we have an infinite loop.

Problem is also in the menu designer of popup menu's. Haven't checked what happens if you change positions runtime, but I expect the bug there too.

Don't panic when the bug occurs. You can still close the menu designer, except the changes will be lost.

Inprise Bugreport Nr: 21192

Users who place their Windows Task Bar in any position besides the bottom or right will notice that maximized code windows under the Delphi IDE will be incorrectly placed/positioned on the screen.

Description

Reported by Jim Rofkar; checked by Reinier Sterkenburg

To reproduce:

1. Move your Windows Task Bar to the top of the screen.
2. Start Delphi and load a project. Ensure the code window is visible.
3. Maximize the IDE code window.

Notice: The gap at the bottom of the screen where the maximized code window does not cover.

Cause:
It appears as though Delphi is automatically compensating for the height of the Windows Task Bar, but since it doesn't appear at the bottom of the screen (default), there's a gap when the code window is maximized.

This same problem is evident if you move your Windows Task Bar to the left edge of the screen. There, a gap appears along the right edge of the screen when the IDE code window is maximized.

Solution / workaround

Workaround:
Ensure you have your Windows Task Bar either located at the bottom or along the right edge of the screen.

Fix:
This is a fairly simple bug to resolve for Borland/Inprise. Simply check the position of the Windows Task Bar and adjust the maximized IDE code window appropriately. Instead, they assume it's going to be located either at the bottom or right edge of the screen.

A published property that is of type int64 does not show up in the Object Inspector.

Description

Reported by Brad Stowers; checked by DDJ-thread and newsgroups

To reproduce:
Install the following component and note that the IntSixtyFourTest property does not appear in the Object Inspector:

--------------TestComponent.pas--------------
unit TestComponent;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;

type
  TTestComponent = class(TComponent)
  private
    FIntSixtyFourTest: int64;
    procedure SetIntSixtyFourTest(const Value: int64);
    { Private declarations }
  protected
    { Protected declarations }
  public
    { Public declarations }
  published
    property IntSixtyFourTest: int64 read FIntSixtyFourTest write
SetIntSixtyFourTest;
  end;

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('Testing', [TTestComponent]);
end;

{ TTestComponent }

procedure TTestComponent.SetIntSixtyFourTest(const Value: int64);
begin
  FIntSixtyFourTest := Value;
end;

end.

Why I Think it is a Bug:
The Object Pascal Language Guide manual does not state that you can not publish int64 types. It does state that you can not publish Real48 types, so it should include int64 as well if that is not legal. Otherwise, it should be perfectly fine.

What's the Cause:
Unknown at this time. Perhaps run-time type information is not generated for int64 types, but I have not investigated this.

This has been validated by myself and several other people on the DDJ-Thread email list where I reported it, as well as on the borland.public.delphi.vcl.components.writing newsgroup.

Solution / workaround

None known.

A published property that is a double word type (longword or cardinal) allows only a signed 32-bit value (2147483648..2147483647) to be entered in the Object Inspector, not an unsigned 32-bit value (0..4294967295).

Description

Reported by Brad Stowers; checked by DDJ-thread and newsgroups

To reproduce:
Install the following component and try to enter an unsigned 32-bit value greater than a signed 32-bit value, i.e. 4294967295 in LWTest and/or CardTest. Also, enter a negative value -- that should not be allowed.

--------------TestComponent.pas--------------
unit TestComponent;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs;

type
  TTestComponent = class(TComponent)
  private
    FCardinalTest: cardinal;
    FLongWordTest: LongWord;
    procedure SetCardinalTest(const Value: cardinal);
    procedure SetLongWordTest(const Value: LongWord);
    { Private declarations }
  protected
    { Protected declarations }
  public
    { Public declarations }
  published
    property CardinalTest: cardinal read FCardinalTest write
SetCardinalTest;
    property LongWordTest: LongWord read FLongWordTest write
SetLongWordTest;
  end;

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('Testing', [TTestComponent]);
end;

{ TTestComponent }

procedure TTestComponent.SetCardinalTest(const Value: cardinal);
begin
  FCardinalTest := Value;
end;

procedure TTestComponent.SetLongWordTest(const Value: LongWord);
begin
  FLongWordTest := Value;
end;

end.

Why I Think it is a Bug:
The range issue is pretty obvious.

What's the Cause:
The TIntegerProperty property editor in the RTL is broken. It's defined in \Delphi4\Source\ToolsAPI\DsgnIntf.pas. It uses StrToInt and a local variable of type longint to do conversions. Both of those will force values entered to a longint range (signed 32-bit).

Solution / workaround

Ray Lischner was kind enough to post a fix for this problem in the borland.public.delphi.vcl.components.writing newsgroup. Install the following component into a package and all should work fine:

------------------FixedPropEd.pas-------------------
unit FixedPropEd;

interface

uses SysUtils, DsgnIntf;

type
  TFixedIntegerProperty = class(TOrdinalProperty)
  public
    function GetValue: string; override;
    procedure SetValue(const Value: string); override;
  end;

procedure Register;

implementation

uses Consts, TypInfo, Classes;

procedure Register;
begin
  RegisterPropertyEditor(TypeInfo(Cardinal), TPersistent, '',
     TFixedIntegerProperty);
end;

{ TFixedIntegerProperty }

function TFixedIntegerProperty.GetValue: string;
begin
  with GetTypeData(GetPropType)^ do
    // Is this an unsigned type?
    if MinValue > MaxValue then
      Result := Format('%u', [GetOrdValue])
    else
      Result := IntToStr(GetOrdValue);
end;

procedure TFixedIntegerProperty.SetValue(const Value: String);
var
  I: Int64;
  MinRange, MaxRange: Int64;
begin
  I := StrToInt64(Value);
  with GetTypeData(GetPropType)^ do
  begin
    if MinValue > MaxValue then
    begin
      MinRange := LongWord(MinValue);
      MaxRange := LongWord(MaxValue);
    end else begin
      MinRange := MinValue;
      MaxRange := MaxValue;
    end;

    if (I < MinRange) or (I > MaxRange) then
      raise EPropertyError.CreateFmt(SOutOfRange, [MinRange, MaxRange]);

    if MinValue > MaxValue then
      SetOrdValue(LongInt(LongWord(I)))
    else
      SetOrdValue(I);
  end;
end;

end.

This has been validated by myself and several other people on the DDJ-Thread email list where I reported it, as well as on the borland.public.delphi.vcl.components.writing newsgroup.

When you hit F1 or Ctrl-F1 for help in the editor, instead of seeking help on the word the cursor was over, you get help for whatever block was currently highlighted.

Description

Reported by Clinton R. Johnson

Those of use who use persistent blocks were obviously driven mad by this little "feature" - I'm happy to report that in D4.02, it has gone back to the old method of searching for help on the word the cursor is currently over.

Access Violation when adding project or form to Object Repository with delphi32.dro read-only

Description

Reported by Sergey Mishkovskiy

When delphi32.dro file is read-only, trying to add a project or form to Object Repository causes an access violation "Access violation at address 6E656900. Read of address 6E656900."

Steps to reproduce:

• make sure that delphi32.dro is read-only
• create a new project
• try to add either project or form to Object Repository
• you'll get an access violation

This is a bug because the IDE should issue an error message about delphi32.dro being read-only, in stead of giving an access violation.

Solution / workaround

Make delphi32.dro writable

The Align mechanism has become somewhat buggy

Description

Reported by Clément Doss; checked by Reinier Sterkenburg

To reproduce (design time):

1. Create a New Application
2. place a PageControl.
3. Set the align property to alClient
4. create a tabsheet
5. drop a Panel on it.
6. set its align property to alBottom.
7. Don't leave the IDE.. Click the PageControl and resize it (Top, bottom, left, right).

You can see the Panel moving (and resizing) to positions that are definitely not alBottom

The Code Insight can cause an Access Violation while typing in code. This does not happen frequently, but we have a simple reproducible case.

Description

Reported by Curt Christiansen; checked by Carl Caulkett

Typing the following code results in an Access Violoation in module DCC40.DLL:

  ShowMessage(IntToStr(Height))

The error occurs when the 't' of height is typed. When you press OK on the error dialog, you just return to the IDE and there seems to be no further damage.

Additional info by Clinton R. Johnson:
This bug only seems to appear when the tooltipwindow is visible, and the data is a property who's value is returned via a function instead of read directly from a variable.

Property Height: Integer Write SetHeight Read GetHeight;

Height, Width, PixelsPerInch, etc etc...
as opposed to :

Property Tag: Integer Read FTag Write FTag;

Properties such as Tag and HelpContext will not generate this error.

Problem with docking and 'hide designers on run'

Description

Reported by Fernand Raynaud; checked by Reinier Sterkenburg

Create a stacked docked toolbar layout on the left of the edit window:
Project Manager at top
Code Explorer at middle
Object Inspector at bottom

Run program w/ "hide designers" on.

Upon return the Object inspector is in a skinny vertical strip to the right of the other two.

Confirmed on:
D4 C/S, NT4SP3-S, IE302 + ComCT332
D4 Prof, NT4SP1

Saving a project as "default.dpr" can give serious trouble.

Description

Reported by Fernand Raynaud; checked by Reinier Sterkenburg

Steps to reproduce:
Create a new application.
Save it as project "default".
Run it. It's OK.
Exit Delphi.
re-Start Delphi.
I get a string of Access Violations, no way to start Delphi until the "default" project files are deleted.

Confirmed on:
D4 C/S, NT4SP3-S, IE302 + ComCT332
D4 Prof, NT4SP1

Solution / workaround

Delete the "default.*" files that have been created.

Watch Window mangled

Description

Reported by Sergey Mishkovskiy; confirmed by several people on the newsgroups

This is not really a very 'heavy' bug
To reproduce:

• start Delphi
• switch to code editor and make a right click
• select Evaluate/Modify from Debug menu
• New Value combo box will be cut off

Solution / workaround

This bug only appears once; if you close down Delphi and restart it, the combo/edit box is normal

It's difficult to find how to get the browser to show all (cross-)references

Description

Reported by Piotr Wozniak; checked by Reinier Sterkenburg

To see what's missing, you should do the following both in Delphi 4 and in Delphi 1:

1. Open project \demos\Ownerlst
2. Build all
3. choose View : Browser
4. choose Globals
5. use incremental search to find TForm1
6. press Enter
7. find the field Listbox1
8. Click References on the right
9. and ... you will see (in Delphi 4) only the place where Listbox1 was defined (in Delphi 3 there's no reference at all!). The 7 other occurrences in the source code (in Delphi 1) are not listed.

In the on-line help no information on the browser or on cross-references could be found.

Solution / workaround

It turns out that this is a matter of compiler options:
In Delphi 4, check the compiler option Reference info (Y) and uncheck the compiler option Definitions only (both in the debugging group). Then rebuild the application and try the procedure described above; now all cross-references will be listed.
In Delphi 3, the compiler option Symbol Info should be checked