Klotzkopp

Pauschal lässt sich das nicht feststellen. Das PE-Dateiformat beinhaltet AFAIK keine diesbezüglichen Informationen. Allerdings können die DLLs, die das Programm braucht, Hinweise geben. Mit dem Dependency Walker (gibts beim Visual Studio 6 oder hier) kann man sich die abhängigen DLLs anzeigen lassen. MSVCRT.DLL oder MSVCRTD.DLL sind ein eindeutiges Indiz für Visual C++, bei VB-Programmen sollte eigentlich immer eine VBRUN*.DLL dabei sein. .NET-Programme brauchen immer MSCOREE.DLL. Eine Unterscheidung zwischen den einzelnen .NET-Sprachen könnte schwierig werden.

Es könnte an einem ungültigen Pixelformat liegen. Der Graphics-ctor Graphics::Graphics(Image*) schlägt bei den folgenden Pixelformaten fehl: PixelFormatUndefined PixelFormatDontCare PixelFormat1bppIndexed PixelFormat4bppIndexed PixelFormat8bppIndexed PixelFormat16bppGrayScale PixelFormat16bppARGB1555 Du kannst das testen, indem du nach dem Erzeugen des Graphics-Objekts den Status prüfst: Status s = graphics.GetLastStatus(); Wenn dabei nicht Null (bzw. Ok) rauskommt, hat es nicht geklappt. Dann kannst du versuchen, einfach mal ein anderes Format vorzugeben.

Je nach Bitmap kann ein halbtransparenter, grauer Text schwer zu erkennen sein. Mach den Text doch mal gelb und deckend: SolidBrush solidBrush(Color(255, 255, 255, 0));

Ist das denn nicht das, was du willst? Wenn der gemalte Text nicht den Bildinhalt überschreibt, sieht man den Text doch nicht. :confused:

Wobei brauchst du denn Hilfe? Weißt du nicht, wie man die Dateien durchgeht, oder geht es um den Text? Das sollte mit Graphics::DrawString machbar sein.

Schau doch mal hier rein: http://www.codeproject.com/property/scrollproppage.asp

In diesem Forum: Geht nicht.

Das war wenig hilfreich. Etwas präziser: http://msdn.microsoft.com/library/en-us/vcmfc98/html/_mfc_ctooltipctrl.asp

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.