Klotzkopp

"\t", nicht "/t".

Normalerweise kommt man auf Blacklists, weil man ein offenes Relay betreibt, also Mails von jedermann für jedermann annimmt. Dass jemand geblacklistet wird, weil er nicht relayt, ist mir neu. Könnte es sich da um ein Missverständnis handeln? Blacklists gibt es viele, frag am besten den Provider nochmal, oder schau in die Newsgroup de.admin.net-abuse.mail.

Schau mal in meinen Beitrag vom 11.12.2002, 13:46 Uhr.

\t

Auch ich würde von Word-Dateien dringend abraten. Wer Word-Dokumente per Mail verschickt, zeigt in meinen Augen, dass er die Virenproblematik ignoriert und nicht über den Windows-Tellerrand schauen kann. PDF ist sicher und portabel.

Es ist nicht zufällig winmail.dat?

Das Drücken der ESC-Taste bei einer dialogbasierten Anwendung entspricht dem Klicken eines Buttons mit der ID IDCANCEL. Überschreibe CDialog::OnCancel, dann bekommst Du es mit.

Sondern? Füllst du dein RecordSet vorher mit gültigen Daten?

Wenn du eine Automatisierungsschnittstelle verwendest, muss der Automatisierungsserver (hier: Excel) installiert sein.

MoveNext und MoveLast zeigen gar nichts an. Aber sie füllen die an die Datenbankfelder gebundenen Variablen mit Werten, darunter auch dein DATE. Die Frage ist jetzt, ob der Wert überhaupt geändert wird, wenn in diesem Feld ein NULL-Wert steht, oder ob der Wert so gelassen wird, wie er ist. Deshalb solltest Du die DATE-Variable mit einem Wert vorbelegen. Wenn der Wert hinterher immer noch gleich ist, dann bewirkt ein NULL-Wert keine Änderung. Das könnte man als Erkennungsmerkmal heranziehen.

Das ist der Wert, mit dem bei einem Debug-Build uninitialisierter Freispeicher gefüllt wird. Darauf kann man sich also nicht verlassen. Wie sieht es aus, wenn Du vor dem MoveNext dem DATE den Wert -1.0 zuweist? Was für ein Wert steht dann nach dem MoveNext drin, wenn in der Datenbank NULL stand?

Du solltest einen NULL-Wert möglichst vor irgendwelchen Konvertierungen abfangen. Wenn ich mich richtig erinnere, hast Du doch ein DATE, dass Du in den COleDateTime konvertierst. Was steht denn in dem DATE, wenn in der Datenbank NULL steht?

Bitte beschreibe dein Problem genauer. Ratespiele gehören in den Daily Talk.

Hast du denn die Quellcodedatei, in der der Konstruktor von Anchor definiert ist, mit kompiliert und gelinkt?

Klasse* zeigervariable = new Klasse;

Jo, m_pCtrlSite darf NULL sein, das ist kein Problem. Kommt die Exception schon beim Aufruf von SetWindowText, oder irgendwo im MFC-Code?

Das reicht nicht. Du musst schon mit new eine neue Instanz der Klasse erzeugen.

Das sind aber zwei Schritte: 1. Dereferenzierung von t, dabei wird ein temporäres Objekt erzeugt 2. Umwandlung des temporären Objekts in char Der Compiler scheitert am ersten Schritt, weil der Datentyp des temporären Objekts void wäre. Und genau wie Du keine void-Variable anlegen kannst, muss auch der Compiler hier die Flügel strecken. Wenn Du die Reihenfolge änderst: 1. Umwandlung von t in char*, auch dabei entsteht ein temporäres Objekt 2. Dereferenzierung des temporären Objekts dann geht alles klar.

itemanzahl - 1 Die Indices gehen von Null bis Anzahl - 1.

Der erste Parameter von SetItemState ist der Index des Items. Die anderen beiden regeln, was mit dem Item passiert. Der zweite ist der Wert, der dritte eine Bitmaske. Wenn Du also ein Item selektieren willst, schreibst Du: m_ctrl.SetItemState( nItem, LVIS_SELECTED, LVIS_SELECTED ); Wenn Du die Selektion eines Items entfernen willst: m_ctrl.SetItemState( nItem, 0, LVIS_SELECTED );

So könnte man es nennen. Man kann jeden Zeiger implizit in einen void* konvertieren. Aber dereferenzieren kannst Du einen void* nicht. Was soll dabei auch rauskommen? Das hier geht: char z = *((char*)t);

Was für ein Objekt ist m_SNRAlias? Kannst Du in SetWindowText reinsteppen?

<Gebetsmühle> Was Du machst, ist ein Zeigervergleich. char-Strings vergleicht man mit strcmp. Achtung, strcmp gibt bei Übereinstimmung Null zurück. </Gebetsmühle>

FighterFigger hat Recht, es muss lauten: m_Grid.SetItemState( m_Grid.GetNextSelectedItem(pos), 0, LVIS_SELECTED );

__declspec(nothrow) ist ein Hinweis für den Compiler, dass diese Methode keine Exceptions wirft. Dadurch kann er sich einiges an Code sparen, der sonst für die Überwachung der Lebenszeit bestimmter Objekte benötigt würde. Exceptions unterdrücken kannst Du damit nicht. Bezüglich throw() in der Deklaration: Note Microsoft C++ does not support exception-specifications, as described in section 15.4 of the ANSI C++ draft. In addition, it does not support function-try-block described in section 15 of the ANSI C++ draft. Quelle: MSDN Library Oktober 2001. Was spricht dagegen, den ganzen Code der Funktion in einen try-catch-Block einzupacken?