Hallo...

ich habe ein Problem 8wer hätte es gedacht).

Also ich möchte mein Projekt in 3 Teile teilen:
Die 1. Unit soll sämtliche Prozeduren (OnCreate, OnDestroy, OnResize, OnKeyDown, OnClick etc.) des Formulares enthalten und ist die Startunit.
Die 2. Unit soll die GL Anweisungen erhalten (SetupGL und die Renderprozedur).
Die 3. Unit soll alle Objekte enthalten, die sich in der Renderung wiederholen (Schränke, Vasen und wenn ich das mit den Blending endlich hinkriege auch Fenster etc.).

Ich versuche mich schon seit heute früh und bekomme nichts anständiges auf die Reihe.
Kann mir einer helfen?

Also es gibt da in der Regel keine Probleme, wenn du deinen Code auf mehrere Units aufteilen möchtest. Dabei musst du aber beachten, dass Pascal in seinen Units einen Interface und einen Implementation Bereich hat. Alles was im Interfacebereich steht wird nach Außen hin sichtbar sein. Im Interface werden aber normal nur Datentypen, Funktionen etc definiert. Die eigentliche Implementation der Funktionen sind auch im Implementation Bereich zu erledigen. Solltest du einen Typen haben der nur in der Unit bekannt sein soll dann kannst du ihn im Implementation Bereich deklarieren.

In etwa wie folgt könnte deine Unit aussehen.


Benutzen kannst du sie dann in etwa so.


Aber ein paar gedanken Anregungen. Es ist nicht gut den Code einfach auseinander zu reißen. Du solltest dir dabei schon etwas denken und da auch darauf achten, dass wenn du Code ausgliederst, dass dieser Code auch in etwa zusammengehört. Also Code zum Speichern einer Textdatei hat nichts in der Unit zur OpenGL Initialisierung zu suchen.

Auch noch sehr wirchtig ist die Kommunikation zwischen den Codes. Wenn die Codeteile Daten austauschen müssen, dann sollte das nicht kreuz und quer passieren. Also Beispiel in der Unit Blah von oben. Es wäre technisch möglich im Implementation Bereich die Unit1 einzubinden und direkt auf das Form zuzugreifen. ABER nur weil es machbar ist muss man es nicht machen. Damit würdest du dafür sorgen, dass die Beiden Units so extrem eng miteinander vereint sind, dass die eine ohne die andere nicht mehr leben kann. Da würde man die Dinge die man in der Unit Blah benötigt an die passenden Methoden als Parameter übergeben. Und ich meine da nicht, dass man dann das Formular übergeben soll. Sondern eher nur einzelne Werte. Wie das aber im Konkreten aussehen kann hängt immer vom aktuellen Fall ab.

Als Faustregel solltest du dir im Hinterkopf behalten, dass du die Unit Blah auch mal eben so in einem anderen Projekt benutzen könntest. Deswegen sollten aus der Unit dann keine Abhängigkeiten nach außen bestehen. Falls es aber nicht auf Anhieb gelingt mach dir da keinen großen Kopf drum. Das gelingt einfach nicht immer. Selbst nach 12 Jahren programmieren nicht.

Nunja, bei mir kommt es immer zu ÜBERKREUZUNGEN und "Redfiniert"...

Und ich kann irgendwie deine Erklärung nicht auf mein Problem umsetzen...
Was sollte ich denn nun wo in der Interface-Uses-Klausel und was in der Implementations-Uses-Klausel einbauen?
Oder würdest du mir indem Fall doch lieber abraten?

Davon abraten wäre das letzte was ich tun würde! Wenn ein Projekt eine gewisse Größe erreicht hat, dann wirst du ohne verschiedene Units nicht mehr auskommen. Was du nur nicht machen darfst ist einfach so Code nehmen und in eine andere Unit packen. Das wird höchstwahrscheinlich in einem Chaos oder in Fehlern enden. Beides vermutlich nicht gerade wünschenswert.

Wo hackt es denn bei meiner Erklärung? Bzw was hast du nicht verstanden?

Der überkreuzende Bezug zweier Unit entsteht immer dann, wenn du zwei Units hast die sich gegenseitig im Interface einbinden. Dann weiß der Kompiler nicht welche Unit er zu erst kompilieren soll. Eine Unit im Implementation teil einzubinden kann dieses Problem evtl lösen. Aber dann sind die beiden Units sowieso extrem miteinander verwoben und da wäre es eventuell ratsam eine andere Struktur anzustreben.

Was du bei dir jetzt genau wo einbauen musst kann ich dir so nicht sagen. Das aber nur, da ich deinen Code nicht mal ansatzweise kenne. Deswegen war meine Erklärung oberhalb auch relativ allgemein gehalten. Allerdings denke ich, dass es wesentlich besser sein wird, wenn man dir das mal am lebende Objekt zeigen kann.

Hmmm.... Also so wie mir scheint, hast du verstanden, dass zum Programmieren auch Code/Projektorganisation gehört. Und jetzt bist du auf der suche nach einer Möglichkeit das geschickt zu machen.

Ich denke, im Moment bist du noch viel zu nah am coden dran. Geh mal ein Stückchen weg und versuch das Problem weiter zu abstrahieren. Das was du versuchst, habe ich damals bei meinen PBall Manager 2 versucht. Ich dachte ich hätte meinen Code strukturiert, aber am Ende war es ein riesen Schlamassel.

Wenn du etwas größeren Code schreibst, dann sollten deine Ziele immer folgende sein:
1: Es muss das machen was es soll (is klar)
2: Es muss Robust sein (ist programmiertechnisch zu lösen: Exception Handling)
3: Es muss Wartbar sein (Einfache Struktur, keine Verschlungenen Aufrufpfade: Ein Klares System muss drunter liegen. Sowas nennt man Software Architektur)
4: Es muss Erweiterbar sein (Wenn du neue Teile/neues Verhalten hinzufügen willst, sollte das ohne änderungen am bestehenden Code funktionieren.)

Das sind so die Grundlagen.
Als ich damals mit dem PBM2 fertig war, bin ich über einen Bekannten auf den "Rational Unified Process" gestoßen. Ich habe dann dazu hier eine 3Teilige Tutorialreihe (Tutorial_Softwareentwicklung1) geschrieben. Allerdings ist dieser Prozess sehr mächtig und vor allem für Projekte im geschäftlichen Umfeld gedacht. Auf alle Fälle ist das was dort gemacht wird aber nicht falsch, sondern vielleicht einfach nur ne Nummer zu groß für ein kleines Hobbyprojekt. Du solltest dir trotzdem mal zumindest das erste Tutorial durchlesen.
Dann sind noch sogenannte "Pattern" zu empfehlen. Das sind Codemuster/vorlagen die sich bewährt haben. Da findest du bei Wikipedia ne nette Zusammenfassung.

Das alles sollte dich nicht abschrecken. Es sind genau diese Dinge die man lernen muss um vom "Coder" zum Programmierer/Software-Engineer zu werden. (Nicht ganz. Der rest ist dann noch Theorie und das lernt man in der Uni. Aber den praktischen Teil, den lernst du nur so.)

_________________
Blog: kevin-fleischer.de und fbaingermany.com