10.1 Berlin tip: In FMX project, do not include FMX.Types before FMX.Forms!

10.1 Berlin tip: In FMX project, do not include FMX.Types before FMX.Forms!

program Project1;

uses
FMX.Types, // <-- problem
FMX.Forms,
Unit1 in 'Unit1.pas' {Form1};
//...
Application.Run;
end. // <-- breakpoint here.

The problem shows at application shutdown, when you hit F9 after stopping at breakpoint.

Access violation occurs is in this method:
destructor TPresentedTextControl.Destroy;

Happens in 32-Bit-Windows target. 64-Bit-Windows target is ok.

Can this type of error be found by static code analyses rule? Because it can be difficult to locate if you upgrade a big project from XE4 - where the problem does not show. Btw FMX.Types is needed to set GlobalUseDXSoftware flag.

Comments

  1. That's an interesting problem. DO you know how it causes the problem?

    ReplyDelete
  2. You can step into with F7. There is also a stack trace. It goes into FinalizeUnits ...

    ReplyDelete
  3. If you can reproduce this with a small app, can you enter it as a QP please?

    ReplyDelete
  4. FMX.Types added to project is the only line changed in new empty FMX project. I did not test on mobile (cannot) or OSX.

    destructor TPresentedTextControl.Destroy;
    var
    AccelKeyService: IFMXAcceleratorKeyRegistryService;
    begin
    FTextSettingsInfo.Free;
    //TPlatformServices.Current is nil !
    if TPlatformServices.Current.SupportsPlatformService(IFMXAcceleratorKeyRegistryService, AccelKeyService) then
    AccelKeyService.UnregisterReceiver(Root, Self);
    inherited;
    end;

    ReplyDelete
  5. These things has been riddling OP for years. When i had to punch at the VCL back when there was a similar problem with an Actions handling unit (can't remember witch) that the IDE left (ActionManager?) and then things started to go wrong. Units that "hogs" globals on initialization will sometimes produce this behaviour. But IHMO in a library such as FMX and at such low level that should be reported.

    ReplyDelete

Post a Comment