Klotzkopp

Siehe hier: Multiple Monitor Applications on Different Systems Auch den Rest dieses Artikels solltest du aufmerksam lesen

Sollst du eigentlich nur die Registryeinträge machen, oder auch den Handler dazu schreiben?

Zum Erstellen von Registryeinträgen muss dein Code nicht in einer DLL sein. Der Shell Extension Handler selbst, der durch diese Einträge gesteuert wird, muss eine COM-DLL sein. Siehe Link in meinem Beitrag von 10:39 Uhr. Mit Sicherheit. Wie gesagt, zum Anlegen der Registryeinträge nicht. Der Shell Extension Handler selbst schon. Wo ist hier die Frage? Auch hier sehe ich keine Frage. Was meinst du mit "ansehen"? Du hast dir vermutlich Code für Shell Extension Handler angesehen. COM im Allgemeinen und Shell Extension Handler im Besonderen sind auch keine Anfängerthemen. Meiner Meinung nach ist dir am ehesten damit geholfen, dass du dir eine einfachere Aufgabe suchst. An dieser wirst du - wenn du niemanden findest, der es für dich macht - vermutlich scheitern.

Was heißt "nimmt nicht an"? Fehlermeldung? Absturz? MessageBox mit dem Text "Den nehme ich nicht an!"?

Das ist keine ausreichende Problembeschreibung. Das ist keine ausreichende Problembeschreibung. Registering Shell Extensions Das ist Unsinn. Weißt du überhaupt, was COM ist? Falls nicht, solltest du dich vorher darüber informieren. Das ist keine ausreichende Problembeschreibung. Das ist keine ausreichende Problembeschreibung. Das ist keine ausreichende Problembeschreibung. Bei dir ist das Hauptproblem, dass du nicht in der Lage bist, eine ordentliche Problembeschreibung abzuliefern. Anscheinend fehlt dir das Grundlagenwissen, um diese Aufgabe zu lösen. Wir können hier aber keine Einzelpersonenschulungen abhalten. Es gibt zwei Möglichkeiten: Du vergibst den Auftrag als Jobangebot im Stellenmarkt, oder du stellst hier konkrete Fragen. Beim nächsten Post der Art "Ich weiß nicht, was ich machen soll" oder "Ich komme nicht weiter" ist der Thread dicht.

Haben da zwei Benutzer gleichzeitig das Programm benutzt? Und eben habe ich dich auf mögliche Speicherlecks hingewiesen. Kann es sein, dass du ziemlich leichtfertig mit new um dich wirfst, und dazu neigst, delete zu vergessen? Das sagt nicht so viel aus. Aber zusammenfassend lässt sich sagen, dass du gar nicht weißt, was Update im Fehlerfall zurückgibt. Mein Rat: Such dein Programm erst mal gründlich nach Speicherlecks ab.

Nachtrag: Konntest du das Problem denn jetzt reproduzieren, oder gibt Update TRUE zurück, wenn sowieso alles klappt? Das wäre ziemlich uninteressant. Spannend wäre der Rückgabewert von Update, wenn der Fehler auftritt.

Wieso nicht? Erscheint die MessageBox oder nicht? Das Problem tritt sehr selten auf um es nachvollziehen zu können. Wie bitte? Was wird aktualisiert? Schönes Speicherleck. Gibt es in irgendeinem Zweig dieser Funktion ein delete zu diesem new?

Nein, musst du nicht. Laut unseren Boardregeln (deren Lektüre ich dir hiermit ans Herz lege) musst du dich für ein Forum entscheiden, und gegebenfalls den Moderatoren die Entscheidung überlassen, wohin dein Thread gehört.

Du lieferst nicht genug Informationen. Wird eine Exception geworfen, wenn das passiert? Wenn ja, was steht drin? Bist du wirklich sicher, dass es zu dem Zeitpunkt Datensätze gibt, die auf deine Bedingungen passen? Oder glaubst du nur, dass es so sein müsste? Lass dir doch vorher mal den Count ausgeben. CRecordset::Update hat nicht nur zum Spaß einen Rückgabewert. Was erhältst du da?

Genau dieselbe Frage hast du hier schon gestellt.

Genau. Zu diesem Zweck gibt std::vector::erase einen Iterator auf das nächste Element zurück, oder end(), wenn das letzte Element gelöscht wurde. Das bedeutet aber, dass man den Iterator nicht im Schleifenkopf inkrementieren darf, weil man sonst ein Element überspringt, oder über end() hinausgeht. Richtig sähe das dann so aus: for(vector<string>::iterator it = vec.begin();it!=vec.end();[b]/*nix*/[/b]){ if(str == *it) { it = vec.erase(it); } else ++it; }[/code]

Warum global und static? Und der Defaultkonstruktor wird sowieso aufgerufen. Wenn man nicht direkt nach einem Wert suchen kann, kann man std::remove_if nehmen.

Grundsätzlich geht das mit std::find (oder std::find_if) und std::vector::erase. Woran erkennst du denn das zu löschende Objekt? Nur an seiner Adresse?

Ja, so sieht es wohl aus.

Nein. Der Connector selbst ist von einer DLL abhängig. Und diese DLL ist möglicherweise keine .NET-DLL, sondern eine "normale". Die läuft aber nicht unter CE, und damit auch der Connector nicht. So steht es ja auch in der Dokumentation: Der Connector läuft nur unter Windows 2000 und XP.

Du solltest dir dringend angewöhnen, bessere Fehlerbeschreibungen abzuliefern. Wie der Name 'Fields' möglicherweise vermuten ließe, der Name des Feldes.

Könntest du dich bitte auf einzelne Satzzeichen beschränken? Hast du geprüft, dass jetzt die richtigen Daten ausgelesen werden? Und zeig mal, wie du versucht hast, die Daten abzulegen. Mit "es klappt einfach nicht" kann hier niemand etwas anfangen.

Da irrst du dich. In C gibt es keine Exceptions, zumindest nicht im Standard. Manche Compiler und Bibliotheken enthalten allerdings ähnliche Mechanismen. "Echte" Exceptions gibt es allerding in C++. Die Benutzung in C++ ist ähnlich wie in Java, allerdings gibt es keine "Checked Exceptions".

Wie weit bist du denn jetzt? Hast du es geschafft, die Eingabe in einen std::string einzulesen?

Die Dokumentation des Connectors ist doch eindeutig: Vermutlich liegt das an librfc32.dll. Wenn die native ist (also nicht .NET), kannst du damit auf einem Windows Mobile-Gerät nichts anfangen.

Moment, 7.0 ist VC++.NET 2002, 7.1 ist 2003, das hat mit Service Packs gar nichts zu tun. Der 7.0-Compiler hat gegenüber dem 6.0 keine großen Fortschritte gemacht. Der große Sprung kam von 7.0 auf 7.1. Der Compiler ist also noch ziemlich weit vom Standard entfernt. Dein Problem beruht anscheinend auf einem Bug des Compilers.

Aber nur, wenn du tatsächlich ein bestimmtes Format erwartest. Für mich ist eine Ausnahme immer ein unerwarteter Fehler. Wenn ich einen String parse, der syntaktisch eine Zahl sein kann, aber nicht muss, ist eine fehlgeschlagene Umwandlung für mich nichts Unerwartetes.

Du meinst boost::lexical_cast? Das tut in etwa das, was ich hier beschrieben habe Wenn man so eine Funktion benutzt, muss man die Exception natürlich fangen. Die Frage ist doch, ob es eine Ausnahmesituation darstellt, d.h. dass das Auftreten nicht vorhersehbar ist. Bei einer Benutzereingabe ist das sicherlich der Fall, aber IMHO nicht generell bei einer Umwandlung von Strings in Zahlen. Aber das ist vermutlich Geschmackssache.

Mir ist keine Standardfunktion bekannt, die in so einem Fall eine Ausnahme werfen würde. Kommt drauf an, wo man die Ausnahme fängt. Ausnahme bieten sich immer dann an, wenn die Fehlerbehandlung an übergeordneter Stelle stattfindet. Einen try-block um solche eine Umwandlung finde ich persönlich unangemessen. Das ist IMHO keine Ausnahme, sondern ein normaler Fall im Programmfluss.