Ich habe gerade getestet:
Es liegt weder am Entladen der DLL beim Programmende noch an der Klasse als Parameter. Der Fehler tritt auch auf, wenn eine Prozedur ganz ohne Parameter aufgerufen wird, die ein Formular anzeigt, und wenn die DLL direkt nach dem Aufruf wieder entladen wird.

Ich habe das auch per Kommentar in dem Ticket ergänzt.

Ein flüchtiger Blick in den Stacktrace zeigt, dass dort ein paar Threads mit WaitForSingleObject warten, die offenbar aus DirectX Funktionen kommen.

Kann man erwarten, daß irgendwann das Codefolding richtig funktioniert?

In Verbindng mit {$LEGACYIFEND ON} und {$IF ...} hab ich jetzt den Fall, daß nach mehreren Verschachtelungen das Folding voll abdreht.
Genauer faltet es das {$IF xxx} bis zum {$ENDREGION} zusammen und schreibt [intern] hin und das obwohl IFs sonst nicht gefaltet werden.
Zwei/Drei Mal geht es und dann plötzlich nicht mehr.

zusammenfalten · markieren

Delphi-Quellcode:

  {$IF UseFeigCOM}

  TFeigCom = class(TFeigPort)
  {$REGION 'intern'}
  private
    ...
  {$ENDREGION}
  public
    ...
  published
    ...
  end;

  {$IFEND}

Auch schafft das Folding es immernoch nicht, einen \\\Doc-Kommentar oder eine Region vor dem unit xxx; zusammenzufalten.

Mit const myconst = {$IFDEF xxx}true{$ELSE}false{$ENDIF}; und manchmal auch {$IFDEF xxx}Winapi.{$ENDIF}Windows.Beep; kommt fast keiner klar. (der Compiler ja, aber weder Help Insight, noch Error Insight und externe Dinge, wie CodeParser, Refactoring, CodeFormating und Documentation Insight sowieso nie)



Wenn sich komische Zeichen (meistens vermutlich Linux-Zeilenumbrüche oder unsichtbare Steuerzeichen) in den Quellcode schleichen, dann verruscht immernoch das Folding und die Debuggerzeilenzählung.

Noch ein Fehlerchen in Verbindung mit dem iOS-Simulator

zusammenfalten · markieren

Delphi-Quellcode:

unit Form.Main;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.StdCtrls,
  FMX.Controls.Presentation;

type
  TForm1 = class(TForm)
    ToolBar1: TToolBar;
    toggleStatusBarButton: TSpeedButton;
    procedure toggleStatusBarButtonClick(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.fmx}

procedure TForm1.toggleStatusBarButtonClick(Sender: TObject);
begin
  if Self.BorderStyle = TFmxFormBorderStyle.None then
    Self.BorderStyle := TFmxFormBorderStyle.Sizeable
  else
    Self.BorderStyle := TFmxFormBorderStyle.None;
end;

end.

Ein paar mal auf dem Button gesteppt und wenn man Glück hat kommt nur das hier
iOS Simulator Screen Shot 12.05.2015 15.15.35.png
oder die App stürzt einfach sang und klanglos ab.

Nachtrag:

Unter Android geht das nur, wenn man das in dem originalen UIThread ausführt:

zusammenfalten · markieren

Delphi-Quellcode:

uses
  FMX.Helpers.Android;

procedure TForm1.toggleStatusBarButtonClick( Sender: TObject );
begin
  CallInUIThread(
    procedure
    begin
      if Self.BorderStyle = TFmxFormBorderStyle.None then
        Self.BorderStyle := TFmxFormBorderStyle.Sizeable
      else
        Self.BorderStyle := TFmxFormBorderStyle.None;
    end );
end;

stürzt dort aber genauso ab - ok, gefühlt häufiger (getestet auf einem echten Device)

Zu den Problemen gibt es im QC 27 offene Reports.

Zitat von Union:

Zu den Problemen gibt es im QC 27 offene Reports.

Auf die Schnelle habe ich da keinen gefunden der dazu passt ... anyway am Besten die StatusBar eingeblendet lassen und den BoderStyle niemals anfassen.

Mit XE8 funktioniert der Kompass-Sensor nicht mehr. Ist das nur auf meinem System so?
Sensor.HeadingX/Y/Z geben immer 0 zurück.