Announcement

Collapse
No announcement yet.

Alle Hints bei den Formen innerhalb meiner DLLs weg.....

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Alle Hints bei den Formen innerhalb meiner DLLs weg.....

    Hallo....
    Ich hab hier eine ganz seltsame Sache. Vor Kurzem habe ich mein Projekt so geaendert, dass alle DLLs (ueber ein Menue im Main zu oeffnen) nicht mehr ShowModal sind sondern Show. Das heisst es ist jetzt moeglich mehrere DLLs zu oeffnen. Zu meinem erstaunen sind alle Hints, z.B. von SpeedButtons, verschwunden. Nur die Hints im Main (Execute... Keine DLL) sind noch vorhanden.
    Wenn jemand dieses Problem bekannt ist.... schreibt mir.

    Schon Mal Danke...

    Najib

  • #2
    Hier im Forum wurde schon mehmals auf das Problem mit DLL's und Forms eingegangen. Grundsätzlich ist dies eigentlich NICHT möglich es sei denn ALLE Programmteile wie EXE + DLL's nutzen Packages, mindestens das VCL??.bpl. Die Seiteneffekte solcher normalen DLL's wie Du sie nutzt sind, Zugriffverletzungen, Hints sind weg, Tabulatoren funktionieren nicht bzw. die Fokusierungen allg., MDI funktioniert nicht, merged Menus funktionieren nicht usw. usw. ALL diese Probleme liegen begründet in folgendem Fakt:<br>
    Ein Object besteht immer aus mindestens ZWEI Teilen. Einer Klassenbeschreibungsstruktur = Typ information + ein Allozierter und durch diese Klassenstruktur vorinitialisierter Speicherbereich. Der Speicherbereich existiert nun bei allozierten Objecten und jedes Object nutzt seinen eigenen. Ein Klassentyp existiert IMMER solange ein bestimmter Objecttyp im programm benutzt wird. Diese Klassenstruktur wird im CODE Segment des benutzenden = implementierenden Modules gespeichert. In Deinem Falle wird also in der EXE alle Klassenstrukturen die in der EXE benutzt werden auch im Codesegment der EXE gespeichert. Die Klassen der DLL's werden im Codesegment in der DLL gespeichert. Nun, will ein programcode ermitteln ob ein Object von einem bestimmten Typ ist, also z.b. mit Object is TComponent oder Object as TComponent dann wird der zeiger auf die Klassenstruktur von Object.ClassType mit der Klassenstructur-zeiger von TComponent verglichen, also Object.ClassType ~ @TComponent.
    Nun, die EXE fragt beim Hint folgendes ab:
    <b> Control_aus_DLL_unter_Maus_Cursor bist DU eine TControl_aus_meiner_EXE ???</b> und vergleicht demzufolgen die Klassenstruktur von TControl gespeichert in der EXE mit der gespeicherten der DLL. Dies ergibt <> und somit hat das Control auch keinen Hint das es kein Control für die EXE IST.<br>

    Werden nun Packages benutzt, und zwar in EXE und DLL's, dann nutzten beide Teile eine DLL in der auch die Klassenstruktur von z.B. TComponent abgespeichert wurde. Ein Vergleich eines EXE-TControls mit einem DLL-TControl vergleicht also immer den TControl-Typ gespeichert im VCL Package mit dem Typ im gleichen VCL Package da ja beide das selbe Package nutzen.<br>

    Ich weiß nicht wer irgendwann einmal auf die bescheuerte Idee gekommen ist Delphi TForms in solche DLL's zu packen. Auf jeden Fall verstößt diese Vorgehensweise direkt gegen das komplette OO Konzept, und auch gegen das DLL Konzept.
    Versuch doch mal Deine DLL mit D5 zu compilieren und Deine EXE mit D3. Dann wirste sehen das NICHTS mehr funktioniert, kann auch garnicht da ja nun sogar die gespeicherten Objecttypen von z.b. D3.TComponent.EXE ganz anders aufgebaut sind als die von D5.TComponent.DLL. Ein Zugriff auf z.b. DLL.TLabel.Caption := 'meine' aus der EXE herraus erzeugt GARANTIERT eine AV.

    gruß hage

    Comment


    • #3
      Grundsätzlich lassen sich sehr wohl TForm's in DLL's nutzen, dann aber NUR mit starken Einschränkungen, wie .Showmodal MUSS benutzt werden, vor und nach .ShowModal MUSS das Application Object der DLL auf das der EXE synchronisiert bzw. wiederhergestellt werden.<br>

      Aber Modul-übergreifende Zugriffe auf die Eigenschaften von Objecten oder deren Methoden ist IMMER falsch, eigentlich sogar illegal.<br>
      Man könnte nun ein deklariertes Object als record bzw. wie in einem Header deklarierte Struktur begreifen und man könnte argumentieren das ja z.B. im WINDOW-API auch Strukturen Modulübergreifend benutzt werden. Jo, dieser Vergleich hinkt aber
      <li>1. ist dann klar ersichtlich das es eine Schnittstelle ist
      <li>2. diese API Strukturen dienen meistens zur Definition der Übergrabeparameter von API Funktionen
      <li>3. Objecte sind "intelligent" und speichern sehr viele ZEIGER auf Einsprungspunkte in den CODE, sogenannte virtuelle/dynamische/message/events Methoden.

      Gruß Hage

      Comment

      Working...
      X