Klassen/Objekte Organisation mit OpenGL

[Illuminatus]

wenn das Signal von MainWindow gesetzt wird, kannst du die Liste doch einfach mit übergeben.

Bei langen Listen ist das sicherlich kein so gutes Vorgehen, da die Parameter des SIGNALS komplett kopiert werden (Auch wenn die SIGNAL-Parameter mit ner Referenz definiert sind, AFAIK). Mit großen Objekte kostet das Zeit und Speicher.

Prinzipiell geht sowas mit extern schon. Aber so weit ich weiß ist die Liste ein Member einer anderen Klasse. Da ist das mit extern nicht lösen.

Warum gibst du nicht das Objekt, welches die tupel-Liste als Member hat, deiner Klasse als Member, die dann auf die Elemente zugreifen will, als Pointer/Referenz? Damit kannst du jederzeit auf die Daten zugreifen, ohne kopieren zu müssen.

Code: Alles auswählen

class opengldrawer : public QGLWidget
{
  Q_OBJECT
public:
  opengldrawer(dbvis* db);

protected:
  dbvis* m_dbvis;
};

ch glaube die Klasse hies doch dbvis, oder?)

ah okay, ich glaube ich weis was du meinst, dass die klasse dann einfach einen zeiger auf den speicherbereich hast und damit dann auch einen zeiger auf diese liste!

ich weis nur nich wie ich das korrekt implementieren soll

Code: Alles auswählen

//opengldrawer.h
[...]
class opengldrawer : public QGLWidget
{
	Q_OBJECT

		
public:
	opengldrawer(QWidget *parent=0);
[...]

Code: Alles auswählen

#include "opengldrawer.h"

opengldrawer::opengldrawer(QWidget *parent)
	: QGLWidget(parent)
{
[...]

ich hab da noch die standardkonstruktoren... also ich übergebe beim aufruf in dbvis ja durch

anzeige = new opengldrawer(this);

ja meine oberfläche repräsentiert durch this dem fenster als ElternWidget! ich bin grad nur verwirrt, warum in meinem prototype des konstruktors der elternwidget auf 0 gesetzt wird, würde ja heißen dass das fenster unabhänigg meiner haupt GUI exisitert...

und wie mach ich das mit dbvis* er kennt diesen typ doch gar nicht?
hab das mit den pointern versucht aber mit dem Typ Widget klappt das nicht, da er ja objekte nicht als member von Widgets kennt...

[Illuminatus]

hi theoretisch müsste es doch gehn wenn ich die liste einfach in der opengl klasse anleg, da ich ja zugriff hab von der gui über den pointer aus oder???

[franzf]

Hi,

Es wäre nicht schlecht wenn du nochmal genau (nicht umständlich! ) beschreiben könntest,
* was die Aufgabe von dbvis ist
* wie die QList<tupel> zum Zeichnen verwendet werden, insbesondere
* wer initialisiert die tupel, damit sie gezeichnet werden (MainWindow, dbvis, oder passiert das direkt in openglviewer)

Prinzipiell denke ich, dbvis hält die Daten, openglviewer zeichnet, und irgendwo ist noch ein MainWindow, welches Inputs entgegen nimmt, entsprechend an die Objekte verteilt. So würde ich deinem opengleviewer einen pointer auf die dbvis-Instanz im Konstruktor mitgeben. Der pointer wird als Member gespeichert und beim Neuzeichnen erhält man immer die aktuellsten Tupel.

[Illuminatus]

Hi,

Es wäre nicht schlecht wenn du nochmal genau (nicht umständlich! ) beschreiben könntest,
* was die Aufgabe von dbvis ist
* wie die QList<tupel> zum Zeichnen verwendet werden, insbesondere
* wer initialisiert die tupel, damit sie gezeichnet werden (MainWindow, dbvis, oder passiert das direkt in openglviewer)

Prinzipiell denke ich, dbvis hält die Daten, openglviewer zeichnet, und irgendwo ist noch ein MainWindow, welches Inputs entgegen nimmt, entsprechend an die Objekte verteilt. So würde ich deinem opengleviewer einen pointer auf die dbvis-Instanz im Konstruktor mitgeben. Der pointer wird als Member gespeichert und beim Neuzeichnen erhält man immer die aktuellsten Tupel.

hi also^^

dbvis ist von QMainWindow abgeleitet! das ist meine oberfläche! sie enthält ein abnehmbares dockwidget dass später regler und eingabeflächen enthält
dann gibt es als zentralwidget den opengldrawer der die tupelliste auslesen soll und diese darstellen soll...

tupel.h ist so aufgebaut dass sie eine interne liste hält mit den spaltenwerten und verschiedene float arrays [x,y,z] die von dem openglwidget als vektoren interpretiert werden.

also in dbvis is die oberfläche wie auch die verarbeitung alos die verarbeitung des inputs...wie könnte man das denn anders organisieren? wenn ich ne neue klasse für die verarbeitung mach, dann müsst ich die ja au erstmal wieder instanzieren, etc. oder?
es müsste doch funktionieren, wenn man die liste einfach als member der von QGLWidget abgeleiteten klasse (opengldrawer) macht , oder?

EDIT: das ganze programm dreht sich bei mir eigentliuch um diese liste mit den tupeln, ist es dann empfehlenswert wenn ich vllt ne extra klasse "liste.h" mach, die die ganzen operationen innehält, wäre vllt sinnvoll oder? dann wäre die GUI getrennt von der verarbeitung der liste? aber instanziieren müsst ich sie ja trotzdem in der openglklasse, dass ich vom eltern widget au zugriff hab oder?

[Illuminatus]

hi also ich habe mir was überlegt, es wird einem ja empfohlen GUI und verarbeitung zu trennen...

Bisher habe ich eine main.cpp (aufruf von QApplication und erstellen der dbvis hauptfenster). Dann die dbvis.cpp die sich um die GUI kümmert. Sie hatte bisher die ganzen Elemente der GUI sowie die Methoden der Verarbeitung (Verbindungsaufbau, Listenaufbau, Liste auslesen,...) drinnen!
Sie hatte ebenfalls als CentralWidget eine Instanz der Klasse opengldrawer, die sich eigentlich mit dem Zeichnen der Objekte beschäftigen sollte...

Meine Idee ist nun die ganzen Methoden der Verarbeitung in eine handle.cpp auszugliedern sodass die dbvis (von QMainWindow abgeleitet) nur noch die SignalSlots implementiert um mit den SignalSlots der handle und denen der opengldrawer zu kommunizieren. Die QListe<tupel> befindet sich danach auch in der handle als Variable.

Das Problem ist dann aber wiederrum dass sowohl die instanz anzeige (als centralwidget) von opengldrawer als auch die dbvis zugriff auf eine instanz der klasse handle benötigen!!! @franzf: du hast vorgeschlagen in der opengl klasse im konstruktor einfach einen pointer auf den parent zeiger zu erstellen (oder??^^) , das geht aber nicht, da ich dann in der opengldrawer.h einen #include "dbvis.h" einfügen müsste und er sozusagen sich wieder selber verweist (da in dbvis.h auch die anzeige als instanz von opengldrawer deklariert wird) auf jeden fall wirft VS08 da lauter fehler.
die andere möglichkeit wäre in der opengldrawer klasse eine instanz von handle einzuführen und dass ich dann in der GUI Klasse dbvis Zugriff habe auf die Liste, den Verbdinungsaufbau und alle in handle definierten methoden über anzeige->instanzofhandle->function() oder anzeige->instanzofhandle->getliste() ...

ist das empfehlenswert? ich mein rein technisch wärs ja problematisch wenn das opengl fenster geschlossen wird, weil dann ja der pointer auf die handlevariable verloren geht bzw. auch die instanz aber da zur gesamten laufzeit ja die opengl oberfläche offen ist, müsste das doch gehen oder? man könnte ja auch en extra pointer (für dbvis) definieren der dann die adresse hält, dann müsste man nicht jedesmal über den poiinter der opengldrawerklasse gehn=

[Illuminatus]

hi
hat niemand von euch ne idee???