Datamodule wird zu Formular

[OlafSt]

Hallo Freunde,

ich hatte zu diesen Thema schon einmal einen Thread erstellt, doch der ist verschwunden... Vermutlich, weil ich dachte, Problem sei gelöst. Ist es aber nicht, weder in D2010 noch in XE4 (auf das sich mein Thread damals bezog) und auch in XE7 nicht.

Folgende Konstellation:

- Ein Datenmodul, genannt TBaseDM. In diesem befinden sich eine ganze Reihe Methoden, die als

Delphi-Quellcode:

abstract

markiert sind.
- Davon abgeleitet ein weiteres Datenmodul (TLocalDM), das diese abstrakten Methoden überschreibt:

Delphi-Quellcode:

type
  TLocalDM = class(TBaseDM)
  //TLocalDM = class(TDataModule)
  ...
end;

- Ebenfalls von TBaseDM abgeleitet ein drittes Datenmodul (TSQLDM), das ebenfalls diese abstrakten Methoden überschreibt.

Delphi-Quellcode:

type
  TSQLDM = class(TBaseDM)
  ...
end;

Nun das Phänomen: Ich öffne die Projektdatei mit dem TLocalDM. Mache irgendeine Änderung. Speichere und compiliere. Alles prima. Starte das Programm und es crasht mit der Meldung "Eigenschaft ClientHeight existiert nicht". Hat er ja recht, ClientHeight haben Datenmodule nicht - aber Formulare.

Öffne ich TLocalDM.pas erneut und gehe auf die Formularansicht, dann sehe ich kein Quadrat, das mein Datenmodul darstellt, sondern ein Formular (Titelzeile, Minimize-,Maximize-,Close-Button). Ich muß dann den Kopf der Unit umbauen:

Delphi-Quellcode:

type
  //TLocalDM = class(TBaseDM)
  TLocalDM = class(TDataModule)  //Kommentare nun vertauscht !
  ...
end;

Dann das Projekt speichern, schließen und neu öffnen, wo mir sofort entgegenspringt "Eigenschaft ClientHeight existiert nicht". Hier wähle ich "alle ignorieren", da noch etliche formularspezifische Properties folgen. Dann tausche ich die Kommentare zurück, compiliere und speichere neu und das Problem ist weg. Bis ich LocalDM.pas schließe und neu öffne - dann ist aus dem Datenmodul wieder ein Formular geworden.

Ich hatte schon mal herumgeforscht und gesehen, das Delphi in der Projektdatei Hinweise hinterlegt, das mein LocalDM eigentlich ein TDataModule ist. Dies stimmt auch alles, trotzdem wird immer wieder ein Formular draus:

Delphi-Quellcode:

  FZW_BaseDM in 'FZW_BaseDM.pas' {BaseDM: TDataModule},
  FZW_NoDBDM in 'FZW_NoDBDM.pas' {NoDBDM: TDataModule},
  FZW_LocalDM in 'FZW_LocalDM.pas' {LocalDM: TDataModule},
  FZW_SQLDM in 'FZW_SQLDM.pas' {SQLDM: TDataModule},

Der ganz große Witz ist nun: Mit TSQLDM passiert das nicht. Das bleibt ein Datenmodul, egal wie oft ich TSQLDM.pas öffne und wieder schließe.

Ich hatte, wie schon erwähnt, während der Nutzung von XE4 schon einmal um Rat gefragt, wie man diese sehr nervige Sache abstellt (zumal dann immer wieder beim Kunden auftaucht "Eigenschaft ClientHeight existiert nicht", obwohl man eigentlich am SQLDM was geändert hat und das nur am LocalDM nachziehen wollte). Ich hatte die leise Hoffnung, das das unter XE7 verschwinden würde, tat es aber nicht.

Also erneut die Frage in die Runde: Was mache ich falsch (oder habe ich falsch genmacht) und wie werde ich diesen Geist wieder los ?

[mm1256]

Hallo,

wie sieht denn die ".dfm" des Datenmoduls aus? Evtl. mal posten.

EDIT: Und evtl. das Userprofil updaten, hier steht noch XE4

[himitsu]

Vererbung von Datenmodulen kannst du ganz einfach vergessen, da der Formdesigner damit nicht klar kommt.
Wenn er nicht sicher erkennt, daß es ein TDataModule ist, oder es sich um einen ihm bekannte Klasse handelt, z.B. TService, dann springt der Designer immer auf TForm zurück.

Also entweder vergiss das Vererben, registriere deinen Vorfahren bei Delphi (RegisterClass, RegisterComponent, ...) oder Vererbe nicht "sichtbar" (also ohne abgeleitete DFM).

PS: Das Erkennen des Typs macht der kranke Designer auch nicht über die RTTI (schauen was für einen Vorfahren die Klasse hat), sondern anhand des Eintrags in der DPR/DPROJ

Delphi-Quellcode:

{BaseDM: TDataModule}

und wenn da nicht "TDataModule" steht ...


Das Problem besteht seit Jahrzehnten und ich würde nicht auf einen Bugfix hoffen (innerhalb der nächsten 20 Jahre) und wenn, dann höstens zum Kaufen (XE32).

[Der schöne Günther]

http://www.delphipraxis.net/177739-v...g-geloest.html

https://www.google.de/search?q=tdata...r1JouuUZP6jYgB

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1317892)

Vererbung von Datenmodulen kannst du ganz einfach vergessen, da der Formdesigner damit nicht klar kommt.

Diese Aussage ist mir etwas zu pauschal. Wäre das nämlich immer so, würde das Problem bei mir mehrmals täglich auftauchen. Tut es aber nicht!

[himitsu]

zum Pauschal: Es ist quasi fast unvorhersehbar, ob es funktioniert, also besser nicht benutzen. :stupid:


Man kann versuchen, ob es funktioniert (wird zumindestens besser, solange das Package mit dem Vorfahren in Delphi installiert/geladen ist), wenn man den Vorfahren registriert
oder man verzichtet eben besser auf eine visuelle Vererbung von Nicht-TForms, von welchen Delphi den Vorfahren nicht direkt kennt.

[Delbor]

Hi OlafSt

Zitat:

Also erneut die Frage in die Runde: Was mache ich falsch (oder habe ich falsch genmacht) und wie werde ich diesen Geist wieder los ?

Eine Antwort habe ich darauf nicht wirklich, aber ich kann von ähnlichen Erfahrungen berichten - allerdings gings damals nicht um Datenmodule, sondern um Frames.
Anhand eines kurzen Beispielprogrammes lernte ich das Pattern Classfactory kennen. Das Beispiel verwendete Frames, genau wie ich. Im Gegensatz zu mir, der ich damals mit DelphiXE4 arbeitete, war das Beispiel mit DelphiXE7 erstellt worden. Erst liess sich dieses Beispiel nicht compilieren - Fehlermeldung war genau die, die du angegeben hast. Meine Recherche ergab, dass Frames in Delphi XE7 offenbar diese Propertys haben.
Und nun kommt der Clou: seit eiger Zeit arbeite ich mit Delphi XE8 und verwende in dem Immer noch selben Projekt Frames, die ich mit Delphi XE4 erstellt hatte - ich hätte also erwartet, dass DXE8 die in meinen Frames fehlenden Propertys ClientHeight und ClientWith anmeckert - aber nichts geschah. Desshalb hatte ich erst angenommen, dass Frames in XE8 diese Propertys doch nicht mehr haben - ein Blick in die Help belehrte mich allerdings eines besseren. Andrerseits habe ich nachgesehen, wie das jetzt bei Datamodulen ist. Da ist nnach wie vor sowas nicht vorhanden.

Den Geist dürftest du loswerden, indem du ein neues Exemplar deines fehlerhaften moduls erzeugst (das alte Umbennen, das neue mit dem jetzigen Namen).
Den Code aus dem jetzigen Modul kannst du zB. mit dem CnPack als *.txt-Datei sichern. Mit den GExperts habe ich nicht so gute Erfahrungen.

Gruss
Delbor

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1317909)

zum Pauschal: Es ist quasi fast unvorhersehbar, ob es funktioniert, also besser nicht benutzen. :stupid:

Mag sein, aber bei mir ist 'quasi fast unvorhersehbar' mit 'noch nie' gleichzusetzen, wobei sich dieses 'noch nie' auf einen Zeitraum von 16 Jahren bezieht.

Wurde schon nach der DFM gefragt? Poste doch mal eine abgeleitete DFM... Die ersten 10 Zeilen sollten reichen.

[Sir Rufo]

Das Verhalten ist reproduzierbar:

Delphi-Quellcode:

unit dm1;

interface

uses
  System.SysUtils, System.Classes;

type
  TDataModule1 = class(TDataModule)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  DataModule1: TDataModule1;

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

{$R *.dfm}

end.

Delphi-Quellcode:

unit dm2;

interface

uses
  System.SysUtils, System.Classes;

type
  TDataModule2 = class(TDataModule)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  DataModule2: TDataModule2;

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

{$R *.dfm}

end.

Bis hier ist die Welt noch in Ordnung ...

Jetzt den Fehler einbauen:

Delphi-Quellcode:

unit dm2;

interface

uses
  System.SysUtils, System.Classes, dm1; // <- da

type
  TDataModule2 = class(TDataModule1) // <- da
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  DataModule2: TDataModule2;

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

{$R *.dfm}

end.

Speichern, Alles schliessen, Projekt wieder öffnen ... DataModule2 öffnen => eine Form!

• Wie kann man das heilen?
  1. Öffnen der dm2.dfm
     
     Code:

     object DataModule2: TDataModule2
       OldCreateOrder = False
       Height = 150
       Width = 215
     end

  2. abändern zu
     
     Code:

     inherited DataModule2: TDataModule2
       OldCreateOrder = False
     end

     und speichern
  3. Jetzt das Projekt neu laden und alles ist wieder schick ...
• Wie sollte man das richtig machen?
  
  Zum Ableiten von
  Delphi-Quellcode:

  TForm

  /
  Delphi-Quellcode:

  TFrame

  /
  Delphi-Quellcode:

  TDataModule

  geht man über
  1. Datei - Neu - Weitere...
  2. Delphi-Projekte - Vererbbare Elemente - DataModule1
  3. OK klicken
  Das war es schon.

PS Dieses manuelle Ableiten funktioniert (halbwegs) nur bei Formularen, denn es wird automatisch angenommen, dass es sich um ein Formular handelt. Empfohlen ist diese Vorgehensweise aber nicht.

[OlafSt]

Ich habe mal den Heilungsprozeß von Sir Rufo durchgeführt. Tatsächlich steht bei den Problem-Datamodules in den DFM-Files "object", während bei den "gesunden" DFMs ein "inherited" steht. Allerdings sind alle Datamodules "per Hand" abgeleitet, von daher muß da noch was anderes im Busch sein - aber wie schon erwähnt wurde, dürfte das in der IDE und ein Fix in sehr weiter Ferne liegen :wink:

Da findige Leute meinen Thread in der EE aufgespürt haben (hatte vergessen, das ich ihn da eröffnet hatte), werde ich den Thread hierhin verweisen lassen.

Was lernen wir daraus ? Da will man mal was anderes ausprobieren und den empfohlenen Weg gehen und wird dann so dafür belohnt :-D Ich gelobe feierlich, von Datamodules gleich wieder die Finger zu lassen, so wie ich es all die Jahre zuvor auch getan habe :-D:-D