Klotzkopp

Du irrst dich: http://msdn.microsoft.com/library/en-us/cpguide/html/cpconnetframeworksystemrequirements.asp

Das ist dann aber nicht Standard-C++, sondern Borland-spezifisch.

Oben hast du <string> eingebunden, nicht <string.h>. Das ist ein ziemlich großer Unterschied. string mit kleinem s.

Zeig doch bitte deinen Code. P.S.: Threadtitel berichtigt.

Verschoben -> Anwendungssoftware

Willst du das selbst programmieren, oder suchst du nur ein Tool? Ist dir klar, dass die Umwandlung einen Qualitätsverlust mit sich bringt?

Das ist eine Eigenschaft aller Fließkommatypen. In float und double passen nur ganz bestimmte Werte hinein, und wenn du einen Wert ablegen willst, der nicht genau passt, wird der nächstliegende passende Wert benutzt. Der liegt in deinem Fall knapp unter dem gewünschten Wert - er könnte auch darüber liegen. Du könntest auf zwei Stellen nach dem Komma runden, indem du 0.005 addierst. Oder du könntest gleich Hundertstel speichern und Ganzzahltypen benutzen, falls der Wertebereich ausreicht.

Weil damit deine Benutzeroberfläche vom Windows-Standard abweicht. Und das sollte man nicht ohne guten Grund tun. Ich würde mich sehr wundern, wenn ich einen Dialog nicht mit der Escape-Taste schließen könnte. Du prüfst den Nachrichtentyp (pMsg->message) auf WM_KEYDOWN. Falls der passt, kannst du in den anderen Membern nachsehen, ob es die richtige Taste ist. Was da drin steht, hängt vom Nachrichtentyp ab, aber das ist in der MSDN Library dokumentiert. Bei WM_KEYDOWN steht in pMsg->wParam der virtuelle Tastencode. Entscheidend ist, was du aus PretranslateMessage zurückgibst. Wenn die Nachricht normal behandelt werden soll, gibst du 0 zurück, ansonsten irgendeinen anderen Wert.

Die Dialoghilfetexte sind anscheinend in %WINDIR%\Help\windows.hlp. Wenn man winhlp32.exe mit der richtigen Hilfe-ID startet, sollte das funktionieren. Aber die richtige Hilfe-ID herauszubekommen, könnte schwierig werden.

Es ist aber das Standardverhalten unter Windows: Modale Dialoge schließen sich, wenn man die Escape-Taste drückt. Davon solltest du nicht ohne guten Grund abweichen. Benutzer, die gut mit der Tastatur umgehen können, dürften sich über dieses Verhalten zumindest wundern. Du bekommst in Dialogen keine Tastaturnachricht für die Escape-Taste. Die wird schon vorher in einen Schließbefehl übersetzt. Du könntest das in PreTranslateMessage abfangen, aber ich empfehle dringend, das nicht zu tun. Kannst du keine andere Taste dafür benutzen?

Sobald du mit einem Programm auf die Datenbank zugreifst, ist es mehr oder weniger egal, wie gut du dich mit dem GUI des DBMS auskennst, denn das benutzt du dann gar nicht mehr. Und falls du nicht gerade vorhast, die Automatisierungsschnittstelle von Access zu benutzen - und danach hört es sich nicht an -, sind auch spezifische Befehle des UI für dich nicht mehr interessant. Es reduziert sich alles auf SQL und die Schnittstelle zwischen Programmiersprache und Datenbank - und die ist vom verwendeten DBMS weitgehend unabhängig. Insofern sind auch baba007s Ausführungen eher am Thema vorbei. Zumindest, wenn die DBMS, die er vorschlägt, keine eigene Schnittstelle für .NET mitbringen.

Tastaturnachrichten gehen an das Fenster, das den "Fokus" hat. Das ist mit hoher Wahrscheinlichkeit nicht dein Dialog, sondern eines der Steuerelemente auf dem Dialog. Warum willst du denn die Escape-Taste abfangen.

In diesem Fall: Umschlag, Verpackung. Eine objektorientierte Hülle um die prozedurale WinAPI. CMenu::SetMenuItemInfo macht aber nicht viel mehr, als ::SetMenuItemInfo aufzurufen. Das ist ein ziemlich dünner Wrapper. Wie jede andere Funktion auch. Allerdings musst du, wenn Namenskonflikte mit Memberfunktionen bestehen, den Scope-Operator davor setzen. Hier ist das aber nicht der Fall.

Du kannst auch die globale WinAPI-Funktion SetMenuItemInfo benutzen. Die CMenu-Methode ist nur ein Wrapper um diesen Aufruf.

http://msdn.microsoft.com/library/en-us/vclib/html/vclrfcmenusetmenuiteminfo.asp Irgend jemand lügt... Oder bist du unter CE zu Gange? Dann solltest du das schon vorher sagen.

Der Router sollte anzeigen können, welche Adressen er als DHCP-Server vergeben hat. Oben hast du noch geschrieben: Was denn nun?

Naja, fast DynDNS bringt nichts, wenn die dynamische IP-Adresse nicht regelmäßig aktualisiert wird. Irgend jemand muss bei DynDNS Bescheid sagen, wenn sich deine IP-Adresse ändert. Vermutlich kann das dein Router, aber das musst du am Router eintragen. An der Kamera sollten diese Eintragungen nicht notwendig sein. Die Kamera hängt hinter dem Router und weiß somit im Normalfall gar nichts von der externen (dynamischen) IP-Adresse. Damit die Anfrage von außen auch bei der Kamera ankommt, muss du am Router einstellen, dass Anfragen auf Port 81 auf die internet (LAN) IP-Adresse der Kamera weitergeleitet werden. Das ist die Adresse, die der DHCP-Server im Router der Kamera verpasst hat.

Ach Mir ist nicht klar, was du mit "die DynDNS" meinst. DynDNS ist ein Dienst, der eine Namensauflösung für dynamische IP-Adressen anbietet. Was genau hast du also eingetragen? Hängt die Kamera am Router? Siehe oben bezüglich "die DynDNS". Tja, dann hast du wohl beim Einrichten der DynDNS-Aktualisierung auf dem Router etwas falsch gemacht. Falls du das überhaupt gemacht hast. Oder macht das die Kamera? Meine Fragen beantwortest du ja nur manchmal. Erklär doch bitte mal ganz genau, was du wo eingerichtet hast, und was wo dran hängt.

Ja, das war falsch. Du musst im Router den Port 81 auf die lokale IP-Adresse der Kamera weiterleiten. Wer kümmert sich denn jetzt um die DynDNS-Aktualisierung? Die Kamera oder der Router? Stimmt die IP-Adresse?

Bitte was? Was hat das HTT-Protokoll mit DynDNS zu tun? Hast du den Port 81 auf die Webcam weitergeleitet? Das ist dann nicht mehr lokal. Was sagt dir denn http://wieistmeineip.de/?

Hast du den Port 81 auf die Webcam weitergeleitet? Funktioniert es lokal? Stimmt die IP-Adresse, die Dyndns aktuell liefert, überhaupt? Du meinst hoffentlich im Router.

Das musst du schon ein wenig mehr Informationen liefern. Welche Art von Internetanbindung hat dieser Rechner? Bekommt er regelmäßig eine neue IP-Adresse? Falls ja, aktualisierst du das bei Dyndns? Sitzt der Rechner möglicherweise hinter einem NAT-Router? Falls ja, hast du den Port weitergeleitet? Ist auf dem Rechner überhaupt ein Webserver installiert? Übrigens: Ping geht gerade nicht.

Wo stehen denn diese Zeilen? Vermutlich überschreibt jede Zeile den Wert der vorhergehenden. Schreib das mal in eine Zeile: path=c:\Borland\Bcc55\bin;c:\masm32\bin;c:\jdk1.3.1\bin

Das klingt wie der Anfang eines schlechten Witzes. Fehlermeldungen dienen nicht dazu dich zu ärgern, sondern dir Hinweise auf die Fehlerursache zu geben. Wenn wir dir dabei helfen sollen, ist es immer von Vorteil, wenn du die Fehlermeldung dazuschreibst. *gebetsmühlewegpack*

http://www.dependencywalker.com/ So etwas nennt sich Debugger. Das geht aber nur, wenn du Debuginformationen für die DLL hast.