Klotzkopp

Der "Call Stack", oder zu deutsch Aufrufstapel, zeigt die Funktionsaufrufe, die zur Zeit noch nicht zurückgekehrt, also in Bearbeitung sind. Man sieht hier z.B., dass es sich um eine Windowsanwendung handelt (WinMainCRTStartup). Nachdem Du InitInstace mit FALSE beendet hast, ruft das MFC Framework die Funktion exit auf (sieht man auch im Stapel). Danach wird die Laufzeitumgebung deinitialisiert. Das danach noch ein Destruktoraufruf erscheint (Access::~Access), kann eigentlich nur bedeuten, dass es sich um ein statisches oder globales Objekt handelt. In diesem Destruktor steht dann der ADO-Aufruf. Man sieht hier auch sehr schön, wie ADO alles an OLEDB weiterreicht. Die Ausnahme kommt vermutlich daher, dass ein ADO-Aufruf geschieht, nachdem bereits die gesamte Laufzeitumgebung runtergefahren wurde.

Die Exception kommt aus ADO. Ist Access ein globales Objekt, dass du selbst erstellt hast?

Bei einer Debug Assertion steht doch auch immer dabei, in welcher Datei und Zeile sie aufgetreten ist. Es wäre hilfreich, wenn du uns das sagen könntest.

Äh, es sind nunmal sieben Tage, nicht sechs...

Während ich dieses Thema in das passende Forum verschiebe, empfehle ich die Lektüre dieses FAQ-Beitrags.

Du kannst eine 16Bit-DLL nicht einfach so laden. Mit einem Vorgang, genannt "Flat Thunking" kannst du aus einer 32Bit-Umgebung auf 16Bit-DLLs zugreifen. Der Nachteil daran scheint zu sein, dass du einen 16Bit-Compiler brauchst. Allerdings wird hier, unter der Überschrift "Using the 16bit cards.dll library", ein alternativer Weg beschrieben.

Und? Ich denke, möglicherweise überflüssige Sicherheitsabfragen sind ein sprachübergreifendes Thema. Schade, dass du nicht auf den übrigen Inhalt meines Beitrags eingehst.

Eine Sicherheitslücke, die durch Ändern des Codes eintritt, gibt es wohl immer. Das kann ich auch haben, wenn ich snprintf benutze: "Du musst nur den zweiten Parameter größer machen als die Größe deines Puffers, ..." oder "Du musst nur mehr Formatstringfelder angeben als zusätzliche Parameter, ..." Das ist für mich kein Argument, und wenn es für dich eins sein sollte, dürfte snprintf auch nicht besser sein. Ich möchte ein anderes Beispiel bringen: Verwendest du grundsätzlich std::vector::at, auch an den Stellen im Code, an denen std::vector::operator[] mit Sicherheit ausreichen würde, weil keine Bereichsüberschreitung auftreten kann? Vorschlag: Ich füge dem FAQ-Beispiel den Hinweis hinzu, dass man auf Pufferüberläufe achten muss, wenn man die Länge des fertigen Strings nicht mit Sicherheit abschätzen kann, und verweise auf snprintf. Entschuldige bitte meine Zweifel, aber kannst du mich auf ein Kapitel verweisen? Ich finde das gerade nicht.

Falls du die STL benutzen kannst/darfst, würde sich std::queue anbieten.

Sehe ich genauso. Drum: Thema geschlossen.

Habe ich korrigiert, danke für den Hinweis. Ich. Solange ich eine Obergrenze ermitteln kann (und solange man mir keinen int zeigt, der Zahlen von mehr als 49 Stellen fasst, kann ich das hier), finde ich "NIEMALS" ein wenig hart. Wir reden hier immerhin nicht von gets. Wie sehen das die anderen? Wofür?

Was steht in dieser Zeile?

Wie ist der genaue Wortlaut der Exception/Fehlermeldung? Wie heißen die obersten Funktionen im Callstack?

Sieht nach einer Schutzverletzung aus. Versuch mal, die Exception zu Debuggen, und schau nach, wie der Callstack aussieht.

Ein einfaches #include "option1.h" sollte die Headerdatei zuerst in dem Verzeichnis suchen, in dem auch die Quellcodedatei steht.

Was für eine Exception kommt denn?

Du musst einen UPDATE_COMMAND_UI-Handler für die Command-ID anlegen. Was das ist und wie das geht, steht hier. In dieser Funktion kannst du dann mit pCmdUI->Enable( FALSE ) die Symbolleistenschaltfläche deaktivieren.

@Terran Marine: Danke @Azubi 2002: Zum Zwecke der Informationsbündelung weiterführende Fragen bitte im verlinkten Thema stellen. @Thema: Zu bist du.

Wie ich schon sagte: Lass den zweiten Dialog durch dieselbe Funktion anzeigen, die auch den ersten anzeigt. Der Wert, den du bei EndDialog als Parameter angibst, erscheint als Rückgabewert von DoModal: ... Modalen2Dlg dlg2; if( [B]25[/B] == dlg2.DoModal() ) { Modalen1Dlg healthdlg; healthdlg.DoModal(); ... void Modalen2gDlg::OnZuruck() { CDialog::EndDialog( [B]25[/B] ); } [/CODE]

Sauber ist das sicher nicht. Warum übergibst du beim Aufruf von EndDialog nicht einen Wert, an dem die Funktion, die Modalen2gDlg::DoModal aufgerufen hat, erkennt, dass danach Modalen1Dlg angezeigt werden soll? Zu dem anderen Problem: Was für ein Fehler tritt auf?

Da kannst du mit kbhit (auch aus conio.h) testen, ob eine Taste gedrückt wurde. Wenn kbhit nicht Null zurückgibt, kannst du getch aufrufen, und sicher sein, dass es nicht blockiert.

Die gibt's mit Sicherheit, aber wie ich schon sagte, nicht mit Standard-C. Du musst uns also schon verraten, für welches Betriebssystem und mit welchem Compiler du arbeitest.

Volt * Ampère ist dann nicht mehr Watt, wenn man Wechselspannungen und Wechselströme betrachtet. Wenn da die Schwingungen von Spannung und Strom nicht in Phase sind, ist Volt * Ampère erstmal nur "Voltampère". Wieviel Watt das sind, hängt vom Phasenunterscheid ab.

#include <iostream> using namespace std; int main() {[/CODE]

Und damit das ziellose Rätselraten ein Ende hat, mache ich hier vorerst dicht. @Eli78: Wenn du dein Vorhaben etwas genauer beschreiben kannst, bitte eine PN an mich, dann mache ich wieder auf.