[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Mal abgesehen von den Problemen, die durch "make" erzeugt werden, wenn man das Makefile nicht ganz perfekt anlegt - irgendwie wundere ich mich doch sehr über das Design. Mir ist schon klar, das es hier um Beispielcode geht, aber eine nicht-konstante Referenz eines privaten Datenmembers aus einer Klasse herauszureichen, würde mich in "freier Wildbahn" zu etwa folgendem Dialog mit dem entsprechenden Programmierer veranlassen:

Binde?

Zigarette?

Ein letzter Wunsch?

[ - Answer - Quote - Direct link - ]

@Solar:

Bin in C++ ziemlich blutiger Anfänger (obwohl das ja eine Designfrage ist und daher eigentlich von der Prog.-Sprache unabhängig).

Aber wie würdest Du/"man" das dann designen?

Im konkreten Fall hab ich eine Window-Klasse, die eine nicht konstante Referenz auf ihr RastPort-Objekt zurückgibt, damit man darin Operationen fahren kann.
Wenn ich die Referenz konstant mache, muss ich alle Public-Methoden der RastPortklasse ebenfalls konstant machen, damit darauf von außen zugegriffen werden kann.
Bin mir nicht sicher, ob das geht, da die RastPortklasse einen Zeiger auf ne RastPort-Struktur kapselt und darauf z.B. Blitoperationen macht und sich dabei ja die RastPort-Struktur ändert (allerdings nicht der Zeiger darauf, mit dem ja gearbeitet wird - geb ich zu).

Wie erstellt man da ein Design, dass mit konstanten Referenzen arbeiten kann bzw. wie stellt man dann das Design um?

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Reth:

Wie erstellt man da ein Design, dass mit konstanten Referenzen arbeiten kann bzw. wie stellt man dann das Design um?

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Das Klassendesign läßt sich nie von der Anwendung trennen. Es geht ja darum, was Du wie abbilden mußt und worauf Du den Zugriff braucht usw. - es bringt ja nix, wenn ich Dir erzähle, mach dieses oder jenes const, aber Du kannst dann hinterher nicht damit arbeiten. So ein Murks wie oben weist meiner Erfahrung nach darauf hin, daß das Klassenmodell schlecht ist. Aufgrund meiner fehlenden Erfahrung fällt mir aber eben nicht auf die Schnelle ein besseres ein, und vielleicht "muß das so" in der GUI-Programmierung, was weiß ich.

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Reth:
Im konkreten Fall hab ich eine Window-Klasse, die eine nicht konstante Referenz auf ihr RastPort-Objekt zurückgibt, damit man darin Operationen fahren kann.
Wenn ich die Referenz konstant mache, muss ich alle Public-Methoden der RastPortklasse ebenfalls konstant machen, damit darauf von außen zugegriffen werden kann.

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Reth:
Ist so ähnlich wie die Graphics-Klasse in Java.

Es wird immer in einen RastPort gezeichnet, nicht in ein Fenster und nicht in einen Screen.
Daher hat die Fensterklasse ein RastPort-Member. Dieses kann man sich besorgen, um dann die Zeichenoperationen darauf auszuführen.

---

Zitat:

---

Wenn man will kann man auch ein eigenes RastPort-Objekt anlegen und darin herumzeichnen.
Was man bei meiner Konstruktion allerdings (bisher) nicht kann (und auch erstmal nicht können soll), ist einem Fenster einen neuen RastPort zu setzen.

---

C++ code:

---

class Painter
{
  virtual void paint(RastPortObj& rp);
}

class Window
{
  //... bißchen was weggelassen ;)
  public:
    setPainter(Painter& p);
  protected:
    void refresh();
}

Window::refresh()
{
  windowPainter.paint(new RastPortObj(intuiWindow->RastPort));
}

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Holger:
Zeichenoperationen sind an sich nicht kritisch. Aber RastPort wie Graphics besitzen einen Zustand wie aktuelle Zeichenfarbe, Zeichenmodus, Line Pattern, etc.
Man sollte sicherstellen, daß zu Beginn eines Refreshs ein definierter Ausgangszustand herrscht. Das kann man erreichen, in dem man immer eine Kopie resp. neuen RastPort herausgibt oder alle Attribute zurücksetzt.

...

Deshalb ist eine getRastPort-Methode auf einem Fenster nicht sinnvoll. Dem Fenster sollte die fürs Zeichnen zuständige Instanz bekannt sein, an die es den Refresh delegieren kann.

Vereinfacht so:

C++ code:

---

class Painter
{
  virtual void paint(RastPortObj& rp);
}

class Window
{
  //... bißchen was weggelassen ;)
  public:
    setPainter(Painter& p);
  protected:
    void refresh();
}

Window::refresh()
{
  windowPainter.paint(new RastPortObj(intuiWindow->RastPort));
}

---

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Reth:
Wird da bei setPainter() im Window der internen Variable windowPainter die Referenz auf p zugewiesen, oder sind das 2 unterschiedliche Painterobjekte, die da im Spiel sind?

---

code:

---

windowPainter=p;
requestRefresh();

---

Zitat:

---

Wie kommt man denn in obigem Bsp. an Blitfunktionen und so Sachen wie Vordergrund-/Hintergrundstift setzen dran?
Momentan sind das Methoden meiner RastPortklasse, die public sind, da man ja die Darstellung beeinflussen will.
Wird im Painterobjekt gesammelt, so lange, bis paint() gerufen wird?

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Holger:
Ne, ne, is schon so, wie Du denkst. setPainter() macht das, was Du von einer set... Methode erwarten würdest. Ala

code:

---

windowPainter=p;
requestRefresh();

---

---

Zitat:

---

Was willst Du sammeln? Du hast Objekte, die einen Status haben, und wenn der sich ändert mußt Du einen Refresh triggern, z.B. mit einer Methode ala requestRefresh(); auf dem Fenster (die Du natürlich schreiben mußt...), funktional vergleichbar mit repaint() in Java. Optional sollte man auch einen Bereich übergeben können, der dann zur damagedRegion des Layers hinzugefügt werden kann.

---

code:

---

painter.blit(...);
window.requestRefresh();
...
// im Painter
rastPort.blit(...);

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Reth:
Hm, ich seh gerad nur nicht, wo die letztendliche Implementation der Blitroutinen sein soll? Im Painter oder im RastPort, oder delegiert der Painter an den RastPort, wenn er was neu zu zeichnen hat?

---

C++ code:

---

class MainWindowPainter:public Painter
{
  Image* background;
  Painter statusBarPainter;
  Painter levelPainter;
  void paint(RastPortObj& rp)
  {
    rp.blit(background, 0, 0);
    statusBarPainter.paint(rp);
    levelPainter.paint(rp);
  }
}

MainWindowPainter mainWindowPainter;
window.setPainter(mainWindowPainter);

//...

//...

//change background
mainWindowPainter.background=newImage;
//change status bar
statusBarPainter.message="Watch the new background";
//and update display
window.requestRefresh();

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Reth:
Sollte es dann einen Painter geben, der z.B. einen Vector mit Bildern entgegennimmt und diese dann blittet?

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Reth:
Hm, dann würden bei mir aber für jedes Tile und jedes bewegliche Objekt ein eigener Painter entstehen, wenn ich den Objekten das Painter-Interface zuordne. Ist das nicht ein bisschen viel?

---

Zitat:

---

Dachte eher daran, dass ein Painter (oder wie bei mir bisher ein RastPort-Objekt) alles macht, ähnlich dem Graphics-Objekt von Java-Components (das kann man ja auch nicht setzen).

---

Zitat:

---

Der Statuspainter würde dann z.B. in meinem Fall ein Array(Liste) aus Strukturen (Objekten) übergeben bekommen mit Texten und Positionen dazu, um die Ressourceninformationen zu schreiben.

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Holger:
Nein, erzeuge einfach exakt so viele Objekte, wie Du es jetzt auch schon tust. Ist jedes tile ein einzelnes Objekt -> ok, dann ist jedes tile auch ein eigenständiger painter. Gibt es kein tile Objekt, sondern ein Background-Objekt, das alle tiles als array o.ä. verwaltet -> ok dann wird dieses Background-Objekt zum painter.

---

Zitat:

---

So soll auch auf dem Window auch nur in Ausnahmefällen ein anderer Painter gesetzt werden. Normalerweise stellst Du ja immer das Gleiche dar, ein Level, eine Statusanzeige, ein paar Konfigurationsmögichkeiten, etc. Nur der Zustand dieser Objekte ändert sich. Und wenn das passiert, wird lediglich dem Fenster mitgeteilt, daß ein Refresh gewünscht ist. Der Painter bleibt derselbe.

---

[ - Answer - Quote - Direct link - ]

C++ code:

---

IntuiMSGReceiver::receive(struct MsgPort *Port)
{
    struct IntuiMessage *msg = (struct IntuiMessage *) GetMsg(Port);
    // reply und verarbeiten
}

---

[ - Answer - Quote - Direct link - ]