OnChange()-Nachrichten unterdrücken

[Crush]

Hallo, ich habe bein WinXP-VC++ ein Problem mit Member-Controls. Ich möchte diese gerne verändern, ohne daß eine OnChange()-Message verschickt wird. Natürlich könnte ich diese Nachrichten mit PretranslateMessage() oder ProcessMessageFilter() rausfiltern, aber besser wäre ein komplettes Ausschalten der Control-Nachichten über die Member-Variable direkt, damit diese also erst gar nicht erzeugt werden, und zwar bevor ich damit arbeite und danach muß die Message-Funktion wieder reaktiviert werden. Ist das überhaupt möglich?

[Babybaer]

Was hast du da eigentlich vor?

Wenn Du die Methode nur aus der Messagemap nimmst passiert da gar nix! Also keine Nachricht vom Control wird ausgewertet!

Wenn Du keinen Code in eine Methode reinschreibst, wird der Default genommen. Also so wie wenn Du da nix codiert hättest.

Unterm Strich ich weiß nicht was Du vorhast!

Schreib mir mal genau was Du da machen möchtest.

Gruß

[Crush]

Noch einmal etwas ausführlicher:

Ich habe Controls, die jeweils eine OnChange-Methode (mit Code) haben. Da diese alle miteinander "verkettet" sind und sich gegenseitig verändern (je nach Eingabe - geändert werden dabei nicht nur die Control-Inhalte, sondern die Controls, Styles, Listen, uvm.) kann mir in einem Ausnahmefall durch eine unglückliche Verkettung eine OnChange-Message-Schleife entstehen. Das bedeutet: Wird dieses bestimmte Control geändert und es beschreibt sich in seiner OnChange-Methode selbst, dann löst es in sich wieder eine OnChange-Methode aus, die irgendwann wieder darin endet, daß das Control-Feld (der Startpunkt der Message-Kette) verändert wird und der Spaß von vorne beginnt. Ein Teufelkreis!!! ...würde TV-Kaiser sagen.

Hört sich kompliziert an - ist es auch.

Das Problem wäre für mich gelöst, wenn ich ein solches Control beschreiben kann, ohne daß diese Message-Kette ausgelöst wird.

Ich habe dieses Problem bis jetzt mit allerlei "Tricks" versucht zu umgehen, allerdings bis jetzt relativ erfolglos. 95% solcher Message-Teufelskreise konnte ich mit einer zusätzlichen Information vermeiden, indem ich den Funktionen Queue-Parameter verpaßt habe, wodurch jede Funktion weiß, wer der vorherige Auslöser der Kette war und dementsprechend anders auf die anderen Controls zugreift (this-Zeiger oder Member-Variablen - die falsche Methode führt zur Endlosschleife). In einem besonderen Fall war das (wieso auch immer - ich kam jedenfalls nicht dahinter was an dieser Methode anders war als an den anderen) mit diesem Trick nicht zu lösen - jeder Schreibversuch führt immer unweigerlich zum Absturz.

Es scheint aber wohl auch bisher kaum einer so etwas komisches programmiert zu haben und deshalb tritt ein derartiges Problem nur bei mir auf. Wenn ich das nicht bald einfach lösen kann, muß ich wohl doch noch einen speziellen Message-Handler schreiben.

Aber vielleicht kennt ja zufällig einer einen "Trick" diese Nachrichten schon im Vorfeld zu unterbinden? (darauf stützt sich meine Hoffnung)

Naja, in der jetzigen Version ist das Prog schon releasefähig, allerdings kann es aufgrund dieser Sache nicht ganz so perfekt funktionieren, wie ich es gern hätte, was eigentlich schade ist.

Ich ruf Dich mal wieder an (ist ja schon eine Weile her), dann kann ich Dir das evtl. noch genauer erklären.

[Babybaer]

habe es immer noch nicht ganz verstanden aber ich glaube das Du vielleicht auch nur einen falschen Denkansatz hast. Vielleicht hift Dir ja das. Wenn du abfragst welches Control gerade den Focus hat.

Beispiel:

GetDlgItem(IDOK)->GetFocus ();

Aber ich nehme an das ich das nicht ganz verstanden habe und auch damit falsch liege. Kannst mich ja mal anrufen.

[Crush]

Es funktioniert zwar, daß der Absturz so verhindert werden kann. Das Dialogfeld wird sogar korrekt beschrieben, allerdings klappt sozusagen das UpdateWindow() nicht. Die Darstellung ist nicht korrekt. Allerdings von außen (also einer anderen Funktion) läßt sich das Control normal bearbeiten. So habe ich das deshalb auch gelöst. Ist mir wirklich schleierhaft, was da genau los ist.