FighterFigger

Hallo ihr Weil mir immer die besten Antworten einfallen, nachdem ich hier schrieb, und morgen das gelöst haben will schreibe ich hier. Sollte ich nicht darauf kommen, gibt es ja noch die wahrscheinlichere Möglichkeit, daß ihr mir helft *freu* ... Problem: Wie kann ich von meiner App in MFC das aktuelle Document in einer SDI ansprechen? GetDocument gibt es nur in View GetNextDocTemplate in Verbindung zu GetFirstDocTemplatePosition brachte mir nichts. Bin ich auf dem richtigen Wege, oder geht das ganz anders? ... Bin ich der Einzige, der in MFC von der App zum Doc greifen will? So geht's nicht ... POSITION pos = GetFirstDocTemplatePosition(); ((MyDoc*)GetNextDocTemplate(pos))->UpdateAlles(); Was ich suche soll NimmActivesDocument ersetzen ... Bsp: class MyApp : public CWinApp // oder so ähnlich ... void MyApp::OnKomischerKnopf() { NimmActivesDocument()->UpdateAlles(); } ... class MyDoc : public CDocument ... void MyDoc::UpdateAlles() { // mach was ... }

Jo ... also: (danke erstmal ... ) Ich habe meinen Fahler gefunden, was ihr nicht konntet, weil ihr meinen Code nicht hattet. Ich gebe ihm bei CreateBitmap explizit nochmal die BitFarbTiefe (pro Pixel) mit, und anstatt daß der dann damit arbeitet, erstellt er das Bild trotzdem nur, wenn diese Zahl mit der aktuellen Device-Farbtiefe UND dem Datentyp des Bild-Daten-Arrays überein stimmt. Da frage ich mich natürlich, wozu ich ihm das überhaupt übergeben muß, aber das klappt nun. Bei CreateCompatibleBitmap {BOOL CreateCompatibleBitmap( CDC* pDC, int nWidth, int nHeight);} habe ich wohl verpaßt, wo ich da den Verweis auf die Bitmapdaten lege, deshalb habe ich da nicht weiter gesucht, werde dies aber sofort wiederholen. Noch etwas: Kennt sich jemand mit CDC::SetColorAdjustment {BOOL SetColorAdjustment( const COLORADJUSTMENT* lpColorAdjust);} aus? ... Ich weiß, daß das nur mit WinNT richtig geht, aber das das nur mit 16-Bit-Farben läuft, steht nirgens. Bei mir verhält es sich aber so ... sowohl die Microsoft-Demo (Halftone.exe) als auch mein Programm. Kann es sein, daß bei 32Bit kein Halftone zieht? ... wäre ja schrecklich ... schöne Grüße ... Volker

hmmmmmpf ... Hallo liebe Gemeinde. Ich programmiere seit einiger Zeit in C++ mit MFC-Unterstützung, und habe ein Problem. Beschreibung der Anwendung: Ein Feld (Matrix) an Werten (zB: Helligkeit oder Temperatur) soll in einer SDI auf dem schönen, weißen Hintergrund gebracht werden. Jeder Wert hat seine Farbe (Graustufen). Es entsteht eine graue 'Mondlandschaft'. Problem: Ich will die Punkte nicht einzeln setzen (beim Stretchen sogar als Rechtecke) sondern die CBitmap-Klasse verwenden. Das Problem ist, daß ich weder eine Ressource noch eine Datei habe, sondern ein Datenfeld. Dieses kann ich mit CreateBitmapIndirect in ein Bitmap wandeln - oder? Mein Ergebnis: Er zeigt nichts an. Alles weiß. Wenn ich eine Ressource angebe, zeigt er was. Also: Meine Zuweisungen an den DeviceContext ist richtig ... es muß bei der Erstellung des Bitmaps liegen. Frage: Habt ihr sachdienliche Hinweise? Ich habe schon x Seiten durchlesen - kennt ihr eine (x+1)te Seite? Hilfe .... :eek:

öhm ... hat hier schon einmal jemand an das neue DOOM gedacht? ... so als alter DOOMer denke ich schon, das ist einen Blick wert.

Sie sind nicht druckreif formuliert, ich könnte bei Interesse aber gerne Die entwickelten Texte zuschicken ... ... aber >>Off Topic<<: "Ego Shooter Server Admin" ... hmmmm Das erinnert mich daran, daß ich "Team Shooter Platoon CoLeader" bin :bimei ... wie sieht es denn bei euch aus? ... gibt es öffentliche Angebote?

Die Gruppe hatte nun eine annehmbare Lösung geliefert, die dann wohl zur Note 1 führte. Eine Woche nach dem Referat hat dann auch Herr Prof. Gräf sich geäußert, und mit scheint, daß unsere Ansicht richtig war. ... soviel nur, um euch den Versprochenen Abschluß zu liefern. Danke an alle, die sich hier dem Thema annahmen und an alle, die die Fachinformatiker.de-Community bilden

worst Case ist mir klar, danke trotzdem für deine Antwort, denn sie Bestätigt es nochmals: Aber der Automat muß nunmal diese Ausmaße erreichen können, im absolut schlimmstemn Fall. Und das ist nichtmal mit Augezukneifen und Abstraktion erreichbar - befürchte ich. Ich werde weiter forschen, und sollte ich auf Ergebnisse stoßen, sie für das nächste Opfer dieser Aufgabe hier posten Bis in Kürze @ Community

[2] verweist auf: A. Gräf. Left-to-right tree pattern matching. In: Proceedings Rewriting Techniques and Applications (RTA \'91, Como). Springer, Berlin, 1991, pp. 323-334. Gräf selber hat diese 2 Formeln in seiner Diplomarbeit verwendet, antwortet aber leider nicht auf unsere ANfrage. \pi ist jeweils ein "Item" in einem Patternset, in diesem Fall vom Ausgangpunkt, also die einzelnen gegebenen Muster. |\pi| ist jeweils ihre Länge. Das Problem ist, daß der Automat zwar wirklich nicht höher sein kann, als die Summation dieser, aber er kann auch nicht mal annähernd dies erreichen. Da frage ich mich, ob das dann wirklich der Worstcase ist, wenn mit zunehmenden Komplexität die Differenz zwischen berechnetem und tatsächlichem worst Case immer größer wird. Schließlich ist das bei der Breite noch schlimmer, wo diese Differenz mehr als im Quadrat zu wachsen scheint. Es ist leider so, daß der Schlimmste Fall, den ich mir vorstellen kann später nichtmal zu 5% den Wert der Rechnung erreicht. Ich hoffte und hoffe, daß irgendjemand diese Formel schon einmal sah oder die Rechnung eines Baum-Automaten dieser Art bereits vornahm. Ich verlange aber nicht von euch, daß ihr jetzt extra neu alles herleitet Mir scheinen Gräfs Formeln viel zu hoch gegriffen, und das ist gerade für eine worstCaseBetrachtung nicht gesund ... oder? Danke aber für dieses Interesse, da mein Referat unbedingt fertig werden muß und niemand sonst sich diesem Problem auch nur mit einer Zeile widmete :e@sy :OD

Hallo (Ich hoffe ... es ist hier das richtige Forum dafür) zu aller erst - der entsprechende Ausschnitt kann hier eingesehen werden. Wir haben im Magazin ACM (Januar 1998)gelesen. Dabei haben wir in einem Artikel von Nadia Nedjah folgende Formeln für die maximale Größe eines deterministischen left-to-right matching Automaten gefunden: height(Atree) <= sum(|pi|); mit i element [1,n] breadth(Atree) <= prod(|pi| + 1); mit i element [1,n] Wobei p die einzelnen gegebenen Muster sind, mit denen zu matchen ist und |p| die Anzahl ihrer Symbole. Unsere Frage: Wie ist Gräf auf diese beiden Formeln gekommen? Sind die überhaupt richtig? Wenn ja, kann mir irgendjemand diese Formeln anschaulich und leicht verständlich erklären, so daß ich verstehe wie diese zustande gekommen sind? Besten Dank im Voraus Volker Subat :marine