FighterFigger

Ich persönlich kenne weder "Borland C++ for Dos 3.5" noch erkenne ich die Fehlermeldung, aber wenn es schon an der main-Funktion liegen könnte: hast du's schonmal mit void main() oder int main(int argc, char* pArgs[]) versucht? kA. ob das eine Hilfe ist ...

Er startet das ja als Konsolenanwendung, und bei jeder Konsolenanwendung unter Windows 98 kann man einstellen, ob das Fenster nach Beendigung geschlossen werden soll, oder nicht. geht das bei XP denn nicht auch irgendwie?

Den Bloodshed habe auch ich damals sehr gerne genutzt, da er auch gleich die Header und einen Compiler mitbringt. Ansonsten sollte deine Schule mal gucken, ob sich die Microsoft Academic Alliance lohnt. Unter Umständen ist die nur für Hochschulen, aber dann wird einmal gezahlt, und die Schüler bekommen Wuschel-Studio gratis für 2 Jahre. Aber eben nur für Windows.

Was heißt hier "Vorteile" ) Ich persönlich kenne diese Klassen-in-Klassen (weiß nichtmal mehr, wie die heißen) ... kenne sie nur aus ganz seltenen Fällen bei untypischen Design-Entwürfen. Im Prinzip benutzt du eine Klasse, um andere Klassen wie in einem Paket zu kapseln. Aber genau für diese Aufgaben sind Namespaces da. Einen Vorteil kenne ich nicht, außer, daß es vielleicht in EngineeringTools anders aussieht ... Aber ich wollte dich ja auch nicht berichtigen, sondern vor allem eben wissen, warum du dafür diese Klasse nutzt, eben WEIL ich das nur selten so sehe und eben WEIL das eigentlich nicht wirklich einen Unterschied macht. )

Beim Beispiel vom Tapeman also: namespace MyClasses { class V { ... }; class O { ... }; class O1:public O { ... }; class O2:public O { ... }; class O3:public O { ... }; class V1:public V { public: O1* o1; }; class V2:public V { public: O2* o2; }; class V3:public V { public: O3* o3; }; }; class Z { public: MyClasses::V1 v1; MyClasses::V2 v2; MyClasses::V3 v3; }; Z z;

Auch wenn das nicht wirklich die Antwort auf die Frage ist verstehe ich nicht, warum ihr die Klassen in die andere Klasse einbettet. Welche Vorteile hat das gegenüber einem gediegen gewählten Namespace? Und Tapeman - müßte es nicht eher Z1::V1 v1; statt Z1:V1 v1; sein? ... Ich kenne mich mit diesen eingebetteten Klassen nicht aus, aber ein Scope-Operator erscheint mir sinnvoll. klärt mich auf =)

Also - es geht mir nicht darum, den Aktualisierungsaufruf auszulagern. Du hast eine langwierige Funktion, die den Thread des Dialogs blockiert. Diese Funktion will den Dialog während der Arbeit verändern, die Aktualisierung wird aber erst nach der Funktion durchgeführt, wenn der Thread des Dialogs wieder Zeit für seinen Dialog hat, weil er nichtmehr deine Funktion beackert Also: Du packst deine komplette langwierige Funktion in einen eigenen Thread, während dessen Ausführung sich der Dialog beinahe langweilt. Ab und zu bekommt er dann von diesem zweiten Thread eine Meldung, daß er sich aktualisieren soll, und das tut er prompt - hat ja sonst nix mehr zu machen. --- Damit man bequem einen Thread machen kann schreibt man sich entweder eine globale Funktion *bibber* oder macht seine Methode static. Denn für den neuen Thread soll die Funktion nicht von einem speziellen Objekt abhängen. Benötigte Daten (wie deinen Dialog) kann man dann als Pointer übergeben - man könnte auch einen Funktionspointer zu einer Callback-Funktion übergeben - das wäre nicht dumm ... Wichtig ist - die Funktion benötigt folgende Signatur: UINT MyControllingFunction(LPVOID pParam); ... entweder global oder als static member ... dann sollte es gehen.

Du könntest (mal wieder ) deine Behandlungsfunktion in einen eigenen Thread auslagern. So blockierst du nicht den Thread des Dialogs, der sich dann sofort um die Aktualisierung kümmern kann. Allerdings weiß ich echt nicht 100%ig, ob das das Problem ist, schließlich sollte RedrawWindow doch die Mal-Funktionen aufrufen, und nicht nur eine Message schicken - oder? Wird denn der Dialog am Ende deiner Funktion - also wenn die Anwendung Idle ist (oder zumindest der Thread des Dialogs) ... wird dann der Dialog aktualisiert? Sorry - anderes fällt mir nicht ein.

Kann es sein, daß du die Texte aus einer Funktion heraus ändern möchtest, die nicht so schnell beendet wird? Ein Dialog hat ja nur einen Thread (wenn ich das richtig sehe) und wenn du von dem aus eine Fuktion einer anderen Klasse startest, dann werden Aktualisierungen u.U. erst durchgeführt, wenn du wieder zurück bist und der Dialog Zeit hat, die Messages abzubauen. Vielleicht solltest du mal sagen, welche Klasse die Statics ändern möchte, wer das Objekt dieser Klasse erstellt, wer den Dialog erstalle ... sowas halt ...

Du kannst doch immer Variablen für Control und für Value bei Window-Objekten der MFC angeben ... so auch bei den Statics ... oder willst du das nicht? Dann legst du bei der Dialogklasse eine nette public Funktion an, die es dir erlaubt den Text zu ändern, indem sie den protected-Member (CString m_static_XY_Text) verändert. Nach UpdateData(false) sollte das eigentlich gehen. So bist du nicht von der Item-ID IDC_STATIC_xy abhängig, die vielleicht bei dir von Klasse zu Klasse unterschiedlich ist. Was den weißen Rest des Konsolen-Fensters angeht: schonmal Invalidate() versucht? Einfach auf das DialogObjekt anwenden.

So mache ich das in MS-VC++ ... ... wobei ich zugegebenermaßen nie einen Unterschied zwischen "access(...)" und "_access(...)" gefunden habe. #include <io.h> ... if (access(filename, 0) != -1) { ... } Geht das nicht, ist das zu sehr Microsoft oder gar nur C++ ? Achso ... und das ist die Liste der File-Handling-Funktionen aus der msdn. :beagolisc

do { } while (!buttonPressed_); buttonPressed_ = false; und der Button setzt deine Member-Variable bool buttonPressed_ auf true ... Geht das nicht?

Also mit TerminateThread kriegst du den definitiv weg. Das wäre mal ein Versuch wert, allerdings: Erstellt er bei jedem Schleifendurchlauf einen neuen Thread, ohne den wieder zu entfernen? Das glaube ich nicht wirklich, denn XSleep kann ja dann abschließen, wenn er genug gewartet hat. Außerdem weiß ich nicht, warum ein Thread bestehen bleiben sollte, wenn der Vater-Prozeß terminiert. Aber hast du dir schonmal das hier in Bezug auf diesen Artikel durchgelesen? Vielleicht übernimmst du seinen Vorschlag.

Aber gerade das ist, was ich Designtechnisch anders machen würde. (ohne zu wissen, ob das dort möglich ist und ohne dir bei XSleep zu helfen) Du könntest eben diese Polling-SchleifenFunktion als Thread aufmachen indem du sie static deklarierst und du darauf CreateThread anwendest. Dann kann die schlafen oder wachen, wann immer sie will. Nun braucht sie nur noch eine Möglichkeit, aktiv die GUI zu verändern. Entweder mit einem Pointer auf den Dialog, oder auf eine Callback Funktion oder ähnliches ... Du könntest theoretisch doch auch die Ergebnisse in einen gemeinsamen Speicher schreiben und per Message der GUI sagen, daß da neue Daten sind. Ich meine nur, daß du das tatsächlich in 2 Threads teilst und damit dann keine Probleme mehr hast. :beagolisc

Dann solltest du vielleicht das, was schlafen soll in einen eigenen Thread packen. Auf den hast du dann volle Kontrolle durch den Handler und den Thread legst du immer brav, früh ins Bett mit Sleep. Da Sleep deinen anderen Thread schlafen läßt, aber nicht deinen Haupt-GUI-Thread, kann der fein weiterarbeiten. Wird die GUI geschlossen muß sie vorher noch ihren Sohn killen, der eben noch schläft. Solch ein Konzept wäre doch einfacher ... oder? Der Thread, der schlafen soll ... was tut der? Berechnet der was oder ist er auch für eine GUI-Funktionalität?