![]() |
TFrame Container für Wizzard
Ist es möglich einen Container zu bauen der ein Liste von TFrame Nachfahren verwaltet, wobei die Frames im Container bearbeitet werden können aber jeder Frame weiterhin in seiner eigenen DFM Datei gespeichert wird.
Ich frage bevor ich es versuche hier nach, damit Ihr mir sagen könnt ob ich da auf unverrückbare Grenzen stoße... |
AW: TFrame Container für Wizzard
Zitat:
Aber das mit dem Container ... der wird wohl nur die "laufenden" Klassen Instanzen bearbeiten können, wärend er sie anzeigt. Er müßte aber die PAS und DFM direkt bearbeiten, was nicht so einfach/schön sein wird, wenn sie gleichzeitig angezeigt werden sollen. Kommt aber darauf an wo und wie der Wizzard laufen soll. - Wenn dein Wizzard im Delphi, als "Plugin" läuft, dann wäre bestimmt es einfach und auch praktikabel machbar. (z.B. Delphi > Menü > Datei > Neu > Weitere > Delphi-Dateien > Komponente > macht ja auch sowas Ähnliches) - Wenn er selber als Komponente als/auf eine(r) Form im Formdesigner im Delphi arbeitet ... ich würd's erst garnicht versuchen, wenn nicht grade mein Leben davon abhängt. (läuft am Ende etwa auf's Selbe hinaus, wie Variante 3) - Wenn der Wizzard als eigenständiges Programm arbeitet und Delphi dabei möglichst nicht läuft ... klar, aber dann wirst du "manuell" die PAS und DFM erstellen/bearbeiten müssen. |
AW: TFrame Container für Wizzard
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
So wie das alte TTabnotebook aus Windows 3.1 Zeiten handhabbar, aber eben mit Frames die dann auch einzeln wiederverwendet werden können... Zurzeit baue ich Wizards in dem ich das Formular n-Bildschirme groß mache und dann Pannels auf dem formular verteile und diese dann einen nach dem anderen sichbar mache und in position bringen... der gesammte code liegt dabei in dem Formular...das ist wirklich nicht mehr feierlich. Ich bin dazu übergegangen Seiten durch Frames zu realisieren damit dieses Formular nicht immer unübersichtlicher wird. Aber es nervt wenn man die Frames jedes mal über Delphi öffnen muss um sie zu sehen und zu ändern... Also werde ich wohl eine andere Lösung suchen :( |
AW: TFrame Container für Wizzard
Zitat:
Dazu dann erstmal rausfinden wie man via OpenToolsAPI diese Units findet, öffnet und vorallem bearbeitet. Alleine das Finden könnte aufwändig werden ... Suchpfade rausfinden, dann alles absuchen und hoffen man triff die richtige Unit (PAS+DFM). Dann wird zur Laufzeit ja nicht die PAS/DFM genutzt, sondern die DCU+DFM und wenn man pech hat, dann befindet sich alles auch noch ein einem Package. Beim Ändern ,üßte man womöglich auch noch sonstwas neu kompilieren, damit es auch wirklich geändert wird. z.B. beim Schließen des Formulars, der Units oder gar des ganzen Delphis und vorallem beim anschließenden Öffnen wird ja womöglich nicht direkt die PAS geladen, denn deine Kompoente läd ja die kompilierte Version. Wurde also nur die PAS/DFM geändert, bleibt alles beim alten und die Änderungen werden nicht angezeigt. :zwinker: |
AW: TFrame Container für Wizzard
Shit!
Jetzt verstehe ich erst worauf du hinaus willst. Frames werden ja immer kompiliert eingebunden.... :( Die Dateien zu finden wäre kein Problem, die Pfade würde ich in der Frameliste speichern...hm Das öffnen der Pas-Datei in der IDE müsste man herausfinden... Das mit den kompilerten Frames ist schon doof, aber wie schafft es die IDE auf Formularen Controls live abzulegen? Evtl. bräuchte man so ne Art Kodebrücke, wo halt doch alles in durchgeschalteten Pannels angezeigt und bearbeitet wird und der DFM Code direkt an die eigentlichen Frames weitergereicht wird, bzw. auch von diesen geladen wird...(oooooh ich hasse TReader und Konsorten) Das Eventöffnen/-erzeugen im Objektinspektor durch doppelklick, lässt sich aber wohl nicht ersetzen durch ein "Umschalten auf MyFrame1.Pas und dort den Code generieren oder anzeigen" Die Idee fühlte sich so gut an. Leider ist es wohl doch eher eine Aufgabe für Gexperts, oder so. Also überlege ich mir etwas ohne Komfort.....aber mit Frames.... Eine Runtime Komponente ist ja einfach. |
AW: TFrame Container für Wizzard
Mal ne dumme Frage am rande, aber warum willst du unbedingt Frames verwenden?
Also wenn ich einen Wizard schreiben würde, würde ich mit TNotebook arbeiten. Frames muss man doch auch Einbinden, im Endeffekt ist die normale Einbindung auch fast eine Art Container für den Frame, und jetzt willst du eine Art Container für eine List von Frames? Vielleicht schaust du dir mal an wie Delphi das mit dem Einbinden eines Frames im Formular macht an. Aber ich finde dies auch recht aufwendig. Du willst im Endeffekt eine Liste von "Panels" haben, die du leicht wechseln kannst, oder? Dies macht TNotebook. Gehandhabt wird TNotebook wie ein TabCotrol, also über Indexzahl oder übern Namen. Also ich würd dir echt TNotebook dafür ans Herz legen. Gruß NickelM |
AW: TFrame Container für Wizzard
...ich würde eher zum TPageControl mit zur Laufzeit unsichtbaren TTabsheets raten.
Vorteil: Du kannst zur Designtime bequem wechseln. Beim Start werden die Tabs entfernt und vom Programm entsprechend über Index oder Name angesprochen. Btw auf den TabSheets können natürlich auch Frames liegen. |
AW: TFrame Container für Wizzard
Zitat:
Der nachteil von Tnotebook oder eine Panelliste ist ja das alles an DFM und Pascalcode in einer DFM und Pas datei zusammen gefasst ist . Ich möchte aber jede Seite als vollfunktionsfähigen Baustein. Wir hatten und haben noch genug TNotebook Wizzards...wir wollen die nicht mehr. |
AW: TFrame Container für Wizzard
Zitat:
|
AW: TFrame Container für Wizzard
Zitat:
Delphi-Quellcode:
DeinTabSheet.TabVisible := false;
Oft hilft es wenn man das was man machen will einfach mal ins Englische übersetzt :wink: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:31 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz