[bug] : Rad Studio 10.3.2 - Custom Component works fine with Tokio but not with Rio

[gioma 19]

I created a component and used it on a project that works great with Delphi Tokio (10.2.3).
When I opened the same project with Delphi Rio (10.3.2) instead I found a very strange problem.
The class that I have created derives from a TCustomScrollBox and has a TPanel a TRectangle, and a TTimer between the private objects which are then created at runtime in the create function of the class.
The problem is that when I open the project the form containing an object of that class immediately creates at designtime one objects ( TTimer) without a name. 
If I switch to displaying the form as textand then going back to the display as a form it creates TTimer again and it creates other two unnamed objects (TPanel and TRectangle)  (so each time it adds three unnamed objects).

code:

 

interface

TCustomClass = class(TCustomScrollBox)
private
	BitmapPanel: TPanel;
	CursorPanel: TRectangle;
    DragClickTimer: TTimer;
    ..
public
    constructor Create(AOwner: TComponent); override;
   ...
implementation

constructor TCustomClass.Create(AOwner: TComponent);
var
  k: TScrollCalculations;
begin
  inherited;
   ...
  BitmapPanel := TPanel.Create(self);
  BitmapPanel.Parent := self;
  BitmapPanel.OnPaint := BitmapPanelPaint;
  BitmapPanel.ClipParent := True;
  BitmapPanel.Enabled:=false;

  CursorPanel:= TRectangle.Create(self);
  CursorPanel.Parent := Self;
  CursorPanel.ClipParent:=True;
  CursorPanel.Fill.Kind:=TBrushKind.None;
  CursorPanel.Stroke.Kind:=TBrushKind.None;
  CursorPanel.OnPaint:=CursorPanelPanelPaint;
  CursorPanel.Enabled:=false;

  DragClickTimer := TTimer.Create(TFmxObject(AOwner));
  DragClickTimer.enabled := False;
  DragClickTimer.interval := 700;
  DragClickTimer.OnTimer := DragClickTimerTimer;

end;

 

This happens when I open the form containing an object of that class:

 

 

 

This is the code that generates when I switch to displaying the form as text:

 

    object mView: TRtcMobileDesktopViewer
      Touch.InteractiveGestures = [Zoom, Pan, TwoFingerTap, LongTap, DoubleTap]
      OnTap = mViewTap
      Anchors = [akLeft, akTop, akRight, akBottom]
      Position.X = 24.000000000000000000
      Size.Width = 647.000000000000000000
      Size.Height = 329.000000000000000000
      Size.PlatformDefault = False
      Viewport.Width = 647.000000000000000000
      Viewport.Height = 329.000000000000000000
      object TPanel
        ClipParent = True
        Enabled = False
        Size.Width = 647.000000000000000000
        Size.Height = 329.000000000000000000
        Size.PlatformDefault = False
        TabOrder = 0
      end
      object TRectangle
        ClipParent = True
        Enabled = False
        Fill.Kind = None
        Size.Width = 647.000000000000000000
        Size.Height = 329.000000000000000000
        Size.PlatformDefault = False
        Stroke.Kind = None
      end
    end
    object TTimer
      Enabled = False
      Interval = 700
  	end

 

 

Edited July 22, 2019 by gioma

[pyscripter 689]

Form serialization has been changed to become faster.  Maybe the changes introduced bug(s).

[gioma 19]

is there something wrong with my code?

[M.Joos 30]

I think your code did not work with  Delphi Tokio (10.2.3) either. You should set the stored property of your child components (Panel, Rectangle, Timer) to false. 

[gioma 19]

19 minutes ago, M.Joos said:

I think your code did not work with  Delphi Tokio (10.2.3) either. You should set the stored property of your child components (Panel, Rectangle, Timer) to false. 

You saved me. Now it works like a charm!
Thank you very much!

[M.Joos 30]

You're welcome. Glad it works now.

[M.Joos 30]

4 hours ago, pyscripter said:

Form serialization has been changed to become faster.  Maybe the changes introduced bug(s).

Do you have more details about what they changed to make serialisation faster?

[gioma 19]

nothing,

it works like a charm!

Edited July 22, 2019 by gioma
I was wrong

[Remy Lebeau 1397]

On 7/22/2019 at 7:50 AM, M.Joos said:

Do you have more details about what they changed to make serialisation faster?

Not specifically, someone will have to do a diff of the RTL source code between 10.3 and 10.3.2.  All the release note says is "VCL DFM files loading optimization".

[Uwe Raabe 2057]

1 hour ago, Remy Lebeau said:

someone will have to do a diff of the RTL source code between 10.3 and 10.3.2

I can think of TFieldCache in System.Classes replacing several expensive calls to FieldAddress.

[Remy Lebeau 1397]

1 hour ago, Uwe Raabe said:

I can think of TFieldCache in System.Classes replacing several expensive calls to FieldAddress.

Perhaps.  On the other hand, it turns out that the introduction of TFieldsCache in 10.3.2 has broken backwards compatibility with 10.3 RTM, so be careful:

Quote

This is turning to be more complicated than I expected. The scenario you described, whereby a package built w/ R103.2 does not work in R103 RTM is not in itself an issue. As I mentioned, we do add new APIs/types, and code that uses them is not expected to work w/ RTM runtime packages.

 

But your code is not explicitly using new Update #2 APIs, and yet it fails to run w/ RTM runtime packages. And, more interestingly, it’s explicitly referring to @System@Classes@TFieldsCache@$bcctr$qqrv. As soon as the team understood why that is the case, we also realized that we had a much worse problem: code built w/ RTM runtime packages will not work w/ Update #2 runtime packages.

 

Details
The scenario we want to support is this:, I install an app, A, built /w RTM runtime packages. Later I install another app, B, built w/ R103.2 runtime packages. The runtime packages from B overwrite the ones from RTM and both A and B still work. Right now A fails if run w/ the newer runtime packages - . And the reason is because A is unaware of the class constructor. The latter is never invoked… and you can imagine the rest.

 

The issue you reported and the one I described above are related to the same issue: adding class constructor/destructor to an update. Our backwards compatibility tests involves validating the hash of every RTM symbol in the update .dcu, and ensuring all entry-points previously exported are still exported. I suspect that we have never added a class constructor/destructor in an update before, which is why our tests does not explicitly look for them. And, as we are learning, they are problematic in an update.

 

We will be discussing more about this issue at tomorrow’s meeting, I suspect.

 

Cheers,

@bruneau.babet

 

 

[M.Joos 30]

On 7/24/2019 at 12:27 AM, Uwe Raabe said:

I can think of TFieldCache in System.Classes replacing several expensive calls to FieldAddress.

I have not installed 10.3.2 yet, so don't have the source code to look at TfieldCache. But yes it makes a lot of sense to cache the Field addresses of a class, as in a typical form loading scenario you have multiple instances of the same class, so that the expensive code to determine the Field address is not repeated over and over again.

Unfortunately  as Remy showed, this introduced some severe bugs, so I would expect a hot fix for 10.3.2 very soon. Hopefully they can fix TfieldCache rather than rolling back to the 10.3 approach for FieldAddress.

[Uwe Raabe 2057]

45 minutes ago, M.Joos said:

Hopefully they can fix TfieldCache rather than rolling back to the 10.3 approach for FieldAddress.

They move the code away from the class constructor into the initialization section and revert that in 10.4 for instance.

[M.Joos 30]

15 hours ago, Uwe Raabe said:

They move the code away from the class constructor into the initialization section and revert that in 10.4 for instance.

That sounds like a feasible fix. Let's wait and see what they come up with in a hot fix.

Edited July 26, 2019 by M.Joos