Klotzkopp

Delete kann wie jeder andere Methodenaufruf geinlinet werden. Kannst du nicht wissen. Es kommt hinzu, dass delete diesen Compare sowieso nochmal macht. Damit wird es zu einer statistischen Betrachtung. Wie oft kommt da ein Nullzeiger vor? Das if kann ja nur dann überhaupt einen Vorteil bringen, wenn der Zeiger tatsächlich Null ist. Die Frage ist also nicht, wieviele Objekte du hast, sondern wieviele du nicht hast. Was das Nullsetzen nach dem delete angeht, auch darüber kann man geteilter Meinung sein. Sinnvoll ist es, wenn ein Zeiger "recycled" wird, also während seiner Lebenszeit immer wieder mal auf ein Objekt zeigt, zwischendurch aber auch mal nicht. Bei einem Memberzeiger, mit dem das nicht passiert, ist das IMHO unsinnig. Mit der gleichen Argumentation könnte man int-Member im Destruktor auf 0 setzen - macht doch auch niemand. Meiner Meinung nach ist der Grund für das Nullsetzen von Zeigern einfach der, dass dieses Konstrukt sehr schön vor Abstürzen durch doppelte deletes schützt. Aber damit verdeckt man IMHO nur ein schlimmeres Problem. Denn wie kann es überhaupt zu einem doppelten delete kommen: Doch nur dadurch, dass man in der Designphase die Lebenszeiten und Besitzverhältnisse der Objekte nicht ordentlich festgehalten hat. Ich rate von solchen Konstrukten ab, weil sie IMHO schlampiges Design fördern.

Unnötig, da delete NULL nichts tut. Falsch. Delete ändert den "Wert" des Zeigers nicht.

Anscheinend hat jemand in CMultiTimeDlg::OnInitDialog den Aufruf von CDialog::OnInitDialog gelöscht.

Was soll das denn für eine Fehlerbeschreibung sein? Nö. Vermutlich sind irgendwelche Member der Struktur falsch oder gar nicht gesetzt.

Das Problem ist vermutlich, dass du die Strings erst hinzufügst, nachdem die Toolbar mit allen Buttons bereits erstellt wurde. Nachträgliche Änderungen an dem TBBUTTON-Array wirken sich natürlich nicht automatisch aus. Möglicherweise reicht es, wenn du danach nochmal für jeden Button TB_SETBUTTONINFO verschickst, damit die aktualisierten Stringindizes auch bei der Toolbar ankommen.

Die Position der Buttons solltest du dir besser mit TB_GETRECT direkt aus der Toolbar holen. Das Gefrickel mit den magischen Zahlen ist nicht so das Wahre. Was liefert dir SendMessage denn zurück?

Sehe ich das richtig, dass du mit reiner WinAPI zu Gange bist? Dann wäre wohl hier der richtige Einstieg für dich: About ToolTip Controls Und weil das kein Standard-C oder -C++ ist: Verschoben nach C++: Compiler, IDEs, APIs

Dein Problem hat also nichts damit zu tun, dass es sich um eine Config-Datei für einen Dienst handelt. Du hast anscheinend nur ganz allgemein Probleme mit der Benutzung von System.Xml. Dann schau dir doch mal XmlNode.Attributes an.

Üblicherweise werden neue Unterforen eingerichtet, wenn es in einem bestehenden Forum so viele Threads zu diesem Thema gibt, dass andere Themen an den Rand gedrängt werden. Das sehe ich hier aber nicht. Traffic zu einem Thema entsteht nicht von selbst, nur weil man ein neues Unterforum einrichtet. Bis dahin würde ich entsprechende Themen entweder ins Windows- oder ins .NET-Forum stellen, je nachdem, ob es um Administration oder Programmierung geht.

Du beschreibst weder, was du genau mit der Datei anstellen willst, noch, wo genau das Problem liegt. Einlesen? Ändern? Mit kann offenbar niemand etwas anfangen. Suchst du ein Beispiel, wie man eine XML-Datei einliest und ändert? Oder hat es am Ende doch etwas mit den spezifischen Inhalten zu tun? Etwas genauer bitte.

Das stimmt so nur für MOD 2, und trifft nicht den Kern der Sache. Das Ergebnis ist der Rest der Division. 5 MOD 3 ist 2, nicht 1.

Richtig. Ich meinte jedenfalls den neuen Kalender

Du musst die geänderten Bits aus K2 ausblenden, und die unveränderten aus K1': K2 := (K2 and ~diff) or (K1' and diff)

Es ist egal, ob du nach 'D' oder 0x44 oder 68 suchst, das ist immer derselbe Wert, nur die Darstellung ist anders. Darum brauchst du da auch nichts umzurechnen.

_msize funktioniert auch nur, wenn das Array auf dem Heap angelegt wurde, mit (c/m/re)alloc. Und dann hast du gar kein Array zum Übergeben, nur einen Zeiger

Nein. Array-Funktionsparametern werden in C und C++ nie kopiert, sondern immer "by reference" übergeben. Du kannst den Inhalt des Arrays also in der Funktion verändern. Eine weitere Besonderheit: Bei Array-Funktionsparametern geht die Größeninformation verloren. Du kannst also in der Funktion nicht mehr herausfinden, wie groß das Array ist. Auch eine explizite Größenangabe hilft da nicht. sizeof liefert dir die Größe eines Zeigers. Es gibt zwischen diesen Funktionen keinen Unterschied: void foo( int a[4] ); void foo( int a[] ); void foo( int* a );[/code]

Genauso. atoi wandelt eine Zeichenkette um, keine Einzelzeichen. Die Funktion bricht erst dann ab, wenn sie auf ein Zeichen trifft, das nicht als Teil einer Zahl interpretiert werden kann.

int alteBsNr = atoi( strstr( Hilfszeiger, ";YBYA" ) + 5 );

Diese Zeile ist kompletter Blödsinn. Zahl ist ein uninitialisierter Zeiger, da darfst du gar nichts reinschreiben Du brauchst Zahl auch gar nicht atoi gibt keinen char-Zeiger zurück. Du willst doch eine Zahl haben, oder? Warum suchst du nicht einfach mit strstr nach dem String, der unveränderlich vor der gesuchten Zahl steht, addierst die Länge dieses Suchstrings zu dem Ergebnis und wendest atoi darauf an? Wozu diese abenteuerlichen Verrenkungen?

Dann benutzt du atoi falsch. Ohne den Code kann dir da niemand weiterhelfen.

Natürlich steht in deinem Text der ASCII-Code. Aber das ist normal, und auch kein Problem. Wie kommst du darauf, dass das nicht funktioniert?

Initialisiere sock im Konstruktor mit Null. delete 0 tut nichts.

Auf jeder Seite hier, unter dem Link "Chat".

Eigenschaften sind IMHO dazu da, um von den Getter- und Settermethoden wegzukommen. Wenn deine Methode also wirklich nur dazu dient, einen Wert zu setzen oder zu holen, nimm besser eine Eigenschaft.

Die Aufrufe von CAsyncSocket sind eben asynchron, d.h. sie blockieren den Aufrufer nicht. Das heißt aber auch, dass die Aufrufe meistens zurückkommen, bevor der Vorgang abgeschlossen ist. Wenn der Vorgang dann abgeschlossen ist - erfolgreich oder nicht - wird der entsprechende Callback des Sockets aufgerufen. Darum bringt CAsyncSocket selbst auch meist nichts. Üblicherweise leitet man eine Klasse davon ab, um die Callbacks überschreiben zu können. Was du wann benutzt, hängt von der Architektur deines Programm ab. Wenn du warten kannst (z.B. weil du schon in einem separaten Thread zu Gange bist, oder kein UI vorhanden ist), kannst du CSocket benutzen. Wenn dein Programm so aufgebaut ist, dass du Anfragen absetzt und einfach nur eine Benachrichtigung bekommen willst, wenn die Anfrage bearbeitet ist, und währenddessen weiterarbeitest, nimm CAsyncSocket.