Jump to content
gioma

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

Recommended Posts

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:

 

Error.png.097f114159775e5c796567c54a4df35e.png

 

Error1.png.1e53f07448d1c5cdbb14281131262912.png

 

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 by gioma

Share this post


Link to post

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

Share this post


Link to post

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. 

  • Thanks 1

Share this post


Link to post
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!

Share this post


Link to post
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?

Share this post


Link to post

nothing,

it works like a charm!

Edited by gioma
I was wrong

Share this post


Link to post
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".

Share this post


Link to post
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.

Share this post


Link to post
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 - :frowning: . 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

 

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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 by M.Joos

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×