Problem accessing array properties of strings

Description

By Jani Järvinen
Actually, it could be that this is documented somewhere (quick scan of manual and help file didn't help), but at least this is a interesting "feature" in the compiler:
If an array property is of type strings (like TStrings.Strings property), it is not possible to access individual characters in the property with the normal array access code. Instead, alternate code must be used.
Problem example:

   Type TMyArray = Array[1..2] of String;
   Var MyArray : TMyArray;
     ...
1:   If (MyArray[1,1] = 'A') Then ...      { this works }
2:   If (MyArray[1][1] = 'A') Then ...     { this works too }
     ...
3:   If (Memo1.Lines[1,1] = 'B') Then ...  { this doesn't work }
4:   If (Memo1.Lines[1][1] = 'B') Then ... { this works OK }

Above, normal arrays of strings can be accessed in two ways (1 and 2). However, string array properties can only be accessed with the case 4. Case 3 gives error message "Too many actual parameters".
Problem cause (supposition):
The compiler compares the array indices with the parameters of the read access method, and notices that there are too many parameters. However, the compiler forgets to check if the property type is an indexable type (like strings are). The other indexing method (case 4 above) is interpreted differently from case 3 inside the compiler and thus doesn't cause an error.

Solution / workaround

Use the method in case 4 above, or first assign the property value to a string variable, and then access the individual characters of the string.

Compiler now finds {$R ... } directives after END.

Description

This isn't a bug but a disappearance of an undocumented feature of all previous versions of TP/BP/DELPHI. All the previous compilers would stop after the "END." So you could copy portions of your code to past the end of the file and have a local backup. The compiler still only compiles till the first "END." but still searches the rest of the file for {$R ....}'s which then get included in the linking causing DUPLICATE RESOURCE Link Errors.

It is possible to call a function or procedure within a unit before the initialization section for that unit has been executed

Description

Reported by Scott Stephenson; checked by Arjen Broeze

It is possible to call a function or procedure within a unit before the initialization section for that unit has been executed, if the caller is within another unit's initialization section! This is a feature, not a bug, but it can cause some seriously perplexing problems.

How to reproduce the problem:
It tends to happen in complex projects, with very convoluted uses clauses. We found it in the Pannon-Rex objects unit, in which they set the root node of a stream registration list to nil in the initialization section. Unfortunately, the initialization was executed after another unit had already registered some streamable objects in that unit's initialization clause. So, the registered objects dropped into limbo, when the root node was reset to nil...

Why do you think it is a bug?
It's not a bug but a (bad) language design feature really. The basic message everyone needs to know is that you cannot count on a unit's initialization clause to execute before code in the unit is called. "Initialization" should be renamed "Not_really_initialization", in my modest opinion...

Solution / workaround

A very thorough remedy is:
Either avoid use of the initialization section altogether, or at least avoid placing code in an initialization section that makes calls beyond the scope of the declaring unit.
Andreas Prucha writes:
This problem does not happen if the units don't cross-use each-other. So you can keep using initalization sections and make calls beyond the scope of the unit. And even if they do cross-use, you can sometimes avoid the problem by changing the order in the USES clause of the project file, with the calling unit first

D4 generates wrong code for all TOleControl descendants (TXXXXControl = class(TOleControl): all function methods with parameters are generated incorrectly.

Description

Reported by Kiriakos Vlahos; checked by Hallvard Vassbotn

To reproduce the problem:
Import the Microsoft Script control and the Excel Type Library .

In importing the MS Script Control the following errors occur:

TScriptControl = class(TOleControl)
  ...
  function Get_Error: IScriptError;
    ...
    property IScriptControl_Error: IScriptError read      Get_IScriptControl_Error;
>>>  Should be Get_Error - causes compilation error

  ...
    function Run(const ProcedureName: WideString; var Parameters: PSafeArray; 
out pvarResult: OleVariant): OleVariant;
>>>  Argument out pvarResult: OleVariant should not be there.  The routine has only two arguments.

  ...
end;

Delphi 3 is importing the above unit correctly!

Also in importing the Excel Type Library a number or Excel collection objects, such as Workbooks, Worksheets etc. have default properties. The imported unit of Delphi 4 omits the "default" specifier of these propetries. Again Delphi 3 is handling this issue properly!

From checker:
At least the second problem (the added out parameter) has been confirmed by Inprise:

On Fri, 24 Jul 1998 11:25:36 -0700, in
borland.public.delphi.activex.controls.using "Alain Tadros"
 wrote:

>Hi Michael,
>Yes, it is a known problem for ActiveX Control wrappers in Delphi 4 and we
>are working on getting a fix out for it very soon.
>Sorry, I don't have an exact date for the release of the fix but very soon.
>Thanks
>Alain Tadros
>Delphi dev Team

Note: this was in reply to a message posted on the newsgroup by Michael Newton describing that same problem.
The other problems (the wrong method name and the default properties) have not (yet?) been confirmed independently.