Crush1

Muß ich mir da nen Button IDC_SPEICHERN machen und dann den kram in OnSPEICHERN legen? -> Wäre so denkbar... Alles was den Dialog betrifft würde ich auch da reinsetzen, es sei denn du willst eine universale Speicherfunktion machen, die müstest Du dann mit #include einbinden also eine eigene .CPP und .h dafür anlegen.

Sorry das war nicht gegen die Leute gerichtet, sondern gegen die Dozenten die wohl nach dem was man so hört großtenteils bescheiden sind. Ich habe nicht vergessen, daß hier alle lernen (wollen). CU!

Hast ja Recht Gugglhupf. Wobei die verteilten Anwendungen meist eh aus einer Hand kommen und da weiß man dann auch, daß man sich strikt an Vorgaben halten muß und nicht so eine unklare Beschreibung wie hier: int main () { summe (2, 4, 5 ); // gibt 9 zurück summe (3, 5, 6, 7); // gibt 18 zurück } na da bin ich mal auf eure lösungen gespannt. ps: ihr dürft sowohl c als auch c++ mittel verwenden. Die Parameter sind gar nicht ausdokumentiert, erst recht nicht deren Typen und die Art des Rückgabewertes (wobei ich immer davon ausgehe wie der Eingabewert). C++ war definitiv ERLAUBT weshalb ich ja gar nicht so falsch liegen kann. Ich habe Deine Lösung ja auch nicht angefochten sondern wollte noch einen anderen Weg aufzeigen. Ich denke das ist auch der Sinn eines solchen Forums, daß man mal aus der eigenen Schublade in die anderen Räume gucken darf. Von Optimierungen usw. war ja eh keine Rede, also waren das auch nicht Teil der Anforderungen. Ich stimme Dir zu, daß Deine Lösung prima ist. Aber was können wir von Grady Booch lernen? Das Design eines Programms entscheided über dessen Aufbau. Da hier Herkunft, Art und Verwendung der Daten unklar ist ist auch jede Lösung eigentlich unklar und somit jeder Schritt erlaubt. Der Rest ist ansichtssache. UML und andere Designmethoden wären ja auch gänzlich überflüssig, wenn wir nicht alle auf die C++ Paradigmas und deren Möglichkeiten setzen würden. Dann könnten wir ja gleich wieder zur prozeduralen Programmierung zurückgehen, Zeilennummern vergeben und mit Goto´s durch die Gegend hüpfen. Wenn Templates so unnötig und zeitraubend sind, warum widmet Soustroup ihm den größten Batzen an Zuwendung in seinen Büchern und hämmert uns allen das ganze Thema gewalttätig ins Hirn? Weil wir´s benutzen SOLLEN! Wer damit nicht lernt umzugehen wird bald wie die Pascal-Leute am Daumen nuckeln können. Die Industrie drängt nach Programmierung in OO und wer nicht mitmacht ist bald am AA! Denen ist es eh egal wie toll wir noch ein paar Taktzyklen aus der CPU rupfen oder ein paar Bytes einsparen könnten. (Alles klar? Einwände? Zusprüche? bin da und habe offene Ohren)

Jungs, wenn wir alle nur noch Speicher sparen und optimieren bis zum Abwinken, dann gibt´s doch von der Industrie keinen Grund mehr noch schnellere Kisten mit größerem Hirn auszuspucken!!! Ihr habt wohl vergessen, daß wir Programmierer mit den Hardwareentwicklern im Wettrennen sind. Oder wolltet ihr heute noch auf Eurem alten C64 rumhacken um die letzten Raster-Effects aus dem Brotkasten zu kitzeln (jaja, das war´n noch Zeiten ...) und mit Vizawrite Textchen tippen?!?! Vielleicht ist Euch allen nicht klar, daß C++ kein Schritt nach hinten sondern nach vorne ist um uns das Leben einfacher zu machen und SOFTWAREENTWICKLUNG ZU BESCHLEUNIGEN!!! Denn Eure Optimierungen wird kein Schwein extra zahlen wollen, sehr wohl aber Euer feriges Produkt!

Also das Positionieren der Fenster muß tatsächlich komplett von Hand erfolgen. Ich wüßte da auch keine andere Lösung als ein Window-Array, welches relative positionen und größen mit minimalen und maximalen Größen beinhaltet. Nämlich einfach verkleinern bis zu 1 Pixel größe ist blödsinnig und Textinhalte werden abgeschnitten. Deshalb minimale Größendefinition. Ein Button in der Größe des halben Screens ist genauso hirnrissig. Also bei einem Programm bei uns in der Firma habe ich einen Resize auf diese Art und weise gecoded. Mir fällt auch noch was wichtiges dabei ein, was ein Problem war: Einige Fensterchen sind einfach beim Resizen verschwunden. Grund war, daß bestimmte Variablen mit denen ich in der Dialog-Klasse gearbeitet habe static sein mußten, weil sie offensichtlich irgendwann irgendwie von irgendwas überschrieben wurden. (ich weiß, ist ein blöder Fehler - aber vor lauter Wald sieht man manchmal die Bäume nicht ... oder so ähnlich)

Maddin: Die Zahlen sind im CArray!!! Die müssen da vorher schon drin sein!!! Ich weiß nicht, was ihr wollt. Gugglhupf: Speicher hammer alle genug und wenns nicht reicht ist die Platte dran. Ein Test der Laufzeit um die Zahlen abzufragen lag im nanosekundenbereich, also mir ist das schnell genug. Cool-Matthias: Lies nochmal den 1. Satz von meinem Briefschen! Da habe ich nur nochmal Gugglhupfs Lösung bestätigt. Außerdem ist Wert a überflüssig (wird ja auch gar nicht verwendet) wenn nicht sogar blödsinnig solang man nicht mit Arrays arbeitet.

Also ich arbeite mit Templates wo ich nur kann - nur finde ich das Debuggen eines Templates das ich selber erstelle etwas schwierig. Eine Andere Methode (leichter zu debuggen) wäre das Einsetzen von Makros welche eigentlich nur ein Vorgänger der Templates sind aber von Compiler zu Compiler unterschiedlich gehandhabt werden. Ist ja alles Wurst ... Aber ich möchte nur sagen, daß das Programmieren von verketteten (einfach oder mehrfach ist scheißegal) Listen eigentlich zum Standard-Repertoire eines Programmierers gehören sollte - denn soooo schwierig ist das nun auch wieder nicht. Da gibt´s Schlimmeres.

Ich habe auch mal einen Videoplayer mit Controls gemacht. Da war dasselbe Problem mit dem Resizen. Wenn das Control ein Resizing nicht als Funktionsaufruf unterstützt siehts düster aus. Damals habe ich mir gedacht wäre doch toll das Control in einem hidden-Fenster laufen zu lassen und dann mit BitBlt ins sichtbare Fenster zu resizen - außerdem wäre dadurch auch das zuschalten von Filtering der Grafik-Karte usw. möglich wenn man über DirectX oder OpenGL geht. Dann müßte man das Fenster jedoch als Textur benutzen und dazu sollte die Grafik-Karte richig schnell sein.

Offsets sind nichts weiter als Werte die relativ zu einem Startpunkt eine neue Adresse liefern. Bei einem Array kann bedeutet der Offset 2 der dritte Eintrag! Array[0] = 1. Eintrag Array[1] = 2. Array[2] = 3. Das mit DOS16 ist sehr wohl noch ein Thema nur merkt keiner was davon weil die Compiler alles automatisch versuchen soviel wie möglich im gleichen Speicher-Segment zu Compilieren. Dadurch verringert sich die Adressierungs-Bandbreite und damit erhöht sich die gesagmt-Geschwindigkeit aller Speicherzugriffe im selben Segment weil die neuen Segmente erst adressiert werden müssen, was Zeit benötigt. Das hat nichts mit Nostalgie zu tun sondern mit der technischen optimierung bei der Code-Generierung. Übrigens wäre ohne diese Optimierungen wohl so etwas wie die Playstation-, N64-Emulatoren und auch die JIT-UAE-Amiga-Emus nicht dermaßen mit solcher Geschwindigkeit auf unseren Kisten möglich. Außerdem wenn jemand mal direkte Hardware-Programmierung machen muß (Steuerungen, etc.) kommt er um das Thema wohl kaum drum herum. Solange unsere Computer Page-orientiert arbeiten ist das sehr wohl ein Thema. Das Thema Bandbreite ist ja nicht nur beim Computer selbst sondern gerade auch bei Grafikkarten in aller Munde, nicht wahr?!!?

Gehe im Resource-Editor auf den Dialog und wähle das betreffende Fenster aus. Drück Strg-W und rufe so den Class-Wizard auf. Wähle dort die Karte "Member-Variables" und klicke auf die entsprechende Control-ID des Fensters. Drücke "Add Variable" und füge bei m_ irgenwas dahinter wie z.B. m_Fenster (das m_ steht für Member-Variable). Wähle in der Kategorie "Control" aus und Bestätige alles mit "OK". Hiermit ist m_Fenster in Deinem kompletten Source-Code über DDX-Funktionen bekannt (Direct-Data-Exchange) und kann über den Punkt-Operator alle Funktionen die dem Fenster bereitstehen benutzen. So arbeiten die (faulen) Profis! Viel Spaß!!!

Heute sind statische Arrays kaum noch ein Thema. Arbeite mit CArrays und alle Funktionen die Du Dir wünscht liegen schon griffbereit - und es funktioniert alles. Sowas wie ein Überschreiben des Arrays kann auch nicht mehr passieren, damit werden Anwendungen absturzsicherer und außerdem "fressen" fast alle Betriebssyteme in den Bildschirmmasken CStrings.

Gerade bei Datenbanken ist OCI (Oracle-Call-Interface: ziemlich schwierig - daran arbeite ich gerade) und CORBA (Programmsteuerung über Netzwerke) ein Thema - das wird oft gefragt sich hier auszukennen ist bares Geld auf die Kralle. Bei DirectX-Programmierung kommt bei der Enumeration auch eine verkrüppelte aber einfacher zu verstehende COM-Schnitstelle zum Einsatz - als Einstieg auch geeignet und außerdem wird wohl oder ist DirectX die Grafik-Schnittstelle Nr.1 für Windows-Betriebssysteme (noch vor OpenGL). Gehe am besten in eine gut ausgestattete Bücherei in einer Großstadt und wühle alles durch, da doch die Anforderungen der Bücher teils auf recht unterschiedlichem Niveau liegen. Mit direktem Büchertip will ich nicht dienen, da mir die Bücher umso interessanter erscheinen je weniger ich auf den ersten Blick verstehe. Ich arbeite beim Lernen immer top-to-bottom. Erst das Schwierige bis es sitzt, dann kann man sich das Einfachere unten genauer betrachten - so lag ich bisher immer am besten. Man darf nur nicht aufgeben wenn man mal etwas nicht rafft. Spätestens beim 10. mal Durchlesen rappelts im Karton und man denkt sich: Warum hab ich das denn vorher nicht geblickt, war ich blind?!? Eine gute Hilfe ist auch das erlernen von Schnellese-Methoden (Photo-& Speed-Reading). Das ist aber leider nicht jedermanns Sache. So konnte ich jedenfalls die Lern-Zeiten drastisch um den Faktor 20-100 verkürzen. Z.B. das Soustroup C++-Buch (Studentenversion) hab ich in knapp 2 Tagen durch gehabt. Das Wichtigste ist es zu erkennen was man überspringen kann und sich nicht an belanglosen oder bekannten Dingen aufzuhalten. Hoffentlich bringen Dir meine Tips was ...

Sorry EisenUli, aber der Cast liefert keinen String zurück der als Zahl 123 erkannt werden könnte. Das mit ITOA ist die bessere Lösung. Am allerbesten ist es eine eigene Number-Klasse aufzubauen, die selbständig in hex oder Ascii oder CString, etc. umrechnet und nacher nur damit zu arbeiten (wenn auch alles richtig klappt). Letzte Möglichkeit, die ich noch nicht gesehen habe wäre die Zahl als Bits oder Nibbles zu berechnen. Das geht so: Zahl 123=%01111011 Man macht eine Tabelle, die den Bit-Wert von 0-32 enthält Bsp: Ascii&Bits (von rechts gelesen) 1*1 = %1 +1*2 = %10 +0*4 = %100 +1*8 = %1000 +1*16 = %10000 +1*32 = %100000 +1*64 = %100000 usw. Die bits werden einzeln ausge-ANDed (in Assembler gab´s noch den Rol ins Carry-Bit - geht heute auch noch mit dem integrierten MASM) und der Ascii-Wert in einm Char-Array aufaddiert. Überträge müssen berücksichtigt werden!! 01111011 wäre dann: 1 +2 +8 +16 +32 +64 =123 Das geht gut programmiert übrigens recht schnell und einfach! Nur ein wenig Platz für die Ascii-Werte muß reserviert werden - je nachdem mit wieviel Bits man maximal arbeitet 64 Bits = 64 Ascii-Werte!!! Das ganze geht natürlich auch mit Nibbles: 123=%0111 1011 = 0111*16 und 1011*1 hex 0xF = Zahlen 0-15 in einem Array FxF = Zahlen 16-255 genauso Hier werden die Bits also in 4er-Packs rausgeANDed. Das Aufaddieren funktioniert ansonsten gleich, alles geht noch schneller nur der Umfang der Ascii-Tabelle steigt um das 16-Fache. ist Aber dafür auch 4x schneller! Die Ascii-Tabellen kann man sich ja generieren lassen, da spart man sich dann viel Arbeit. Ich bin ehemaliger Assembler-Programmierer und da hat man das immer so gelöst! Ist zwar heute (fast) kein Thema mehr, aber wer wirklich alles übers Programmieren wissen will, sollte auch mal über den Tellerrand schauen. P.S.: Zum Programmieren von MMX1&2, ISSE & Geforce3 benötigt man übrigens wieder Assembler - also ganz ohne geht auch wieder nicht.

Schön zu sehen, daß es außer mir noch ein paar andere Anwendungsentwickler gibt, die einmal wirklich selber eine Anwendung entwickeln können. JUNGS->Wir müssen den Namen der Fachinformatiker in Ehre halten - sonst werden wir noch mit den anderen Luschen, die nur zum Popeln in den Unterricht gekommen sind, verglichen. Nicht vergessen, der Ruf aller Fachinformatiker fällt nachher auch auf uns zurück!

Ihr Pfeifen, wer waren denn Eure Dozenten?!?! Man muß die Funktion überladen (2faches Definieren der Funktion zum Einen mit 2 und einmal mit 3 Parametern). Der 1. Parameter ist überflüssig, da er die Anzahl weiterer Parameter angeben soll - beim überladen ist die Anzahl der Parameter und der Typ eh klar. Eine Echte Lösung wäre es ein CArray anzulegen mit ints oder floats. Da kann man problemlos drüberiterieren und alles zusammenrechnen. .Insert & .RemoveAll sind auch schon vordefiniert. Aber bis zu den Templates sind wohl nur die Wenigsten gekommen. Erst mal der Inlcude: #include <afxtempl.h> das läuft dann so: CArray<int,int> x; Nun kann man alles über den Punkt-Operator benutzen. x.Add(5); x.Add(6); usw die Funktion heißt dann: int Summe(CArray x) { int summe=0; for (int i=0;i<x.GetSize();i++) { summe+=x.GetAt(i); } return summe; } Zum löschen des Arrays nur x.RemoveAll(); aufrufen! Ist doch einfacher und man braucht keine 1000 Funktionen definieren. Das nennt sich dann übrigens wirklich C++!!!

Solange der Name des Fensters ID_STATIC ist kann man gar nichts ändern. Nenne es z. B. in ID_Ausgabe um ... schon klappt´s!