Eine Form über den "Bildschirmrand" hinaus bearbeiten

[LinkTL]

Hallo und ich wünsche allen einen schönen guten Tag!

Das ist das erste mal in meinem Leben, dass ich ein Forum benutze, also habt bitte Rücksicht falls ich hier irgendetwas falsch mache

Nun zu meinem Thema:

Ich programmiere seit 2-3 Wochen mit Lazarus und hatte vorher absolut 0 Programmiererfahrung.
Nun komme ich zwar durch viele Tutorials und rumgelese ganz gut zurecht, aber mein größtes Problem ist fehlender Platz auf der Form.

Da ich nach stundenlanger Suche nicht fündig geworden bin habe ich mich selber ausgetrickst und meinen Zweitbildschirm als Erweiterung genutzt um die Formen nach unten länger zu ziehen. Das hat auch super geklappt, bis ich von unterwegs arbeiten wollte und plötzlich nicht mehr auf alle Bauteile zugreifen konnte.

Tja.. nun habe ich mich in meiner letzten Verzweiflung angemeldet und bitte offiziell um Hilfe.
Gibt es überhaupt eine Möglichkeit die Form ohne zweiten Bildschirm größer zu machen (ich kann mir einfach nicht vorstellen das man immer auf die Bildschirmgröße begrenzt ist) und wenn ja...wie bewege ich mich während des "Programmierens" auf meiner Form nach unten oder zur Seite!

Ich danke euch allen im Voraus für eure Hilfe und wünsche euch ein entspanntes Wochenende!

VG

[Winni]

Hi!

Mache Deine Form so groß wie der Bildschirm.

Dann packst Du eine TScrollBox darauf - liegt bei dem Reiter "Additional". Die ziehst Du auf die gesamte Größe auf.

Dann richtest Du die beiden Schieber "HorzScrollbar" und "VertScrollbar" ein.

Und dann packst Du Deine Komponenten drauf auf die Scrollbox..

Dann kannst Du innerhalb der Form scrollen und trotzdem den Bildschirm nicht verlassen.

Alternativ gibt es das TPagecontrol ("Common Controls"). Hier kannst Du eine größere Anzahl an Seiten unterbringen, die jeweils einen eigenen Reiter besitzen. So hat man mit z.B. 5 Seiten quasi die fünffache Fläche zur Verfügung.

Winni

[Lincoln Six Echo]

Ich habe an meinem Hauptrechner 4 Bildschirme laufen. Bisher gibt es keine Probleme Forms auf einem oder mehreren Bildschirmen darzustellen.

Das ist aber auch für Anwender eines Programms relativ unwichtig. Wie der Kollege hier schon geschrieben hat, gibt es so einige Controls mit denen sich das lösen lässt. Die meisten Anwender mögen lieber Page-Controls (TNotebook) als Scrollboxen wegen der Übersichtlichkeit. In vielen Programmen kombiniert mit einer Kategorie-Liste ist das der quasi-Standard für Einstellungsdialoge.

[wp_xyz]

Wenn man ein Programm auf einem System mit mehreren Monitoren entwickelt und selbst benutzt - kein Problem, jeder kann machen, was er will. Wenn aber die geringste Chance besteht, dass dieses Programm auch jemand anders zwischen die Finger kriegt, z.B. in einem Forum-Post, muss unbedingt Code vorhanden sein, der berücksichtigt, dass der End-User ja auch nur 1 Monitor haben könnte.

Und meine generelle Meinung zu dem Fall, dass ein Programm nicht auf 1 Monitor passt: Da macht man etwas falsch, das Formular ist dann so überladen, dass man sich darin nicht zurecht findet. Bitte unbedingt mit Hilfe eines PageControl/NoteBook oder zusätzlicher Formulare den Inhalt auf mehrere Häppchen zerteilen.

[charlytango]

Und meine generelle Meinung zu dem Fall, dass ein Programm nicht auf 1 Monitor passt: Da macht man etwas falsch, das Formular ist dann so überladen, dass man sich darin nicht zurecht findet. Bitte unbedingt mit Hilfe eines PageControl/NoteBook oder zusätzlicher Formulare den Inhalt auf mehrere Häppchen zerteilen.

Kann da nur zustimmen.

Besonders wenn man mit dem Programmieren beginnt neigt man dazu viele Elemente/Controls auf eine Form(=Formular=vulgo Fenster) zu packen. Und wenn man ein komplexes Projekt hat ist das noch verstärkt. Da wird einem schnell mal ein Formular zu klein.

"Programmieren" ist mehr als Formulare zu malen und und sie mit Funktionen zu unterlegen.
Man muss sich auch überlegen wie man Funktionen und Bedienelemente aufteilt (z.B. indem man mehrere Fenster oder Frames verwendet) oder gruppiert ( mit Hilfe eines PageControl, Notebook oder TabControl).

In einer grafischen Benutzeroberfläche sollte der Benutzer des Programmes quasi durch das Programm geführt bzw eingeladen werden die Funktionen zu benutzen. Idealerweise selbsterklärend, was bei komplexen Projekten auch wieder komplex und oft unmöglich wird.
Dann setzt man für komplizierte Sachverhalte auch sog. Wizards ein - also Programme die den Benutzer Schritt für Schritt an der Hand nehmen und kontrolliert bis zum (End)Ergebnis führen.

Aber nicht nur der Benutzer profitiert davon sondern auch der Programmierer.
Wenn all der Code für viele Controls in einem Formular (also dem Codeteil eines Formulars) verwaltet werden wird das schnell unübersichtlich. Kleinere Einheiten die zusammen spielen sind leichter wartbar und erweiterbar.

Auch das Aufteilen von Sourcecode in nicht visuelle Units (Dateien in denen dann Sourcecode steht) hilft beim Strukturieren eines Programmes und beim Wiederverwenden von Codeteilen.

Vielleicht mal mit einem kleineren Projekt beginnen um zu sehen wie sich Lazarus verhält und was man alles braucht um zum Ziel zu kommen.

Ich weiß nicht mehr die wievielte CD-Verwaltung (bevor es CDs gab war es Bücher oder Adressen) ich in unterschiedlichen Sprachen und Programmsystemen gebaut habe um eine Idee zu bekommen wie sie sich verhalten.
Und kleine (manchmal auch größere -- so etwas bekommt auch bei Routiniers eine Eigendynamik) unabhängige Codeteile zu erstellen und zu testen um sie dann in einem komplexen Projekt zu verwenden ist nach wie vor an der Tagesordnung.

Also klein beginnen und das ganze dann zusammen setzen.