Klotzkopp

Möglich. Aber mandantarray[0] ist dann immer noch uninitialisiert.

@bigpoint: Ist dir klar, dass die anderen Elemente von mandantarray uninitialisiert sind, also beliebige Werte beinhalten können? int mandantarray[10] = {0, 0, 2, 0, 4, 0, 6, 0, 0, 0}; for (int ii=1; ii<10; ++ii) { if(mandantarray[ii] > 0) cout<<"Huuuuuuuura"<<endl; } [/CODE]

Der ist an diesem Wochenende? Kann ich mir ja eigentlich nicht entgehen lassen.

Ich bin eigentlich kein Fan von Volksfesten, aber meine Frau und ich sind eingeladen worden, deshalb gibt's ein verlängertes Wochenende (Fr-So) in München. Vielleicht können die Eingeborenen hier ja noch ein paar Tips abgeben, was sonst noch so Sehenswertes in der Gegend ist.

C und C++ sind zwei unterschiedliche Sprachen. @Gottesgeschenk: Niemand kann Dir einen Strick draus drehen, wenn du genau die Sprache benutzt, die im Antrag steht. In C gibt es keine Klassen. Und MFC ist C++.

Es gibt einen OLEDB-Provider für den Indexdienst. Das geht natürlich nur, wenn der Indexdienst vorhanden (>= Windows 2000), aktiviert und entsprechend eingestellt ist. Eine andere Möglichkeit kenne ich nicht.

Üblicherweise sind die Hersteller der Geräte dafür verantwortlich, ein auf ihre Hardware zugeschnittenes SDK zur Verfügung zu stellen. Um was für ein Gerät handelt es sich denn?

for (it=tv.begin(); it!=tv.end(); ++it) { cout << it - tv.begin(); } [/CODE]

Was möchtest du denn ausgegeben haben? Den Inhalt des Vectors oder die Anzahl der Elemente?

Das klingt schon ganz gut Nein, keine globale Variablen. Der Hauptdialog kann doch nach dem Schließen des Unterdialogs noch auf die Member der Unterdialog-Klasse zugreifen und die Daten auslesen. Da gibt es keine fertige Funktion, das musst du selbst machen. Du kannst natürlich die Funktion aufrufen, die du auch beim Start des Hauptdialogs für die Initialisierung benutzt.

Erstellst du die Datei bereits aus dem Unterdialog? Falls ja, solltest du dafür einen guten Grund haben - nicht nur den, dass die Daten, die in die Datei geschrieben werden sollen, da gerade verfügbar sind. Du musst ein klares Konzept für den Datenfluss aufstellen. Die Interaktion mit den Datendateien sollte nur an einer Stelle passieren, ansonsten sollten die Daten im Speicher weitergereicht werden. Keinesfalls sollte jeder Dialog sein eigenes Süppchen kochen und dann allen anderen über die Änderungen Bescheid geben. Das wird zunehmend komplizierter, je mehr datenverarbeitende Stellen du hast. Einer muss für die Synchnonisation der Daten zwischen Datei und Speicher verantwortlich sein, und die Anderen haben die Finger davon zu lassen. Konkret: Ich würde den Unterdialog keine Datei erstellen lassen. Er soll nur die Daten für den Hauptdialog vorhalten. Der kümmert sich um das Speichern der Daten und kann sich dabei auch gleich selbst aktualisieren.

Ich habe auch nichts vom Schließen des Hauptdialogs geschrieben. D.h. du legst die Daten bereits irgendwo ab? Wo und wann passiert das? Sicher gibt es die. Und die sieht so aus, wie ich sie eben schon beschrieben habe: - Unterdialog öffnen - Benutzer Daten eingeben lassen - Unterdialog schließen - Daten aus Unterdialog auslesen und sich selbst aktualisieren.

Üblicherweise holt sich die Behandlungsfunktion des "Erfassen"-Buttons die Daten vom Unterdialog, nachdem dieser geschlossen wurde, und kümmert sich selbst um die Aktualisierung.

Es liegt wahrscheinlich am internen Limit in der JET-Engine. Wenn ich mich richtig erinnere, wurde das beim Wechsel von 2.5 auf 3.0 mal eben verdoppelt. Auf die internen Vorgänge der Engine hast du über die DAO-Wrapper praktisch keinen direkten Einfluss. Brauchst du den Schreibzugriff? Wenn nicht, könntest du den dritten Parameter bei CDaoDatabase::Open auf TRUE setzen. Erzeugst du sehr oft einen neuen Recordset, auch wenn sich die Daten nicht oft ändern? Falls ja, könntest du versuchen, die Daten im Programm zu cachen. Es könnte auch helfen, hin und wieder das Database-Objekt neu zu erstellen.

Hast du die aktuelle JET-Version installiert? Sollte 4.0 sein.

Das einzige, was mir aufgefallen ist: file muss ein int sein, wenn du ihn mit %i einliest. Hast du es mal mit einer einfachen Test-Eingabedatei ausprobiert?

Wenn du die Zellen voneinander abziehst, bekommst du die Differenz in Tagen. Wenn du Stunden willst, musst du also mal 24 rechnen: =(C4-B4)*24 Formatierung natürlich als Zahl.

Es wäre hilfreich, wenn du zeigen würdest, wie die Zeilen in der Ausgabedatei aussehen, und wie sie aussehen sollen.

Vielleicht solltest du das nochmal für dich selbst überprüfen. Der Borland-Compiler, den ich hier habe (5.5), beschwert sich z.B. nicht über #include <IOSTREAM>. (Es hätte mich auch sehr gewundert )

Zumindest unter Windows ist diese Aussage falsch.

Klar ist das möglich. Den Formatstring kannst du auch formatieren: CString f; int iNachkomma = 2; f.Format("%%01.%df", iNachkomma); CString s; s.Format(f, fWert );[/CODE] Einzige Besonderheit: Wenn hinterher ein Prozentzeichen im String stehen soll, musst du im Formatstring ein doppeltes Prozentzeichen angeben.

Überleg doch mal genau, was der Code macht: Angenommen, deine Listbox hat drei Einträge, dann löscht zu zuerst den Eintrag mit dem Index 0, zwei bleiben übrig. Dann löschst du den Eintrag mit dem Index 1, bleibt einer. Dann willst du den Eintrag mit dem Index 2 löschen. Aber es ist ja nur noch einer drin, und der hat den Index 0

Die Zeichen werden "normal" ausgegeben. Das Problem ist, dass du Zeichen benutzt, die nicht Bestandteil des ASCII-Zeichensatzes sind. Die sehen, je nach Codierung, anders aus. Und der Editor deiner Entwicklungsumgebung verwendet leider eine andere Codierung als die Konsole. Die Suchfunktion spuckt für "Umlaute" übrigens diesen Thread aus: http://forum.fachinformatiker.de/showthread.php?t=12579

Nur als Info: Aus afxwin1.inl: _AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle() { ASSERT(afxCurrentResourceHandle != NULL); return afxCurrentResourceHandle; }[/CODE] Der Pfad mit Laufwerk F bezieht sich auf den Pfad, aus dem heraus die MFC bei Microsoft gebaut wurde. Diese Informationen stecken in der Debugversion der MFC noch drin. Man findet die MFC-Quellcodes in diesen Ordnern: C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include C:\Programme\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\src (VS.NET 2003, Standardinstallationspfad vorausgesetzt)

Die Steuerelement beim Internet Explorer scheinen nicht nur keine Standard-Windowssteuerlemente zu sein, sondern gar keine Fenster im Windows-Sinn (beim aktuellen Firefox übrigens auch nicht), also kannst du da mit WinAPI-Funktionen nicht rankommen. Du kannst das aber auch jederzeit mit Spy++ nachprüfen.