Der XE8 Fehler-Thread

[Bernhard Geyer]

Zitat:

Zitat von Daniel (Beitrag 1300025)

Nochmals:
Es geht mir in diesem Thread um reproduzierbare Fehler in XE8 und mögliche Lösungen dazu.
Fachsimpeleien über Preise und Paragraphen bitte woanders.

Diese Anweisung hat keine 6 Stunden gehalten :roll:

Könntest du nicht einen Thread aufmachen der "Mängel und deren Rechtliche Konsequenzen im Vertrag" als Titel hat und die letzten Posts dorthin verschieben?
Und jeder der nach diesem Abspalten damit wieder anfängt in diese Richtung abzuschweifen rigoros den Beitrag löschen?
Ansonsten mach ich einen "XE8 Fehler und Workaround - Keine Juristische Diskussion"-Thread auf...

[mquadrat]

Einfach ein paar Tage warten, dann hat sich das tot gelaufen..

[Chemiker]

Hallo Stevie,

ich habe mit „BDS / NOCASTALIA“ Delphi gestartet aber der Fehler erscheint weiterhin, bei den anderen Demos kommen ja Files dort kommt keine Fehlermeldung. Ich will jetzt auch nicht zu viel Zeit investieren, es gibt ja unter den DEMOs unter "\Object Pascal\RTL\Parallel Library\" ein Beispiel Project.

Bis bald Chemiker

[mensch72]

- stat NOCASTALIA funktioniert bei mir die Methode mit dem Unterstrich vor dem Namen als Registrypatch zur Abschaltung besser
- mit der vollen TMS Ladung war OutOfTheBox anfänglich die Formular/Code Umschaltung in der IDE sehr langsam, mit TLIST<> Patch und den FixPack Sachen von Mr. Hausladen geht es jetzt
- cnpack hat bei mir keinen negativen Einfluss auf Speicher oder Stabilität
- Mr. Hausladens FixPack usw. ist also wieder Pflicht

Da Emba bei einigen Demos im Auslieferungszustand der ISO keine glückliches Händchen hatte, gibt es ein SVN wo man besser jetzt einen aktuellen SnapShot aller Demos zieht und diese verwendet.

http://docwiki.embarcadero.com/CodeE...ategory:Sample
http://sourceforge.net/p/radstudiode.../RadStudio_XE8

[Daniel]

Zitat:

Zitat von mensch72 (Beitrag 1300075)

Da Emba bei einigen Demos im Auslieferungszustand der ISO keine glückliches Händchen hatte, gibt es ein SVN wo man besser jetzt einen aktuellen SnapShot aller Demos zieht und diese verwendet.

Das ist ein guter Hinweis. Vielleicht noch ergänzend / erklärend: Hat man einen SVN-Client (wie etwa Tortoise) installiert, kann man den Demo-Ordner mit der rechten Maustaste anklicken, um die aktuellen Demos abzurufen.

[himitsu]

Alle Demos in eine Projektgruppe und man könnte das theoretisch auch, ohne ein externes Programm, direkt über die Projektverwaltung updaten (auschecken).

(Ich würde mir dafür aber wünschen, man könnte in der Projektverwaltung die Projekte gruppieren)

[Sir Rufo]

Nach dem neuen Hotfix kann man ja auch den iOS-Simulator benutzen und dabei fiel mir das hier auf die Füße:
Anhang 43093

Delphi-Quellcode:

  InputQuery( 'Nutzer', 'Name:', '',
    procedure( const AResult: TModalResult; const AValue: string )
    var
      LItem : TListViewItem;
    begin
      if ( AResult <> mrCancel ) and ( AValue) then
      begin
        LItem := NutzerListe.ListView.Items.Add;
        LItem.Text := AValue;
      end;
    end );

Ja und wenn der Nutzer nach der Eingabe einfach mal return auf der virtuellen Tastatur drück, dann hat

Delphi-Quellcode:

AResult

den Wert

Delphi-Quellcode:

2

, was genau dem Wert von

Delphi-Quellcode:

mrCancel

entspricht.

Ich hätte hier jetzt eher ein

Delphi-Quellcode:

mrOK

erwartet ...

[Union]

Du bekommst den Integer von ModalResults und nicht den ModalResult selber :kotz:

Delphi-Quellcode:

  ModalResults: array[TMsgDlgBtn] of Integer = (mrYes, mrNo, mrOk, mrCancel, mrAbort, mrRetry, mrIgnore, mrAll,
    mrNoToAll, mrYesToAll, 0, mrClose);

[Sir Rufo]

Zitat:

Zitat von Union (Beitrag 1300435)

Du bekommst den Integer von ModalResults und nicht den ModalResult selber :kotz:

Delphi-Quellcode:

  ModalResults: array[TMsgDlgBtn] of Integer = (mrYes, mrNo, mrOk, mrCancel, mrAbort, mrRetry, mrIgnore, mrAll,
    mrNoToAll, mrYesToAll, 0, mrClose);

Was ich kriege ist mir ja egal, nur eben nicht das Gleiche wenn ich auf Abbrechen drücke und genau das bekomme ich zurück.

In

Delphi-Quellcode:

AResult

finde ich eine

Delphi-Quellcode:

2

egal ob ich auf Abbrechen drücke oder auf return.

[Daniel]

Ist Return nicht das neue Escape?

Ich setze Dein Beispiel ins Quality-Portal, sofern es dort noch nicht drin ist.

[Sir Rufo]

Zitat:

Zitat von Daniel (Beitrag 1300445)

Ist Return nicht das neue Escape?

Ich setze Dein Beispiel ins Quality-Portal, sofern es dort noch nicht drin ist.

Das Problem ergibt sich auch nur bei iOS:

• Windows: Enter-Taste -> Dialog schließt und
  Delphi-Quellcode:

  AResult = mrOK

• OSX: Enter-Taste -> Dialog schließt und
  Delphi-Quellcode:

  AResult = mrOK

• Android: OK-Taste (Virtual Keyboard) -> virtuelle Tastatur verschwindet (Nun ja, nichts ist immerhin besser als falsch)

[Union]

Hast Du es mal so versucht:

Delphi-Quellcode:

InputQuery( 'Nutzer', ['Name:'], [''],
    procedure( const AResult: TModalResult; const AValues: array of string)
    var
      LItem : TListViewItem;
    begin
      if ( AResult <> mrCancel ) and (AValues[0] <> '') then
      begin
        LItem := NutzerListe.ListView.Items.Add;
        LItem.Text := AValues[0];
      end;
    end );

Bei der Cocoa-Implementierung kann man nämlich die TInputCloseQueryFunc übergeben, doch leider wird die nicht an den Delegate übergeben (konstant *nil*). Denn der akzeptiert nur TInputCloseQueryProc im constructor.

[Daniel]

@SirRufo: Danke für die Tests auf den anderen Plattformen.

EMBT hat sich der Sache angenommen (Ticket ist einem Entwickler zugewiesen). Ich rechne damit (lies: "hoffe inständig darauf"), dass diese Korrektur in Update #1 enthalten sein wird.
https://quality.embarcadero.com/browse/RSP-11101

@Union: Getestet habe ich es noch nicht, denke aber, dass auch diese Variante einen falschen Wert für ModalResult liefern wird.

[Darlo]

Hallo zusammen,

ich habe ein Projekt von XE7 auf XE8 umgezogen und wollte in diesem Zug auch "sauberer" mit den Styles arbeiten.
Habe gefühlt 100 Labels umgestellt, das Ergebnis es wird nicht gespeichert....

Anbei ein Video zur Verdeutlichung.
Könnte gerade :kotz:

[Harry Stahl]

@darlo:

Habe gerade mal unter XE7 eine Form erstellt mit TTabControl, TLayout und darein ein TLabel gelegt, einen Style in ein StyleBook geladen und Styledsettings ausgeschaltet. Dann Projekt nach XE8 übernommen, die Optionen in StyledSettings alle aktiviert und gespeichert und wieder geladen. Hat dauerhaft gespeichert.

Kannst Du eine Form isolieren und hier zum Download bereitstellen, so dass man sich das einmal näher ansehen kann?

[Darlo]

Hi Harry,

gerne, anbei ein Beispiel-Projekt. Bin ja gespannt was der Styleexperte hier im Forum herausfindet ;-)

[Darlo]

Wenn ich in der Formularansicht als Text folgende Zeilen der betroffenen TLabels entferne funktioniert es:

Code:

            StyledSettings = [Family, Style, FontColor]
            TextSettings.Font.Family = 'Georgia'
            TextSettings.Font.Size = 22.000000000000000000

[Harry Stahl]

Ja, hier ist eindeutig ein Bug in XE8 drin. Immer wenn in Textsettings in den Einträgen zu Family ODER Size ein anderer Wert als Default steht, dann werden NICHT die Einstellungen des Styles verwendet, sondern eben diejenigen, die unter Textsettings stehen.Gleichzeitig werden beim Laden der Form dann unter StyledSettings die entsprechenden Einstellungen deaktiviert.

Dummerweise kann man zwar unter Textsettings "Family" manuell im Objektinspektor auf Default setzen, nicht aber "Size".

Man muss also tatsächlich manuell die Form-Datei editieren und Size entfernen.

Das ist ja echt ein blöder Bug!:evil:

[Kralle]

Moin,

also wenn ich mir diesen Thread so durch lese frage ich ich mich warum man jetzt auf XE8 gehen sollte?!
Sollte ich diesen Thread mal provokanterweise Dienstag mit nach Hamburg zur Roadshow nehmen :?:

Gruß Heiko

[himitsu]

Na wegen der coolen neuen Features?
http://www.delphipraxis.net/184977-c...ease-date.html

Und wer für iOS entwickelt ist sowieso zum Upgrade gezwungen, inkl. Installation der Fixpacks.

[Harry Stahl]

So, den Bug habe ich mal gemeldet:

https://quality.embarcadero.com/browse/RSP-11123

Die Behebung sollte m.E. auf jeden Fall noch ins Update 1 rein.

[Kralle]

Moin,

Zitat:

Zitat von himitsu (Beitrag 1300762)

Na wegen der coolen neuen Features?
http://www.delphipraxis.net/184977-c...ease-date.html

Naja ..

=== Off Topic =====

Zitat:

Zitat von himitsu (Beitrag 1300762)

Und wer für iOS entwickelt ist sowieso zum Upgrade gezwungen, inkl. Installation der Fixpacks.

Wer entwickelt denn für iOS wenn er es nicht unbedingt muss?
So mal ebend eine vorhandene Anwendung auf iOS kompilieren ist ja eh nicht.
Man braucht einen Mac zusätzlich zum PC.
Okay, für Android braucht man auch ein Android-Gerät, wird aber nicht genötigt seine Anwendungen über den Apple-Store zu vertreiben.
Aber wir schweifen ab..
==================

Gruß Heiko

[Harry Stahl]

Und weil es soviel Spaß macht, Fehlerreports zu schreiben(:(), gleich noch einer:

VCL-App calling a FMX-DLL hangs on FreeLibrary (DLLHandle)

https://quality.embarcadero.com/browse/RSP-11125

Fehler betrifft allerdings auch schon XE7, wie ich nun feststellen musste.

[Bernhard Geyer]

Zitat:

Zitat von Harry Stahl (Beitrag 1300788)

Und weil es soviel Spaß macht, Fehlerreports zu schreiben(:(), gleich noch einer:

VCL-App calling a FMX-DLL hangs on FreeLibrary (DLLHandle)

https://quality.embarcadero.com/browse/RSP-11125

Fehler betrifft allerdings auch schon XE7, wie ich nun feststellen musste.

Also du übergibst lebende Objekte über DLL-Grenzen ohne mit gemeinsamen Laufzeitbibliotheken zu arbeiten?
Falls ja (kenn jetzt nicht jede Option in der dproj-Datei) war das eher zufall das das funktioniert hat aber nix was man erwarten sollte. Lebende Objekte über DLL-Grenzen ohne gemeinsame Laufzeitbibliothek zu verwenden ist ein NoGo.

[Harry Stahl]

Was meinst Du mit "gemeinsamen" Laufzeitbibliotheken in Verbindung mit einer VCL-APP, welche eine FMX-DLL verwendet?

[jaenicke]

Wenn du eine DLL ohne gemeinsame Laufzeitpackages benutzt, hat die DLL nicht die gleichen Klassen, globale Variablen, usw. wie deine Anwendung. Deshalb funktioniert is und as usw. auch nicht.
Ohne Laufzeitpackages kannst du dann nur einfache Variablen und Interfaces in deinen DLL-Schnittstellen benutzen. (Und mit Sharemem theoretisch auch Delphistrings, ich würde es aber nicht machen.)

Objekte zu übergeben ist, selbst wenn es zufällig funktioniert, aber auch schon deshalb nicht schön, weil die DLL dann erzwungenermaßen mit der gleichen Delphiversion kompiliert sein muss. Eine standardkonforme DLL hingegen kannst du auch mit einer neuen Anwendung verwenden (und auch von anderen Sprachen wie C# aus).

Statt TMemoryStream würde ich daher z.B. IStream verwenden, besser noch aber ein eigenes Interface, da ich gerade erst feststellen musste, dass sich diese Standardinterfaces in Delphi ebenfalls ändern...

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1300797)

Wenn du eine DLL ohne gemeinsame Laufzeitpackages benutzt, hat die DLL nicht die gleichen Klassen,

Darum geht es doch nicht... In der DLL ist doch die Laufzeitumgebung von FMX drin...

Somit kannst Du in Deiner VCL-Anwendung - "geile FMX Formulare" oder andere Fancy-FMX Features nutzen...

[Harry Stahl]

Als einzige gemeinsame Klasse verwende ich TMemoryStream. Diese stammt aus System.classes und wird sowohl von der VCL als auch von FMX verwendet.
Wenn ich also sowohl VCL-APP und FMX-DLL mit der gleichen Delphi-Version kompiliere, sollten technisch gesehen keine Probleme auftauchen.

Von der Funktionalität funktioniert ja auch alles, wie gewünscht.

Nur eben das entladen der FMX-DLL eben nicht.

Auch bei dem Beispiel, das EMBA mal selber für den VCL to FMX-DLL Access veröffentlicht hat, funktioniert nicht das Entladen der DLL.

Hier muss also ein Problem in Delphi XE7/XE8 liegen.

Wenn ich die DLL mit Delphi <= XE6 kompiliere, klappt es auch mit den entladen der DLL, auch wenn ich die VCL-App mit XE7 oder XE8 kompiliert habe.

[Sir Rufo]

Auch wenn die beiden Klassen aus der gleichen Unit stammen, sind die Klassen in der EXE und DLL anders und du darfst die nicht einfach so übergeben. Was geht wäre das Übergeben eines Pointers auf den Speicherbereich oder wenn du alles in ein Interface kapselst.

Alles andere führt zu komischen Ergebnissen.

Ob es da trotzdem ein Problem mit XE7/XE8 gibt kann man also pauschal nicht sagen, erst wenn man alles richtig gemacht hat und es nicht funktioniert, dann kann man von einem Fehler sprechen.

Die Beispiele von Emba sind auch nicht als Perlen der Programmierung bekannt, daran würde ich gar nichts messen.

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1300822)

Die Beispiele von Emba sind auch nicht als Perlen der Programmierung bekannt

Die findet man übrigens hier: Programming Pearls

[Harry Stahl]

Zitat:

Zitat von Sir Rufo (Beitrag 1300822)

Auch wenn die beiden Klassen aus der gleichen Unit stammen, sind die Klassen in der EXE und DLL anders und du darfst die nicht einfach so übergeben.

Inwiefern sind die Klassen anders? Also z.B. hier der TMemoryStream?

Zitat:

Zitat von Sir Rufo (Beitrag 1300822)

Alles andere führt zu komischen Ergebnissen.

Ich hatte bislang (also bis Delphi XE6 bzw. Kombination aktuelle Delphis + DLL <= XE6) in der Verwendung VCL-APP zu FMX-DLL keine komischen Ergebnisse, sondern nur funktionierende Programme. Außerdem möchte ich noch mal festhalten, dass es "nur" um das Entladen der DLL geht. Aufruf der DLL, Übergabe und Rückgabe von Daten funktioniert alles ordnungsgemäß.

Habe grade mal eine FMX-DLL erstellt, die nur eine Procedure "ShowAForm" exportiert (also ohne Parameter). Ihre einzige Aufgabe ist dann, wenn aufgerufen, eine leere FMX-Form anzuzeigen.

Also NULL Thema von wegen falscher Datenübergabe oder so. Und siehe da: Bei Freelibrary hängt das Programm.

Wer das immer noch nicht glauben mag: Ich habe diese Demo (XE8-Version) hier mal angehängt (Zuerst FMXFilters.dpr kompilieren = die FMX-DLL) und dann die MyDLLDemo.dpr kompilieren (= die VCL-App).

Wer hier etwas findet, das programmtechnisch falsch ist, ich lasse mich gerne eines Besseren belehren... aber momentan sieht das für mich nach einem BUG aus.

[Bernhard Geyer]

Zitat:

Zitat von Harry Stahl (Beitrag 1300836)

Zitat:

Zitat von Sir Rufo (Beitrag 1300822)

Auch wenn die beiden Klassen aus der gleichen Unit stammen, sind die Klassen in der EXE und DLL anders und du darfst die nicht einfach so übergeben.

Inwiefern sind die Klassen anders? Also z.B. hier der TMemoryStream?

Probier doch einfach mal mit is bzw. as zu arbeiten.
Dann bekommst du den hier schon gefühlt Tausend mal gemeldeten Fehler

"Im Projekt Test.exe ist eine Exception der Klasse EConvertError mit der Meldung 'TPngImage kann nicht zu TPicture zugewiesen werden' aufgetreten."

(Wobei die Klassennamen unterschiedlich sind). Dort wurde auch schon tausend mal erklärt wieso das Auftritt wenn man ohne Runtimepackages arbeitet und versucht Instanzen zwischen DLL und Exe auszutauschen.

Zitat:

Zitat von Harry Stahl (Beitrag 1300836)

Zitat:

Zitat von Sir Rufo (Beitrag 1300822)

Alles andere führt zu komischen Ergebnissen.

Ich hatte bislang (also bis Delphi XE6 bzw. Kombination aktuelle Delphis + DLL <= XE6) in der Verwendung VCL-APP zu FMX-DLL keine komischen Ergebnisse, sondern nur funktionierende Programme.

War mehr oder mindern Zufall. Wir hatten auch vor Jahren so eine DLL-Konstrukt im Einsatz. Und hatten "funktionierende" Programme die halt ab und zu sich komisch verhalten haben.
Als wir das DLL-Konstrukt raus geschmissen hatten verschwanden auch dieses "komische Verhalten" von der wir nicht genau zuordnen konnten woher es kommt.

Zitat:

Zitat von Harry Stahl (Beitrag 1300836)

Habe grade mal eine FMX-DLL erstellt, die nur eine Procedure "ShowAForm" exportiert (also ohne Parameter). Ihre einzige Aufgabe ist dann, wenn aufgerufen, eine leere FMX-Form anzuzeigen.

Also NULL Thema von wegen falscher Datenübergabe oder so. Und siehe da: Bei Freelibrary hängt das Programm.

Wer das immer noch nicht glauben mag: Ich habe diese Demo (XE8-Version) hier mal angehängt (Zuerst FMXFilters.dpr kompilieren = die FMX-DLL) und dann die MyDLLDemo.dpr kompilieren (= die VCL-App).

Wer hier etwas findet, das programmtechnisch falsch ist, ich lasse mich gerne eines Besseren belehren... aber momentan sieht das für mich nach einem BUG aus.

Das könnte auf das Thema "niemals VCL und FMX in einem Programm verwenden" hinauslaufen. Wenn das aber in Exe/DLL ohne Runtimepackages verpackt ist sollte es trotzdem funktionieren.
DAS würde ich auch als Fehler ansehen.

[Uwe Raabe]

Zitat:

Zitat von Harry Stahl (Beitrag 1300836)

Und siehe da: Bei Freelibrary hängt das Programm.

Könnte auch der hier sein: FMX Forms inside a DLL or BPL cause Access Violation when FreeLibrary is called or crash

Komisch, daß das wohl gerade bei XE6 nicht auftritt.

[Harry Stahl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1300841)

Könnte auch der hier sein: FMX Forms inside a DLL or BPL cause Access Violation when FreeLibrary is called or crash

Komisch, daß das wohl gerade bei XE6 nicht auftritt.

Ja, das ist ja so ziemlich der identische Sachverhalt.

[mensch72]

Das Beispiel mit der "Procedure ShowAForm" sollte so gehen, weil es eben doch nur ein simpler Call ohne Parameter Übergabe/Rückgabe ist.

Wir arbeiten weil oft auch von C/C++ kommend und eine alte Hauptapplikationen noch in D7 recht viel mit XE2..XE8 DLL's für aktuelle Erweiterungen.

Aber wir arbeiten da strikt nach dem Prinzip: Aufruf einer XE? DLL wie aus einer Fremdsprache/Fremdanwendung.
Der einzige manchmal nötige Trick ist eigentlich, in einer DLL TApplication teilweise selbst etwas weiter zu initialisieren, damit eine DLL beim FormCreate was sinnvolles zum übergeben hat.

- nur Funktionen und keine Procedures, also immer mit einem UINT32/INT32 als Rückgabe
- Funktionen ohne weiter Übergabeparameter erlaubt
- Objekte/Klassen als Übergabeparameter sind nicht erlaubt
- DelphiBoolean als direkter Übergabeparameter ist nicht erlaubt, wir verwenden UINT32 und es gilt C konform UINT32=0 für "False" und UINT32<>0 für "True" (meist "1")
- Bei Übergabe Parametern verwenden wir nur Standardtypen klar definierter Größe INT32,UINT32,INT64,UINT64,double,PAnsiChar,PWideCh ar,PBytes,PWord,PDWord,PQWord,(P)PackedRecords
- um den Stack nicht mit großen Records auf zu blähen, über geben wir bei alles was größer wie 8Bytes als Pointer
- Das aufrufende Programm stellt stets den Speicher zur Verfügung, oder in Ausnahmefällen die DLL allokiert den Speicher mit Nativ-Funktionen der WinAPI, damit das Aufrufende Programm diesen auch wieder per Nativ-Funktionen der WinAPI freigeben kann
- Für DLL Funktionen mit "Textparametern" halten wir uns an das WinAPI-Schema, es gibt getrennte Funktionen(A&W) für NonUnicode und UniCode, welche mit PAnsiChar oder PWideChar arbeiten und zusätzlich immer einen Parameter der max. Größe, damit auch die Rückgabe sicher begrenzt werden kann
- Records in den Übergabeparametern werden möglichst per Pointer übergeben und haben eine fixe Größe sowie sind stets als "Packed Record" definiert
- Arrays werden als Pointer mit separatem Längenparameter übergeben

Aus Prinzip sind das sogar noch nach ganz alten Regeln für Win32API C Anwendungen, aber unter Beachtung dieser Regeln funktionieren aktuelle VCL und FMX Dlls aus XE2..XE8 eigentlich in jedem Programm und in jeder Programmiersprache, wo externe DLL's aufgerufen werden können.
Der Kontrolltest mit XE? DLL Aufruf aus einem D7 oder C Programm zum Test hat sich bewährt, den da fällt ganz schnell auf, ob absichtlich oder unabsichtlich doch etwas Delphi spezifisches übergeben wurde.

[jaenicke]

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.

[himitsu]

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

In Verbindng mit

Delphi-Quellcode:

{$LEGACYIFEND ON}

und

Delphi-Quellcode:

{$IF ...}

hab ich jetzt den Fall, daß nach mehreren Verschachtelungen das Folding voll abdreht.
Genauer faltet es das

Delphi-Quellcode:

{$IF xxx}

bis zum

Delphi-Quellcode:

{$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.

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

Delphi-Quellcode:

unit xxx;

zusammenzufalten.

Mit

Delphi-Quellcode:

const myconst = {$IFDEF xxx}true{$ELSE}false{$ENDIF};

und manchmal auch

Delphi-Quellcode:

{$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.

[Sir Rufo]

Noch ein Fehlerchen in Verbindung mit dem iOS-Simulator

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
Anhang 43158
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:

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)

[Union]

Zu den Problemen gibt es im QC 27 offene Reports.

[Sir Rufo]

Zitat:

Zitat von Union (Beitrag 1301212)

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.