Klotzkopp

Diese Antwort war unangemessen und unnötig. Frag dich doch mal, woran es liegt, wenn du wenige bis keine Antworten bekommst. Was erwartest du? Eine Nachhilfestunde in Regelungstechnik? Dafür wird sich kaum jemand die Zeit nehmen. Wo genau liegt jetzt bei dir das Verständnisproblem? Weißt du überhaupt etwas von Regelungstechnik? Weißt du, was proportional, integral und differential bedeutet?

Ich habe aber ausdrücklich gefragt, auf welchem OS du entwickelst. Und ob du die Unicode-MFC-Libs installiert hast, hast du auch nicht beantwortet

Ich wusste gar nicht, dass das auch mit ADO geht - wieder was gelernt :floet: Hier noch ein Link dazu.

@Angelius: Es geht um Active Directory, nicht ActiveX Data Objects. @k4fu: Die Problembeschreibung ist eigentlich schon ziemlich genau. @Smilla: Google, active directore create user vbs, erster Treffer

In jedem Buch sind Fehler, das lässt sich nicht vermeiden. Auch <iostream.h> ist nach dem aktuellen Standard (immerhin von 1998) falsch. Die C++-Standardheader haben kein ".h" am Ende. Und alle Funktionen, Klassen und Objekte stehen im Namespace std. Ich empfehle, dieses Buch nicht weiter zu benutzen. Leerzeichen in Variablennamen sind schon ein ordentlicher Schnitzer.

Auf welchem Betriebssystem entwickelst du? Hast du beim Installieren die Unicode-Versionen der MFC mit installiert?

Ich würde dir dringend dazu raten, entweder dein Programm so umzustellen, dass nur ein Thread auf die Datenbank zugreift, oder eine threadsichere Datenbankschnittstelle zu benutzen. Alles Andere ist in meinen Augen ein blutiger Hack. Du kannst übrigens über eine einfache statische Variable keine sichere Threadsynchronisierung erzeugen.

Allgemein gesagt ist das eine Vorrichtung, die im Schubbetrieb (wenn die Räder den Motor antreiben) die Treibstoffzufuhr abdreht. Technische Umsetzungen gibt es mehrere.

Wenn das Fahrzeug eine Schubabschaltung hat, ist es spritsparender, den Gang drinzulassen.

Dieser Beitrag bei CodeProject benutzt zwar C#, aber möglicherweise lässt sich das auf VB.NET übertragen.

Möglicherweise ist zu diesem Zeitpunkt der Stack bereits zerschossen. Zeig doch mal, wie du die Daten vom Socket einliest.

Du kannst bei MSVC 6 bleiben. Das Programm ist nur schon ziemlich alt, sogar älter als der C++-Standard. MSVC 2005 (Express Edition) gibt es kostenlos bei Microsoft.

Warum erledigst du das nicht einfach im Konstruktor?

Stimmt, es ist keine Standardfrage. Ich hatte mich da verguckt. Es geht übrigens noch kürzer: summe = accumulate(preise, preise + 10, 0.0); Dafür braucht man allerdings den Header <numeric>.

Geht doch! An dieser Stelle hält sich dein (ziemlich veralteter) Compiler nicht an den Standard. Du musst das "int" aus dem Initialisierungsteil der Schleife entfernen. Und es heißt "int main", nicht "void main".

Das habe ich schon verstanden. Du darfst daraus eben nur nicht den Schluss ziehen, dass das richtig ist. Das hatten wir doch schon. Bubble hat geschrieben, wie du das mit einer Schleife machen kannst. Und du hast geschrieben, dass das nicht geht. Und trotz mehrfachen Nachfragens hast du bisher nicht geschrieben, was genau nicht geht. Also bitte.

Das ist kein Argument. Das schon gar nicht. Der Code entspricht so nicht dem Standard. Dass der Compiler, den du da gerade benutzt, das so akzeptiert, macht den Code nicht richtig. perdi hat es doch schon gesagt: Was heißt "es geht nicht"? Eine ordentliche Fehlerbeschreibung ist die Grundvoraussetzung für jede weitere Hilfe.

Nein, eigentlich nicht. Beim Programmieren ist selten etwas "immer gleich". Sonst gäbe es da nicht so viel Arbeit. Weil es eben nicht "die" Lösung für jeden Anwendungsfall gibt. Jedes Problem ist anders. Deswegen hilft es auch nicht, Code zu kopieren, den man nicht versteht. Und auswendig Lernen hilft auch nicht. Man muss Lösungsstrategien lernen, nicht Lösungen. Dann frag nach. Wir beißen doch nicht. Versuche, den Sinn hinter dem Code zu verstehen. Code ist immer die Umsetzung der Absicht des Programmierers. Wenn du aus dem Code erkennen kannst, was der Programmierer damit erreichen wollte, dann bist du einen großen Schritt weiter. Das geht aber nur, wenn du weißt, was jede einzelne Anweisung des Codes tut. Dafür gibt es die Dokumentation. Das ist genau die Vorgehensweise, die dich nicht weiterbringt. Ich versuche mal, das zu veranschaulichen: Du willst einen Nagel in die Wand schlagen, hältst aber den Nagel falsch herum, und schlägst mit dem Hammer auf die Spitze. Da das offensichtlich nicht funktioniert, nimmst du einen anderen Hammer. Möglicherweise nimmst du irgendwann einen Hammer, der so groß ist, dass er den Nagel auch falsch herum in die Wand schlagen kann. Das beschädigt möglicherweise die Wand, und der Nagel wackelt ziemlich stark, aber dein Bild hängt mehr oder weniger. Das Ergebnis: Du hast es irgendwie hinbekommen, auch wenn es ziemlich lange gedauert hat. Aber vor allem: Du hast nicht gelernt, dass du auf das stumpfe Ende des Nagels schlagen musst. Du sollst es nicht ohne Variable benutzen, nur nicht mit einer lokalen. Denn die "lebt" nur, so lange diese Funktion läuft. Danach wird sie zerstört. Hinzu kommt, dass der Variablenname mit "m_" anfängt. Das macht man bei MFC normalerweise nur bei Membervariablen. Vielleicht gibt es sogar schon eine Membervariable mit demselben Namen. Ist das der Fall? Es ist richtig, dass man den Rückgabewert von GetDlgItem casten muss. Allerdings benutzt du GetDlgItem falsch. Was genau ist denn m_Button? Diese Argumentation musst du dir auch schnellstens abgewöhnen. "Beweis durch Beispiel" nennt man das, und es ist gefährlich, weil es instabilen Code erzeugt. Natürlich. Wieso nicht?

Weißt du denn, was ein P-, ein I- oder ein D-Regler ist? Ist dir klar, worin die drei sich unterscheiden?

Nein. Ich kann auch jetzt nicht alles. Bei so ziemlich jedem neuen Projekt gibt es eine Menge Dinge, die ich nicht kann. Das hat aber nichts mit der Vorgehensweise zu tun. Nein. Frickeln hilft nach meiner Erfahrung nicht beim Verstehen. Frickeln erzeugt unstabilen, redundanten Code, der so gerade eben auf der Entwicklungsmaschine läuft, und du weißt nicht mal, wieso. Man kann sich beim Programmieren die Lösung nicht durch Rumprobieren erarbeiten. Das liegt einerseits daran, dass es oft nicht "die Lösung" gibt, und andererseits daran, dass ein funktionierender Code nicht zwangsläufig gut ist. Du kannst hier fragen. Aber das bringt nichts, wenn du die Ratschläge nicht umsetzt. Glaub mir, so lernst du es nicht. Genau das meine ich. Beim Rumprobieren kommt Code heraus, von dem du nicht weißt, warum er funktioniert. Daher ist das ein grundlegend falscher Ansatz. Bleib doch mal bei deinem ersten Ansatz, setz die Hinweise um, die ich dir gegeben habe, und zeig, was dabei rausgekommen ist.

Welches Modul ist denn "dieses"? Ich weiß ja nicht, in welchem Modul deine Bitmapressource liegt. Im Zweifelsfall nimm AfxGetResourceHandle. "funzt garnicht" ist keine ausreichende Fehlerbeschreibung. Wenn das wirklich so in deinem Buch steht, wirf das Buch weg. Hast du meine Anmerkungen mal umgesetzt? Ohne Code kann ich dazu nichts sagen. Was ist "es"? Nimm's mir nicht übel, aber deine Vorgehensweise erzeugt bei mir den Eindruck, dass du gar nicht denkst, sondern nur rumfrickelst.

Lass LR_LOADFROMFILE weg und gib als ersten Parameter nicht NULL an, sondern das Instance-Handle des Moduls, in dem die Ressource liegt. Oder benutzt einfach CBitmap::LoadBitmap, wie in deinem ersten Code. Was meinst du mit "unused"?

Der Profiler von Compuware könnte was für dich sein. Mir hat er schon oft geholfen. Wenn du dich registrierst, kannst du ihn 45 Tage umsonst benutzen.

Doch. Und genau das ist hier notwendig (leider). Stichwort reinterpret_cast.

Und genau da steht auch folgendes: