AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Der XE8 Fehler-Thread

Ein Thema von Daniel · begonnen am 7. Apr 2015 · letzter Beitrag vom 27. Mai 2015
Antwort Antwort
Seite 20 von 25   « Erste     10181920 2122     Letzte »    
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.530 Beiträge
 
Delphi 11 Alexandria
 
#191

AW: Der XE8 Fehler-Thread

  Alt 9. Mai 2015, 16:58
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?

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.
Angehängte Dateien
Dateityp: zip DLLDemo.zip (65,1 KB, 4x aufgerufen)
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.194 Beiträge
 
Delphi 10.4 Sydney
 
#192

AW: Der XE8 Fehler-Thread

  Alt 9. Mai 2015, 17:08
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.


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.

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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.438 Beiträge
 
Delphi 12 Athens
 
#193

AW: Der XE8 Fehler-Thread

  Alt 9. Mai 2015, 17:24
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.530 Beiträge
 
Delphi 11 Alexandria
 
#194

AW: Der XE8 Fehler-Thread

  Alt 9. Mai 2015, 17:38
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.
  Mit Zitat antworten Zitat
mensch72

Registriert seit: 6. Feb 2008
838 Beiträge
 
#195

AW: Der XE8 Fehler-Thread

  Alt 9. Mai 2015, 18:38
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.
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.580 Beiträge
 
Delphi 11 Alexandria
 
#196

AW: Der XE8 Fehler-Thread

  Alt 9. Mai 2015, 18:57
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.029 Beiträge
 
Delphi 12 Athens
 
#197

AW: Der XE8 Fehler-Thread

  Alt 10. Mai 2015, 23:59
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.
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (11. Mai 2015 um 00:13 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#198

AW: Der XE8 Fehler-Thread

  Alt 12. Mai 2015, 15:18
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
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:
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)
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)

Geändert von Sir Rufo (12. Mai 2015 um 15:27 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Union
Union

Registriert seit: 18. Mär 2004
Ort: Luxembourg
3.492 Beiträge
 
Delphi 7 Enterprise
 
#199

AW: Der XE8 Fehler-Thread

  Alt 12. Mai 2015, 15:22
Zu den Problemen gibt es im QC 27 offene Reports.
Ibi fas ubi proxima merces
sudo /Developer/Library/uninstall-devtools --mode=all
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#200

AW: Der XE8 Fehler-Thread

  Alt 12. Mai 2015, 15:30
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 20 von 25   « Erste     10181920 2122     Letzte »    

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:26 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz