Klotzkopp

Warum hast du die MessageBox auskommentiert?

Du hast nicht zufällig ein Antivirusprogramm installiert, das auch deine Mails prüft?

Neben den "Brute-Force"-Ansätzen wie bei kingofbrain und Der Kleine ist es übrigens auch möglich, das ganze auszurechnen. Eine Zahl n lässt sich genau dann als Summe von x aufeinanderfolgenden positiven Zahlen darstellen, wenn n geteilt durch x mindestens x/2, und, falls x ungerade ist, n modulo x gleich 0 ist, und falls x gerade ist, n modulo x gleich x/2 ist. Beispiel: 21 21 / 2 = 11,5 reicht 21 mod 2 = 1 passt 21 / 3 = 7 reicht 21 mod 3 = 0 passt 21 / 4 = 5,25 reicht 21 mod 4 = 1 passt nicht 21 / 5 = 4,2 reicht 21 mod 5 = 1 passt nicht 21 / 6 = 3,5 reicht 21 mod 6 = 3 passt 21 / 7 = 3 reicht nicht, weil 3 < 7/2, also gehts nicht weiter. Mit welcher Zahl die Summe dann anfängt, kann man auch ausrechnen. Kann aber sein, dass das durch die vielen Divisionen auch nicht schneller ist.

C-Strings sind immer durch ein Nullzeichen terminiert. Dein "ABCD" passt also gar nicht in ein Array von 4 TCHARs. Das Nullzeichen kopiert _tcscpy aber auch, und überschreibt damit (zumindest im Release-Build) möglicherweise eine andere Variable, die im Speicher hinter str steht. Da du beim Einlesen auch kein Nullzeichen hast, wird jede stringverarbeitende Funktion den Speicherinhalt hinter str fröhlich als Teil des Strings interpretieren, bis irgendwo im Speicher mal ein Nullzeichen steht. Außerdem solltest du bei Textdateien besser CStdioFile verwenden, da kannst du auch Zeilenweise einlesen.

Es gibt da mehrere Möglichkeiten: Du kannst - wie Darth_Zeus vorgeschlagen hat - fopen und fread verwenden. Das wäre sozusagen die C-Methode. Du kannst auch die C++-Streamklassen verwenden. Du kannst die WinAPI-Methoden CreateFile und ReadFile benutzen Oder, falls du die MFC verwendest, kannst du CFile/CStdioFile verwenden Was darf's denn sein? Und um was für eine Art von Datei handelt es sich ? Ist es eine Textdatei, die man zeilenweise einlesen könnte, oder enthält sie Binärdaten?

Verrätst du auch, was für ein Fehler auftritt? Oder zeigst ein wenig Code? Oder sollen wir raten?

Das kann ich dir erklären. Diese ganzen xl-Dinger (wie xlSortValue, xlAscending, xlNo) sind symbolische Konstanten für Zahlenwerte. Leider kann man die von C++ aus nicht benutzen, sondern man muss die Zahlenwerte selbst kennen. Das L kennzeichnet einfach nur den Datentyp als long.

Du reservierst zuwenig Speicher für helpst. Du brauchst noch ein weiteres Byte für das Nullbyte, das bei C-Strings als Endmarkierung verwendet wird, das strlen aber nicht mitzählt. l-3 sollte es also tun. Außerdem ist es eine Eigenart von strncpy, dass diese Funktion das terminierende Nullbyte nicht setzt, wenn der zu kopierende String länger ist, als man angibt. Das ist bei dir immer der Fall, also musst du das letzte char von helpst selbst auf Null setzen. Von Hand, mit einem Sortieralgorithmus deiner Wahl. Falls du C++ verwenden kannst, würde ich aber empfehlen, aus dem Array von char* einen std::vector<std::string> zu machen. Damit bist du nicht nur deine ganzen Probleme mit Arrays und Zeigern los, sondern kannst auch über std::sort komfortabel sortieren.

Eigenartig. Wie hast du das Automatisierungsinterface eingebunden? Importierst du die Typbibliothek oder hast du den Klassenassitenten verwendet? Wenn letzteres, wie sieht die Methodendeklaration von Range::Sort aus?

Mal abgesehen davon, dass das so nicht klappen kann, sind alle Parameter im Automatisierungsinterface Variants. Es sollte also mit 15mal covOptional klappen. Die Version mit 12 Parametern ist übrigens die von Excel 2000.

Es geht. Aber schlechter (weil wenig aussagekräftiger) Betreff und falsches Forum. --> Betreff angepasst. --> Verschoben nach: Delphi/VB/VBS/AS 400/C#/.net/Sonstige Trotzdem: Willkommen auf dem Board

Alle 15 Parameter von Range::Sort sind optional. Was passiert denn, wenn du überall einen optionalen COleVariant angibst?

try/catch kann nur dann funktionieren, wenn die Exception auch innerhalb des try-Blocks auftritt. Wie sieht denn der Code für die Eingabe aus? Machst du irgendwelche Berechnungen? Es wäre auch hilfreich, wenn du den genauen Text der Exception-Meldung postest. Das kann die Fehlersuche erleichtern.

Du hast keinen Unterpunkt "Platform SDK Documentation" im Inhaltsverzeichnis der MSDN Library? Hast du eventuell die MSDN Library nach dem Platform SDK installiert?

Naja, Teile davon sind auch .NET, was du nicht brauchst, oder gehören zum Platform SDK, das du samt Dokumentation kostenlos runterladen kannst. Die aktuelle MSDN Library selbst (als CD oder DVD) bekommt man AFAIK wirklich nur über eine Subscription.

Steht denn die Anweisung, die die Exception auslöst, überhaupt innerhalb des try-Blocks?

Wenn du nicht VS.NET benutzt, bringt das, je nachdem, wie alt deine Version ist, nicht viel. Soweit ich weiß, hat sich an der Hilfe für VS 6 seit der MSDN Library Oktober 2001 nichts mehr getan.

Das Handle deines Hauptfensters kannst du in dem anderen Thread auch über AfxGetApp()->m_pMainWnd->GetSafeHwnd() kommen.

@Hille259: Es gibt genügend einschlägige Boards, auf denen du Hilfe zu Filesharing-Programmen finden kannst. Hier bitte nicht. @Doham: Danke @Thema: --> geschlossen.

Zeigst du die Instanz von CCErweiterungSnapShotDlg, die du erstellst, mit DoModal an? Oder ist das der Hauptdialog deiner Anwendung? Dann gibt es schon eine Queue. Aber die macht intern DispatchMessage. DispatchMessage funktioniert aber mit Thread-Nachrichten nicht, weil sie keinem Fenster zugeordnet sind. Deshalb werden deine Nachrichten zwar versendet und kommen auch an, können aber nicht verarbeitet werden. Aus der MSDN: Messages sent by PostThreadMessage are not associated with a window. Messages that are not associated with a window cannot be dispatched by the DispatchMessage function. Therefore, if the recipient thread is in a modal loop (as used by MessageBox or DialogBox), the messages will be lost. To intercept thread messages while in a modal loop, use a thread-specific hook. Bevor du mit Hooks anfängst, solltest du besser PostMessage verwenden.

Ganz ruhig, es gibt keinen Grund für Satzzeicheninflation. PostThreadMessage verwendet man normalerweise, um Nachrichten an einen anderen Thread zu schicken. Dadurch braucht man nämlich keine Synchronisierungsmechanismen. Dein Thread schickt Nachrichten an sich selbst. Nochmal: Du kommst an diese Nachrichten nur aus dem Thread heran, an den du sie geschickt hast. Du rufst PeekMessage aber aus dem ursprünglichen Thread heraus auf. Das hat gar nichts mit den Klassen zu tun. PostThreadMessage funktioniert übrigens nicht, wenn der Empfänger-Thread in einer modalen Schleife steckt. Wenn dein Fenster also mit DoModal angezeigt wurde (wovon ich bei einer Klasse, deren Name auf Dlg endet, ausgehe), dann geht das mit PostThreadMessage sowieso nicht, Queue hin oder her.

Und genau das funktioniert nicht. Du kannst mit PeekMessage nicht die Queue eines anderen Threads abfragen. Um beim Briefkastenvergleich zu bleiben: Du kannst nur in deinen eigenen Briefkasten gucken, und dabei wirst du niemals erkennen können, welche Post jemand anders bekommen hat. Schick die Nachrichten einfach an das Fenster selbst, und es sollte funktionieren.

Ich auch nicht. Deswegen wäre es besser, wenn Leana uns über Sinn und Zweck der Aktion aufklärt. Sonst ist das alles nur Spekulatius.

Da bin ich mir nicht so sicher. Offenbar sollen die Nachrichten ja erst in OnOK abgearbeitet werden. Also müsste man sie bis dahin in einer separaten Queue zwischenspeichern.

Ich weiß Ich bin mir aber nicht sicher, ob Leana das so verstanden hat. @Leana: Was du machst, ist in etwa folgendes: -Thread A startet Thread B. -Thread B schreibt mehrere Briefe an sich selbst. -Thread A schaut in seinen Briefkasten. Das da nichts drin ist, war ja zu erwarten. Was man da machen kann, hängt davon ab, wozu du das ganze überhaupt machst. Geht es nur darum, dass die GUI noch reagiert, während du im Hintergrund etwas anderes machst?