Hi,

change in mentioned FPC trunk r34087 totally breaks sparta dockedformeditor package (and probably many other things) see:

http://forum.lazarus.freepascal.org/index.php/topic,27211.msg216064.html#msg216064 http://bugs.freepascal.org/view.php?id=30377

please revert mentioned commit (what is sense for such change?).

For example problem exist in sparta_MainIDE.pas module:

=== code begin ===
constructor TDesignFormData.Create(AForm: TCustomForm);
begin
  FForm := AForm as IDesignedForm; // won't work anymore. FForm is an
interface
=== code end ===

Presumably, Sven has a reason for this change ?

For example, dynamic packages support may necessitate such a change. (just a wild guess)

If the change is needed, the right approach is to fix the bug that this change causes.

Michael.

Maciej Izak wrote

constructor TDesignFormData.Create(AForm: TCustomForm); begin FForm := AForm as IDesignedForm; // won't work anymore. FForm is an interface

I have not studied the context of this code but to me it looks suspicious. If such a typecast is needed then something is wrong in the code's design. An obvious idea is to change the AForm's type to IDesignedForm. My intuition says that Sven's commit only revealed some fishy code in sparta dockedformeditor.

Juha

AFAIU, unless the AForm ( a TCustomForm descendant which explicitly list IDesignedForm ) doesn't has the IDesignedForm in it's list of supported interfaces, then it's a bug in the compiler, because, AFAIU, the compiler is relying on this in order to implement the as cast, no ?

regards,

Dimitrios Chr. Ioannidis wrote

AFAIU, unless the AForm ( a TCustomForm descendant which explicitly list IDesignedForm ) doesn't has the IDesignedForm in it's list of supported interfaces, then it's a bug in the compiler, because, AFAIU, the compiler is relying on this in order to implement the as cast, no ?

Ok, true. Technically the compiler should accept such a cast.

Code design is another issue which should not be mixed here, although I still think there is something fishy in that specific use case. It could be implemented differently.

Juha

Just looked in the sources a little bit, and I saw that you use interface inheritance.

Never used that and searching on the net found the following http://stackoverflow.com/questions/14931940/casting-object-to-interface-type-with-no-tinterfacedobject-as-base-class.

The change is for Delphi compatibility maybe ?

Anyway, this is out of my league ....

regards,

2016-07-15 13:10 GMT+02:00 Juha Manninen :

Code design is another issue which should not be mixed here, although I still think there is something fishy in that specific use case. It could be implemented differently.

Change for the AForm's type to IDesignedForm is impossible in mentioned context. IDesignedForm means not only "TForm" but is used also to handle forms for TFrame and TDataModule. IDesignedForm is way to unify usage of TForm (which directly exist as form) and "form containers" for TFrame/TDataModule. Nothing wrong with that. Normal code -,- .

2016-07-15 12:18 GMT+02:00 Michael Van Canneyt :

If the change is needed, the right approach is to fix the bug that this change causes.

Fixed in Lazarus trunk r52691.
That was long standing Lazarus bug in JITForms (vmtIntfTable slot was equal 0). It was correct before FPC r34087 because was used FPC_EMPTYINTF instead of nil...

Ok, I believe this one is a difficult case because TForm, TFrame etc. don't have those interfaces. You have to stich them in afterwards somehow.

I myself learned that design with interfaces requires to turn all params and APIs to use interfaces.
It is not easy always.

Juha