Klotzkopp

Warum sollte das nicht gehen? Sag nicht einfach "geht nicht", sag, wo das Problem liegt (siehe meine Signatur). Bekommst du eine Fehlermeldung? Wenn ja, wie lautet die? Außerdem brauchst du für einen Zeiger- oder Referenzmember keine vollständige Klassendefinition. Eine Vorwärtsdeklaration tut's auch. Schreib einfach class CData* NameDerMembervariablen; in den Definitionen der Page-Klassen. Das ist alles viel zu kompliziert. Du ziehst die richtigen Schlüsse aus falschen Beobachtungen.

Du kannst die Pfade zusammenführen. Schau dir an, wie mrdck das gemacht hat.

Die Lösung ist falsch, weil du zuerst auf "Neuer Kunde" und dann auf "Ausland" prüfst. Damit ist es einem neuen Kunden immer möglich, bei Beträgen <= 25 Euro das Online-Bezahlsystem zu benutzen, auch wenn er aus dem Ausland kommt. Das widerspricht der Aufgabenstellung. Außerdem ist der Ablaufplan unnötig redundant. Die Kreditkartenprüfung und die Bezahlsysteme "Kreditkarte" und "Vorauskasse" müssen nicht doppelt vorhanden sein.

Nein. Das müsstest du nur, wenn du meinen Ansatz verfolgen würdest. Aber du willst ja die statische Variable. Da brauchst du nicht mal eine Instanz von CData. Du kannst einfach mit CData::deineStatischeVariable darauf zugreifen.

Der Code ist richtig. Nur die Position ist falsch. Statische Member müssen auf globalem Scope (also nicht in einer Methode) definiert werden. @Kampfkartoffel: Überleg dir noch mal den Ansatz, den ich vorgeschlagen habe. Das ist sauberer, als die Member statisch zu machen.

Das ist - wie du selbst schon bemerkt hast - ein Fehler. Irgendwo erzeugst du doch diese Page-Objekte. Da kannst du doch einfach die Adresse eines einzelnen Datenobjekts an einen Member-Zeiger in jeder Seite übergeben. Dann haben alle Seiten einen Zeiger auf dasselbe CData-Objekt.

Unsinn. Wie äußert sich denn dieses "Meckern". Sprich: Wie lautet die genaue Fehlermeldung? Gar nichts. Zeig mal deinen Code. Und weil das offenbar nichts mit .NET zu tun hat: Verschoben -> C++: Compiler, IDEs, APIs

Doch, ist so. Jede Wette. Vermutlich bindest du id3lib_ext.h selbst und zusätzlich eine Headerdatei ein, die wiederum id3lib_ext.h einbindet. Dagegen helfen Includewächter: Am Anfang der Headerdatei #ifndef ID3LIB_EXT_H_INCLUDED #define ID3LIB_EXT_H_INCLUDED[/CODE] und am Ende [CODE]#endif Der Name (ID3LIB_EXT_H_INCLUDED) ist egal, es darf nur nicht zur Kollision mit anderen Namen kommen.

Nein. Jaja, das kenn' ich Ja. Wenn du das Programm im Debugger startest, kannst du in der Ausgabe die Trace-Meldung sehen. Da drin steht die ID des Steuerelements, das an dem Ärger schuld ist. Du kannst dir auch nIDC auch einfach im Debugger ansehen. In der resource.h kannst du die symbolische Konstante für diese Zahl raussuchen.

Es wäre sehr hilfreich gewesen, wenn du dazu geschrieben hättest, in welcher Datei bzw. Funktion dieser Code steht. Ich vermute, du hast in deiner DoDataExchange-Methode einen Datenaustauschbefehl für ein Steuerelement, das nicht (mehr) da ist.

Kannst du auch einzelne Satzzeichen machen? Nein. Behaviour by design, auf beiden Seiten.

Wieso schreibst du "Frage" davor? Das liegt daran, dass Windows Bytes anders in GBytes umrechnet als die Plattenhersteller.

In dem Variant steckt kein double, sondern ein Safearray von doubles. Falls die Verwendung der ATL erlaubt ist, würde ich den pparray-Member des VARIANT in ein CComSafeArray packen. Darüber kann man dan recht einfach die einzelnen doubles rausholen.

Und genau das ist bei einer Volumenlizenz der Fall. Wo ist das Problem? Du kannst dir selbst eine Installations-CD mit integriertem SP2 erstellen. Das ist von der verwendeten Lizenz unabhängig.

http://www.microsoft.com/germany/lizenzen/ueberblick/unternehmen.mspx

Volumenlizenzen gibt es AFAIK erst ab 5 Lizenzen. Wie viele brauchst du denn?

Verschoben -> Windows

Nein, mein Beispiel sah so aus: A / \ B C / \ D E / F[/code] Ich weiß nicht, welchen Browser du benutzt, aber sowohl beim Internet Explorer als auch beim Firefox kann man da genau sehen, dass F der linke Kindknoten von E ist. Willst du mich veräppeln? Du bist doch derjenige, der keine Codetags benutzt :confused:

In meinem Beispiel hat D keine Kindknoten, weder links noch rechts. In deinem Beispiel kann man das nicht erkennen, weil du keine Code-Tags benutzt hast, und damit die Einrückung verloren geht. Wenn bei deinem Beispiel F der linke Kindknoten von D sein soll, ist deine Rotation natürlich richtig. Allerdings hilft dir das nicht viel. Ich habe mein Beispiel ja absichtlich so gewählt, dass eine einfache Rotation nicht ausreicht.

Nicht, wenn wir von meinem Beispiel ausgehen. Bei deinem ist das mangels Einrückung nicht wirklich zu erkennen. Mein Beispiel war A / \ B C / \ D E / F[/code] In meinem Beispiel ist D das kleinste Element.

Ob du eine einfache oder eine Doppelrotation brauchst, hängt vom Balancewert des linken Kindknoten des Knotens ab, der -2 hat.

Nur, um sicher zu gehen. Wir reden hiervon: vorher: A / \ B C / \ D E / F nachher: B / \ D A / / \ F E C[/code]Das ist deine "Rotation". Richtig? Vorher ist D < B < F, nachher ist F < D < B. Entweder hast du nicht verstanden, was ich im letzten Beitrag geschrieben habe, oder du glaubst es mir nicht. Du darfst die Reihenfolge nicht ändern. Mit "Reihenfolge" meine ich die, die sich durch die Ordnungsrelation ergibt. Und deine Umformung ändert diese Reihenfolge in Bezug auf F und D bzw. B. Deine Umformung ist keine Rotation. Sie macht den Baum kaputt. Du musst mir nicht glauben. Aber wenn du es nicht tust, kann ich dir nicht helfen.

Richtig. Und dieses Verhalten ist beabsichtigt. Steht alles in der MSDN Library. Da steht sogar, wie du testen kannst, ob die Verbindung noch besteht.

Was meinst du mit "rauskommt"? Nein. Du musst die Ordnung getrennt von der Struktur betrachten. Ein AVL-Baum ist eine Datenstruktur, die ihre Elemente sortiert. Der linke Kindknoten ist immer "kleiner", der rechte "größer" als der Elternknoten. Es gibt bei mehreren Elementen mehrere Möglichkeiten, diese Relation in einem Baum auszudrücken. Aber nur wenn die Balancewerte möglichst klein sind, ist eine optimale Suchgeschwindigkeit gewährleistet. Die Rotationen im AVL-Baum ändern nicht die Reihenfolge der Elemente im Bezug auf die Ordnungsrelation. Sie ändern nur die Balance. Die Reihenfolge darf sich nicht ändern, sonst geht die Sortierung des Baums verloren. Deswegen ist deine Umformung unzulässig. Die Struktur muss man natürlich so ändern, dass die Balancewerte wieder zwischen -1 und 1 liegen. Und da zeigt dir mein Beispiel, dass eine einfache Rotation nicht ausreicht. Du brauchst die bei Wikipedia beschriebene Doppelrotation, wenn bei einem Balancewert von -2 der Wert des linken Kindknotens positiv ist - eben wie in meinem Beispiel.

Äh, solche Bäume liest man nicht zeilenweise. Das ist nicht eindeutig. Man beginnt beim Knoten ganz links und liest dann Linker Teilbaum - Elternknoten - Rechter Teilbaum. Bei jedem Teilbaum fängt man wieder ganz links an. In meinen Beispiel kommt dabei vor und nach der Rotation dasselbe raus: DBFEAC. Nach deiner "Rotation" sieht es so aus, als ob F der linke Kindknoten von D wird. Das ändert die Reihenfolge.