Klotzkopp

Ich komme auf 6. Das müssen aber ziemlich schlaue Pferde gewesen sein.

Indem du Zeile 22 in Unit1.cpp auskommentierst. Im Ernst, wie sollen wir dir helfen, den Fehler zu beheben, wenn du nicht einmal die fehlerhafte Zeile zeigst? Ich kann nur soviel sagen, das TEvent keinen passenden Konstruktor für die Typen der Parameter, die du angegeben hast (int, bool, bool und void * (__stdcall *)(const char *,const char *)), anbietet.

Ein quadratischer Deckel kann in den passenden Schacht hineinfallen, ein runder nicht.

Richtig. Der zweite Parameter des ON_NOTIFY-Makros gibt die Kind-Id des sendenden Steuerelements an. Hier setzt der Klassenassistent fälschlicherweise die ID des List Control selbst ein. Die Nachricht stammt aber vom Header Control, das wiederum ein Kind des List Control ist. Da das Header Control immer die Kind-ID Null hat, funktioniert die Änderung. Dieser "Workaround" hat aber den Nachteil, das bei mehreren List Controls alle Headernachrichten in derselben Funktion aufschlagen, weil ja alle Header Controls dieselbe ID haben. Um das wieder aufzulösen, kann man das Handle des Elternfensters des Header Controls ermitteln und mit den Handles der List Controls vergleichen: void CMeinDlg::OnHdnItemclickList1(NMHDR *pNMHDR, LRESULT *pResult) { LPNMHEADER phdr = reinterpret_cast<LPNMHEADER>(pNMHDR); HWND hListCtrl = ::GetParent( phdr->hdr.hwndFrom ); if( hListCtrl == m_list1.GetSafeHwnd() ) { // List Control 1 } else if( hListCtrl == m_list2.GetSafeHwnd() ) { // List Control 2 } // ... *pResult = 0; }[/CODE]

Was mir bisher aufgefallen ist: - Integrierte Unterstützung des Compact Framework - Visual J# - verbesserter (native) C++-Compiler - erweiterte Automatisierungsschnittstelle Details gibt's hier: http://msdn.microsoft.com/library/en-us/vsintro7/html/vxoriWhatsNewInVisualStudioNET2003.asp

Der Klassenassistent von VC6 generiert bei Headerbenachrichtigungen eines List Control falsche MessageMap-Einträge. Wahrscheinlich steht in der cpp-Datei deines Dialogs in etwa das: ... ON_NOTIFY(HDN_BEGINDRAG, IDC_LIST1, OnHdnBegindragList1) ON_NOTIFY(HDN_ENDDRAG, IDC_LIST1, OnHdnEnddragList1) ... Wenn du IDC_LIST1 (oder was auch immer die Resource-ID deines List Controls ist) durch 0 ersetzt, sollte es funktionieren. VC7 hat diesen Bug übrigens nicht mehr

Nein, denn 10 hoch (log x) ist x, nicht (log x) hoch 10. Und 10 hoch 1 ist 10.

Woher nimmst du die 10? Du brauchst nur auf beiden Seiten "10 hoch" zu rechnen: (x+1) / (x-1) = 10 Der Rest ist trivial.

Mit hoher Wahrscheinlichkeit nicht, zumindest nicht von MS. Zwar werden einige Teile der MSDN Library übersetzt, aber bei weitem nicht alle. Zudem sind die Übersetzungen AFAIK nur über eine Subscription erhältlich, nicht online.

Äh, ln( 6^2x ) ist 2x * ln 6 nicht 6 * ln( 2x ). @timmi: Warum sollte man irgendeine Basis bevorzugen? Oder meinst du log (Basis 10), weil man das leichter abschätzen kann?

Nein, um von ln x auf x zu kommen, musst du den Ausdruck als Exponenten von e einsetzen: e hoch - ganzLangeZahl = x

http://msdn.microsoft.com/library/en-us/modcore/html/deovrObjectModelGuide.asp

@Felicie: Du kannst nicht einfach hoch durch log ersetzen. Vielleicht hilft das weiter: log( a hoch b ) = b * log a log( a * b ) = log a + log b

== bindet stärker als &&, also wird MF_UNCHECKED == MF_UNCHECKED ausgewertet. Außerdem macht der logische und-Operator keinen Sinn, der bitweise Operator wäre der richtige. Drittens ist MF_UNCHECKED gleich Null, d.h. auch mit Klammern und & statt && ist dieser Ausdruck immer wahr. Das logische oder macht gar keinen Sinn. Dieser Ausdruck ist wahr, wenn GetMenuState einen von Null verschiedenen Wert zurückgibt. Aber im Thread, auf den Guybrush Threepwood verlinkt hat, habe ich das alles eigentlich schonmal erklärt.

Eigentlich sollten Radiobuttons die gleichen State-Werte benutzen. Hast du versucht, die relevanten Daten aus dem Rückgabewert rauszufiltern, anstatt einfach zu vergleichen?

Unterscheiden sich die Styles überhaupt? Unterscheiden sich die Rückgabewerte von GetParent?

LONG GetWindowLong( HWND hWnd, int nIndex ); Für nIndex setzt du GWL_STYLE ein.

Du könntest die Fenster-Styles vergleichen. Vermutlich hat nur ein Fenster den WS_CHILD-Style nicht, das wäre dann das Hauptfenster. Alternativ könntest du Excel auch über die Automatisierungsschnittstelle starten.

Wenn du Hilfe möchtest, solltest du schon eine konkrete Frage stellen. Womit hast du denn Probleme? - Öffnen der Dateien - Lesen - Verarbeiten - Schreiben? Eine Komplettlösung wirst du hier nicht bekommen.

Hab ich doch geschrieben: Setze lpDesktop auf einen dieser Strings, z.B.: StartInfo.lpDesktop = "SAWinSta"; Einfach mal durchprobieren

Kann sein, dass du gar nichts dran ändern kannst. Die Einstellungen mit STARTF_USEPOSITION wirken sich nur dann aus, wenn die betreffende Anwendung ihr erstes Overlapped-Fenster mit CW_USEDEFAULT als Koordinatenwerten erstellt. Tut sie das nicht, bewirken dwX und dwY nichts. Wie sieht denn das Applikationsfenster nach dem Start aus? Maximiert? Hast du EnumDesktops mal ausprobiert? Wenn alles nichts hilft, könntest du dir nach dem Start das Fensterhandle holen und das Fenster verschieben.

Ich glaube nicht, dass das allein über die Koordinaten funktioniert. STARTUPINFO hat ein Member lpDesktop, da musst du den Namen des Desktops angeben. An die Desktopnamen kommst du mit EnumDesktops.

Über den vorletzten Parameter von CreateProcess, das ist ein Zeiger auf eine STARTUPINFO-Struktur: http://msdn.microsoft.com/library/en-us/dllproc/base/startupinfo_str.asp

Die meisten Probleme bei Release-Builds resultieren aus uninitialisiertem Speicher (z.B. für Strukturen) oder, wie Guybrush Threepwood schon schrieb, aus Array-Überläufen, die bei Debug-Builds durch die verwendeten Begrenzungsmarkierungen nicht sofort spürbar sind (aber eigentlich beim Debuggen eine Meldung erzeugen sollten). Welche Funktion liefert denn den Fehler?

Was gibt ProcAdd zurück?