TPanel oder TTabSheet aus einer LIBRARY anzeigen

[Lorca]

Hallo zusammen

kennt jemand einen Weg, um z.B. Registerkarten (TabSheets) aus einer Library anzuzeigen?
Nachdem dies bei mir nicht funktioniert hat, habe ich alles auf die Anzeige von Frames in Panels umgebaut.
Rufe ich diese Objekte normal aus den UNITs auf funktioniert dies. Aktiviere ich den Compilerschalter "Library" geht das in die Wicken.

In einem anderen Programm habe ich eine Library aufgebaut, um ganze TFORMs anzuzeigen. Das hat funktioniert. Jedoch hier, bei einzelnen
Komponenten in der aktuellen Form funktioniert es nicht, einzelne Komponenten wie Frames oder Panels anzuzeigen.

Hat jemand eine Idee, warum das so ist, bzw. wie es geht?


Gruß
Lorca

[KodeZwerg]

-- Beitrag vom Moderator entfernt --

[Lorca]

Hallo zusammen, hallo KodeZwerg,

zunächst herzlichen Dank für Deine Antwort.
Nein, leider hilft die nicht, oder ich verstehe da etwas völlig falsch.

Mir geht es darum, das hoch komplexe Tabsheets (mit mehr als 50 Komponenten) nicht ins Hauptprogramm eingebunden werden.
Bei der von ChatGPT vorgeschlagenen Lösung verlegst du nur das Problem als eigene Komponente. Wenn diese dann auf den Hauptschirm per drag and drop gezogen wird hast du nichts gewonnen. Die Komplexität bleibt weiterhin im Hauptprogramm.

Bei dem einbinden in eine Library bleibt das Problem wie auch in meiner Version.
Ich denke der Grund liegt im Adressbereich (Stichwort: Farjump)

Lager ich eine TFORM in eine Library aus, muss ich die Variable "APPLICATION" bei der Initialisierung der Form vom Hauptprogramm mitgeben. Also: Register_Form_XYZ( io_Appl : Tapplication ). Hier wird dann die Methode io_Appl.CreateForm aufgerufen.
Somit ist die ausgelagerte Form aus der Library, in der Applications Liste des Hauptprogrames eingebunden und funzt.

Bei dem Auslagern von Tabsheets, Frames bzw. Panels funktioniert diese Vorgehensweise jedoch nicht.
In meinem Programm habe ich dann zuerst das Tabsheet, und später dann das Panel mitgegeben. Beides mal ohne Erfolg.
Im Debugger konnte ich sehen, daß das Frame zwar erstellt wurde, aber danach die Methode "TCL_Frame.Create" sofort beendet wurde. Ich schätze das hier der erhaltene Adressbereich für den Parameter "io_Owner" für die Library nicht erreichbar bzw. ungültig ist.

Ich weiß jedoch nicht ob meine Vermutung richtig ist oder nicht, bzw. wie man so ein Problem lösen kann.
Deshalb habe ich ja auch hier nachgefragt ob jemand eine Idee hat

Also Danke für Deinen tollen Einsatz, ich kann jedoch nicht erkennen, das eine Auslagerung in ein Paket das Problem löst.

Viele Grüße
Lorca

[KodeZwerg]

Na super, nun wird meine Antwort gelöscht und ich bekomme eine Verwarnung von Fuchs da ich etwas von ChatGPT, mit dem vermerk das es von dort stammt, eingefügt habe womit jegliche Grundlage einer Antwort "warum als Paket" zerstört wurde.
app.php/help/faq
Da konnte ich nichts entdecken das eine Beispielhafte demonstration einer generierten AI Antwort verboten ist aber nun weiß ich es ja.
Einen schönen Tag wünsche ich noch.

[charlytango]

Da konnte ich nichts entdecken das eine Beispielhafte demonstration einer generierten AI Antwort verboten ist aber nun weiß ich es ja.

Möglicherweise liegt das daran dass die FAQ aus einer zeit stammt in der KIs in den Kinderschuhen staken.

[KodeZwerg]

Dann könnte man es auch freundlicher formulieren anstelle "Verwarnungen" rauszuschicken wo man als Teilnehmer keine Ahnung vorher von dieser Situation hatte, dass das Deutsche Lazarusforum eine Technologiephobie hat war mir vorher nicht bewusst.

[m.fuchs]

Das ist ein Forum in dem sich Entwickler austauschen können, keine Spielwiese für Deep-Learning-Experimente.

Wenn du zu dem Problem etwas beitragen kannst: schreib eine Antwort. Wenn du zusätzliche Fragen zu dem Problem hast: schreib eine Antwort. Wenn du eine Webseite kennst, die eine Antwort zu dem Problem hat: schreib eine Antwort und hänge einen Link zu der Webseite an.

Aber nicht die Frage einfach in einen Chatbot hauen und das Ergebnis hier posten. Das ist keine Antwort, das ist Spam.

Das hat auch nichts mit Technologie-Phobie zu tun, wir nehmen einfach nicht an dem Experiment ChatGPT teil als Forum.

[m.fuchs]

Lager ich eine TFORM in eine Library aus, muss ich die Variable "APPLICATION" bei der Initialisierung der Form vom Hauptprogramm mitgeben. Also: Register_Form_XYZ( io_Appl : Tapplication ). Hier wird dann die Methode io_Appl.CreateForm aufgerufen.
Somit ist die ausgelagerte Form aus der Library, in der Applications Liste des Hauptprogrames eingebunden und funzt.

Bei dem Auslagern von Tabsheets, Frames bzw. Panels funktioniert diese Vorgehensweise jedoch nicht.
In meinem Programm habe ich dann zuerst das Tabsheet, und später dann das Panel mitgegeben. Beides mal ohne Erfolg.

Eine Idee hätte ich anzubieten: Anstelle von Frames könntest du wieder Forms nehmen und diese jeweils in ein Panel einbinden. Im englischen Forum gibt es dazu ein paar Infos: https://forum.lazarus.freepascal.org/in ... #msg135256

Ob das jetzt auch mit Forms aus einer Library klappt, kann ich dir nicht versprechen.

[fliegermichl]

Du kannst aus einer Library nur einfache Variablen exportieren. Klassen geht nicht.

Allerdings kannst du ein Wincontrol aus der Library in dein Formular einbinden. Dazu muß jedoch das Fensterhandle bekannt sein.
Ausserdem muß die Library auch entsprechende Callbacks für Benutzeraktionen anbieten.

Auf die Weise habe ich den dxf/dwg Reader/Viewer eines externen Anbieters in meinem CAD Programm eingebunden.

[Lorca]

Hallo zusammen, hallo m.fuchs, hallo fliegermichl

ganz herzlichen Dank für eure netten Antworten

Vorab, ich habe es hinbekommen. Wenn auch nicht genau so, wie ich es wollte, jedoch in einer für mich tragfähigen Version.

@m.fuchs:
Deine Idee, mit einer Form (auch als MIDI) war zwar echt cool, und hat mich auch auf eine Alternative geleitet, funzt leider nicht. Es harkt immer am Parent. Der lässt sich bei mir nicht einstellen. Er ist nach der Zuweisung immer NIL. Weder über die direkte Zuweisung noch mittels InsertControl.

@fliegermichl:
Was meinst du mit Fensterhandle? Wie komme ich an das Handel?
Und wie wird das Einbinden eines TWincontrol aus der Library in das Hauptprogramm gemacht?
Der Owner für dieses neue WinControl war die TFORM des Hauptprogrames (Übergeben an die Export Methode)
Zunächst einmal muss nach dem Erstellen des TWincontrol (in der Library), der Parent diesem neuen Wincontrol zugewiesen werden.
Und genau das war ja immer mein Problem. Der Parent lies sich nicht zuweisen. Das TWinControl lies sich deshalb nicht anzeigen.
Wenn Du also ein paar Codeschnipsel hättest, würde ich mich darüber sehr freuen.

Nun zu meiner alternativen Lösung: ( nicht optimal, aber gangbar )
Zuerst habe ich ein Frame erstellt und Buttons und TEdits darauf angelegt. Danach habe ich eine Contoller Klasse dazu angelegt, welche dieses Frame verwalten kann, und auf Benutzeraktionen reagiert (Outsourcing )

Im Hauptprogramm habe ich dann dieses neue Frame auf die benötigte Registerkarte gelegt.
Dann habe ich dieses hier angelegte Frame an die LIBRARY Exportmethode übergeben.

Und nun kümmert sich die LIBRARY bzw. die vom Hauptprogramm losgelöste Controllerklasse des Frames, um alle Benutzereingaben auf eben diesem Frame.
Somit liegt due UI Darstellung im Hauptprogramm, und die Bearbeitung aller Felder wird autonom in der Library bzw. dem Controller erledigt. Auf diese Art kann ich nun Modul für Modul fertig stellen, ohne daß das Hauptprogramm alles immer verändert und mit Compiliert.

Nochmals herzlichen Dank euch allen. Oft helfen ja schon eure Denkanstöße.
Und wenn fliegermichl noch ein paar Schnipsel findet, könnte ich das Programm vllt. auch noch optimieren

Viele Grüße
Lorca

[af0815]

Somit liegt due UI Darstellung im Hauptprogramm, und die Bearbeitung aller Felder wird autonom in der Library bzw. dem Controller erledigt. Auf diese Art kann ich nun Modul für Modul fertig stellen, ohne daß das Hauptprogramm alles immer verändert und mit Compiliert.

Ich verstehe den Sinn dahinter nicht. Wenn ich ein Frame designe, so ist das komplett in sich gekapselt und das Hauptprogramm kann es nur parametrieren, aber ändert dort nichts. Das Frame kommuniziert zurück an das Hauptformular über CallBacks und Events. Frames immer zur Laufzeit einbinden, das mit Designzeit ist nicht unbedingt optimal in der IDE gelöst (War aber in Delphi genauso)

Und einmal kompiliert, liegt es ja als compilat vor und wird nur bei Sourceänderungen neu kompiliert. Genau dieses Verhalten versuchst du über die Library meiner Meinung krampfhaft nachzubilden.

[Lorca]

Hallo zusammen, hallo af0815

Ich habe jahrelang nach dem MVC Modell (Model, View, Controller) entwickelt.
Damit wird eine Trennung der Visuellen Komponente von den Daten und den Funktionen erreicht und ist somit austauschbar.
Durch die Verteilung der Zuständigkeiten wird sowohl eine höhere Übersichtlichkeit, als auch eine bessere Wartbarkeit erreicht.
Ebenfalls lässt es sich so in einem Team bei Änderungen oder Korrekturen besser bearbeiten.

Das Framekonzept hier im Lazarus ist sehr instabil und fehleranfällig und führte bei mir sehr häufig zu Problemen, das bei eingebauten Frames sich das Programm am Folgetag nicht mehr korrekt laden ließ, weil irgend welchen Änderungen an den Frames, nicht sauber gespeichert wurden. Frame in Frame in Frame ist suboptimal von Lazarus gelöst. Ein Panel als Toolbar mit mehreren Buttons kann bei Frame in Frame in .... nicht so einfach geändert werden. Oft wurde bei mir z.B. die Caption einer Frame nach einer Änderung gesetzt. Sowas meckert dann Lazarus beim laden an. Dieses Setzen dieser Eigenschaft wurde jedoch von Lazarus selbst gemacht und nicht von mir. So wird ebenfalls das Attribut ParentFont immer auf False gesetzt. Auch wenn dies während des Designs auf True gesetzt wird. Solche Dinge kann dann der Controller korrigieren.

Und wenn Du dann ein Frame mit enthaltenen Coding neu machen musst ist das sehr ärgerlich und zeitaufwendig.
Wird das jedoch nach MVC gemacht, brauchst Du nur die VIEW (also das Frame neu gestalten). Der Controller und das Model sind dann jedoch immer noch funktionsfähig.

Viele Grüße
Lorca

[af0815]

Nochmals, die Frames sind voll Ok und funktionieren super - allerdings dynamisch erstellt.

Ich gebe dir Recht, das die Umsetzung in der IDE nicht besonders ist. Dort gibt es Probleme mit dem Reload, auch Events werden überschrieben, aber beim löschen nicht mehr aus der lfm richtig ausgetragen und so Sachen konnte ich in der Vergangenheit bemerken.

Nur deine Lösung über den Umweg einer DLL kannst du dir IMHO ersparen, wenn Frames zur Laufzeit verwendet werden (so wie die DLL) sind Frames absolut stabil und ich verwende extensiv Frames in Frames in Feldern of Frames. Und das in industrieller Umgebung seit Jahren.

Seit Delphi habe ich mir abgewöhnt die im Designer zu verwenden, das Verhalten war ähnlich Problematisch.

[charlytango]

ich hab mal die Suchfunktion bemüht und nach frame, Frames, Tframe gesucht weil genau diese Themen schon etliche malte besprochen wurden;

viewtopic.php?f=9&t=14355&p=128931#p128931

viewtopic.php?f=10&t=14479&p=130333&hil ... me#p130333

und etliche andere.

Grundsätzlich soll ja jeder das machen was er will. -- checked.

MVC ist ein gutes Konzept, ob das aber wirklich gut mit dem RAD Konzept von Lazarus/Delphi zusammen passt?
Als Model könnte man ein Datenmodul nehmen in dem alle datenrelevanten Komponenten samt Code liegen, das Frame ist dann der View und in irgend einer Unit liegt dann noch die Business-Logik.

Sich das wirklich anzutun alles was es in Lazarus gibt neu zu erfinden nachdem man Lazarus/fpc alles abtrainiert was es ausmacht nur weil man scheinbar mit Frames nicht zurecht kommt halte ich für Overkill.

Bisher hab ich das was ich nun mit Frames beginne umzusetzen einfach mit TForms gemacht -- klappt hervorragend.
Einkleben in ein TTabSheet ? Kein Problem -- sieht genauso aus wie es soll. (Ohne Fensterbalken).
Der Owner kümmert sich ums Aufräumen und der Parent ist fürs einkleben zuständig.

Im Moment mache ich es so, dass ich diverse TFrames und andere Controls in ein TForm "klebe". TForms werden IMMER zur Laufzeit erzeugt und in Größe und Position eingepasst oder wenn mir das zu umständlich ist klebe ich das TForm einfach zur Laufzeit in ein TPanel das als Platzhalter in der IDE fungiert.

Diese so erzeugte TForm wird ebenfalls zur Laufzeit erzeugt und dann in ein TTabsheet eingeklebt. Das hat den Vorteil dass man diese TForm wahlweise eingeklebt lassen kann oder sie aus dem TTabSheet zur Laufzeit herauslösen und als eigenes Fenster nonmodal bedienen kann.

Jedes Form und jedes Frame ist in sich inert, und kann für sich selbst funktionieren und daher auch in einer Testumgebung getestet werden. Jedes Formular (außer dem Hauptformular) wird zur Laufzeit erzeugt. That's it


just my 2cents