Mal wieder Hänger in Dialog

[Holger Gothan]

Hi,

ich habe jetzt mal ein kleines VS6-Testprojekt entwickelt.
Unter http://www.dachdesigner.de/TesteTabCtrlHaenger.zip
(44 kB) kann Quelltext+Programm heruntergeladen werden.

Es ist einfach ein Dialog mit Radiobuttons und einem TabCtrl.
Dessen einziges ChildWindow ist ein Dialog mit
ownerdraw-Button und ein Editfeld.

Bei einem Klick auf einen Radiobutton hängt das Programm.

Kommentiert man die 2 Zeilen mit WS_EX_CONTROLPARENT
in TestDialog.cpp aus, dann geht alles.

Ist das normal?
Kann sich mal jemand das ansehen?

Tschüß, Holger.

[Martin Richter [MVP]]

Hallo Holger!

> Ist das normal?
> Kann sich mal jemand das ansehen?

Ja! Ich habe es mir angesehen. Und ja Dein Problem ist hausgemacht und
verständlich... ;-)

Was kriege ich dafür wenn ich Dir verrate woran es liegt?
Ich trinke übrigends für mein Leben gerne Schottischen
Single-Malt-Whisky und ab und zu darf es auch ein Irischer Whiskey sein...

Aber ich will mal nicht so sein:
Du hast eine Gruppe von Radiosbuttons.
Und wie jeder weißt beginnt eine Gruppe Auto-Radios mit dem ersten
WS_GROUP Control und endet mit dem nächsten Control das den WS_GROUP
Stil hat.
Jetzt hast Du aber kein nächstes Control, das nächste Control sagt
sogar, suche in mir weiter(WS_EX_CONTROLPARENT). Durch dieses Flag wird
das Tab-Control selber (selbst wenn es ein WS_GROUP hätte) als
unsichtbar übergangen...

Es entsteht auf eigenartige Weise eine endlose Schleife.
Ursache ist aber in jedem Fall die nicht abgeschlossene Gruppe von
Auto-Radios!

Der Fix war und ist elementar einfach.
1. Lösung: Eine Groupbox um die Radios
2. Lösung: Z-Order geändert sodass der OK Button auf den letzten Radio
folgt.
3. Lösung: Im Subdialog dem ersten Ownerdraw Button WS_GROUP verpasst.
4. Lösung: Unsichtbares Static Control mit WS_GROUP hinter den dritten
Radio.

Keine Lösung ist dem Tab-Ctrl WS_GROUP zu geben. Durch
WS_EX_CONTROLPARENT wird der Effekt aufgehoben.

Ein schönes Wochenende noch... ;-)

--
Martin Richter [MVP] WWJD http://blog.m-ri.de
"A well-written program is its own heaven; a poorly written
program is its own hell!" The Tao of Programming
FAQ: http://www.mpdvc.de Samples: http://www.codeproject.com

[Holger Gothan]

Hi,

"Martin Richter [MVP]" <martin....@mvps.org> schrieb im Newsbeitrag
news:fdj171$d9q$00$1...@news.t-online.com...

Danke für deine Hilfe, auf die Idee wäre ich niemals gekommen.

Seltsam 1)
Der Dialog lief bis vor 8 Wochen, ohne dass eine Änderung erfolgt ist.

Seltsam 2)
Bisher noch nie in dieses Problem gelaufen
Gibt es dazu eigentlich Styleguides? Man sollte also
vermutlich am besten Radiobuttons immer "abschließen".

Seltsam 3)
Hatte gleichen Hänger mit anderem Dialog, der definitiv keine
Radiobuttons hatte. Da ich diesen komplett neu gestaltet hatte,
kann ich es jetzt leider nicht mehr nachvollziehen.

Seltsam 4)
Ich habe noch einen mehrfach geschachtelten Dialog, der auch
hängt. Hier hatte sich fälschlicherweise bei einem der
Sub-Sub-Dialoge ein WS_EX_CONTROLPARENT eingeschlichen.
Wenn ich hier um die Radiobuttons eine Groupbox lege
(natürlich mit WS_GROUP und nach den Radiobuttons) dann
hängt das Programm weiterhin.
Erst mit Entfernung des WS_EX_CONTROLPARENT läuft
es jetzt. Also kann man diesen Hänger auch ohne Radiobuttons
produzieren. Leider kann ich hierfür kein Beispielprojekt zusammenbasteln.
Dieses funktioniert immer, selbst mit dem "falschen"
WS_EX_CONTROLPARENT.

Tschüß, Holger.

[Martin Richter [MVP]]

Hallo Holger!

> Danke für deine Hilfe, auf die Idee wäre ich niemals gekommen.

Ich sage Dir auch wie ich darauf gekommen bin:
Mir ist aufgefallen, dass der alte Button immer noch angeklickt war und,
dass der Statuswechsel checked/unchecked für die Buttons noch nicht
durchlaufen war.

Das war für mich der Aufhänger.

Alternativ: würde es auch funktionieren keine AUTO-Radios zu verwenden.
Dann musst Du halt selbst bei Klick für Setzen und Löschen sorgen.

> Seltsam 1)
> Der Dialog lief bis vor 8 Wochen, ohne dass eine Änderung erfolgt ist.

Gaaaanz sicher? Ein Tab-Order Wechsel ist schnell passiert. Dito eine
Änderung um Subdialog wo WS_GROUP entfällt oder hinzukommt.

> Seltsam 2)
> Bisher noch nie in dieses Problem gelaufen
> Gibt es dazu eigentlich Styleguides? Man sollte also
> vermutlich am besten Radiobuttons immer "abschließen".

Jupp! Unbedingt wenn man mit BS_AUTORADIO arbeitet!

> Seltsam 3)
> Hatte gleichen Hänger mit anderem Dialog, der definitiv keine
> Radiobuttons hatte. Da ich diesen komplett neu gestaltet hatte,
> kann ich es jetzt leider nicht mehr nachvollziehen.

Dann gebe ich Dir aus den Erfahrungen, die wir eben gemacht haben noch
einen Tipp:
Ein Ähnliches Durchlaufen der Controls geschieht auch beim Umsetzen des
Default-Buttons! Verwednest Du mit Garantie GotoDlgCtrl / NextDlgCtrl /
NEXTDLGCTL anstatt von SetFocus innerhalb Deiner Dialoge.
Bekannterweise kann SetFocus einige Ungereimtheiten auslösen.

> Seltsam 4)
> Ich habe noch einen mehrfach geschachtelten Dialog, der auch
> hängt. Hier hatte sich fälschlicherweise bei einem der
> Sub-Sub-Dialoge ein WS_EX_CONTROLPARENT eingeschlichen.
> Wenn ich hier um die Radiobuttons eine Groupbox lege
> (natürlich mit WS_GROUP und nach den Radiobuttons) dann
> hängt das Programm weiterhin.

Siehe 3.

> Erst mit Entfernung des WS_EX_CONTROLPARENT läuft
> es jetzt. Also kann man diesen Hänger auch ohne Radiobuttons
> produzieren. Leider kann ich hierfür kein Beispielprojekt zusammenbasteln.
> Dieses funktioniert immer, selbst mit dem "falschen"
> WS_EX_CONTROLPARENT.

Schade. Würde mich interessieren.

Wenn es Dir nichts ausmacht, würde ich gerne einen Blog-Eintrag über
diesen Effekt schreiben und Dein Sample verwenden. Ist das OK für Dich?

[Alexander Sailer]

Servus Martin:

> Alternativ: würde es auch funktionieren keine AUTO-Radios zu verwenden.
> Dann musst Du halt selbst bei Klick für Setzen und Löschen sorgen.

eine weitere Alternative:

Wir sind dazu übergegangen anstatt der RadioButtons eine ComboBox zu
verwenden. Dies ist für die Lyaoutänderung bei Erweiterung der Gruppe
wesentlich effektiver.

Dies nur als weiteren Denkanstoß für Holger.

MfG Alex
--
Künstliche Intelligenz ist leichter zu ertragen als natürliche Dummheit.
(Dieter Bär)
FAQ,s : http://www.mpdvc.de
Samples: http://codeguru.developer.com http://www.codeproject.com
Anstand: news:de.newusers.infos www.learn.to/quote

[Holger Gothan]

Hi,

"Martin Richter [MVP]" <martin....@mvps.org> schrieb im Newsbeitrag

news:fdqktt...@news.grutzeck.de...

> Hallo Holger!
>
> > Danke für deine Hilfe, auf die Idee wäre ich niemals gekommen.
>
> Ich sage Dir auch wie ich darauf gekommen bin:
> Mir ist aufgefallen, dass der alte Button immer noch angeklickt war und,
> dass der Statuswechsel checked/unchecked für die Buttons noch nicht
> durchlaufen war.
>
> Das war für mich der Aufhänger.
>
> Alternativ: würde es auch funktionieren keine AUTO-Radios zu verwenden.
> Dann musst Du halt selbst bei Klick für Setzen und Löschen sorgen.
>
> > Seltsam 1)
> > Der Dialog lief bis vor 8 Wochen, ohne dass eine Änderung erfolgt ist.
>
> Gaaaanz sicher? Ein Tab-Order Wechsel ist schnell passiert. Dito eine
> Änderung um Subdialog wo WS_GROUP entfällt oder hinzukommt.

vermutlich habe ich etwas übersehen. Es sollte wirklich schon immer
"hängen".

>
> > Seltsam 2)
> > Bisher noch nie in dieses Problem gelaufen
> > Gibt es dazu eigentlich Styleguides? Man sollte also
> > vermutlich am besten Radiobuttons immer "abschließen".
>
> Jupp! Unbedingt wenn man mit BS_AUTORADIO arbeitet!

Ich glaube ich habe gefunden, warum es bisher nie Probleme gab:
In den Dialogen wird eigentlich überall die Form
<StaticText>: <Eingabefeld>
verwendet und der StaticText hat ja per default WS_GROUP.
Und ich erinnere mich schwach, dass es auch ab und zu eine
Trace-Ausgabe im Debugger gelesen habe, dass
nicht alle Controls der Gruppe Radiobuttons sind.

>
> > Seltsam 3)
> > Hatte gleichen Hänger mit anderem Dialog, der definitiv keine
> > Radiobuttons hatte. Da ich diesen komplett neu gestaltet hatte,
> > kann ich es jetzt leider nicht mehr nachvollziehen.
>
>
> Dann gebe ich Dir aus den Erfahrungen, die wir eben gemacht haben noch
> einen Tipp:
> Ein Ähnliches Durchlaufen der Controls geschieht auch beim Umsetzen des
> Default-Buttons! Verwednest Du mit Garantie GotoDlgCtrl / NextDlgCtrl /
> NEXTDLGCTL anstatt von SetFocus innerhalb Deiner Dialoge.
> Bekannterweise kann SetFocus einige Ungereimtheiten auslösen.
>

...

Ja, siehe mein Posting vom 22.8.07.
Hier findet sich tatsächlich ein USER32!xxxRemoveDefaultButton
kurz vor dem SendMessage.
Da dieser Dialog "wichtig" war, habe ich diesen neu designed und
kann diesen Fehler dementsprechend nicht mehr nachvollziehen.
Allerdings hatte dieser auch das fehlerhafte WS_EX_CONTROLPARENT

>
> > Erst mit Entfernung des WS_EX_CONTROLPARENT läuft
> > es jetzt. Also kann man diesen Hänger auch ohne Radiobuttons
> > produzieren. Leider kann ich hierfür kein Beispielprojekt
zusammenbasteln.
> > Dieses funktioniert immer, selbst mit dem "falschen"
> > WS_EX_CONTROLPARENT.
>
> Schade. Würde mich interessieren.
>
> Wenn es Dir nichts ausmacht, würde ich gerne einen Blog-Eintrag über
> diesen Effekt schreiben und Dein Sample verwenden. Ist das OK für Dich?
>

logo

Tschüß, Holger.

[Martin Richter [MVP]]

Hallo Holger !

> Ich glaube ich habe gefunden, warum es bisher nie Probleme gab:
> In den Dialogen wird eigentlich überall die Form
> <StaticText>: <Eingabefeld>
> verwendet und der StaticText hat ja per default WS_GROUP.
> Und ich erinnere mich schwach, dass es auch ab und zu eine
> Trace-Ausgabe im Debugger gelesen habe, dass
> nicht alle Controls der Gruppe Radiobuttons sind.

Bingo!
Genau auf diese Warnung wollte ich nämlich auch in meinem Blog eingehen.
Diese Warnung macht mehr Sinn, als manche evtl. vermuten.
IMHO hätte man einen ASSERT daraus machen müssen.
Aber es geht eben auch so...

>> Bekannterweise kann SetFocus einige Ungereimtheiten auslösen.
>>
> ...
>
> Ja, siehe mein Posting vom 22.8.07.
> Hier findet sich tatsächlich ein USER32!xxxRemoveDefaultButton
> kurz vor dem SendMessage.
> Da dieser Dialog "wichtig" war, habe ich diesen neu designed und
> kann diesen Fehler dementsprechend nicht mehr nachvollziehen.
> Allerdings hatte dieser auch das fehlerhafte WS_EX_CONTROLPARENT

Man sieht: Alles hat seinen Grund!

>> Wenn es Dir nichts ausmacht, würde ich gerne einen Blog-Eintrag über
>> diesen Effekt schreiben und Dein Sample verwenden. Ist das OK für Dich?
>>
>
> logo

Danke!

[Martin Richter [MVP]]

Hallo Alexander!

> Wir sind dazu übergegangen anstatt der RadioButtons eine ComboBox zu
> verwenden. Dies ist für die Lyaoutänderung bei Erweiterung der Gruppe
> wesentlich effektiver.

Leider sind ComboBoxen bei weitem nicht so intuitiv. wie Radio-Button
Gruppen! Bei einer Gruppe von Radio-Buttons sieht man sofort was Sache
ist und möglich. Bei Comboboxen muss man immer erstmal aufklappen.

Sicherlich sind die auch platzsparender...

Es kommt eben immer darauf an.

[Alexander Sailer]

Servus Martin:

>> Wir sind dazu übergegangen anstatt der RadioButtons eine ComboBox zu
>> verwenden. Dies ist für die Lyaoutänderung bei Erweiterung der Gruppe
>> wesentlich effektiver.
>
> Leider sind ComboBoxen bei weitem nicht so intuitiv. wie Radio-Button
> Gruppen! Bei einer Gruppe von Radio-Buttons sieht man sofort was Sache
> ist und möglich. Bei Comboboxen muss man immer erstmal aufklappen.

Hier hast Du zweifellos Recht.

> Sicherlich sind die auch platzsparender...

...hier auch.

> Es kommt eben immer darauf an.

so ist es ;)

MfG Alex
--
Wer sich auf seinen Lorbeeren ausruht, trägt sie an der falschen Stelle.