Frame as Container

[ITVS]

Hello Timo,

thanks for these great controls.

But I have a problem when the frame-control is used as a container and the form is a MDIChild.
For example the textbox: when you press in the textbox twice, the LostFocus event is fired
and the frame is the active control, so the validate-event is never fired.
Is there any chance that the textbox don't lost the focus?

with friendly regards Lars Schneider - ITVS

[TiKu]

Hi,

For example the textbox: when you press in the textbox twice, the LostFocus event is fired
and the frame is the active control, so the validate-event is never fired

You mean double-clicking into the textbox makes it fire the LostFocus event?

Regards
TiKu

[ITVS]

Hi TiKu,
not necessarily a double click, if the second click is executed (even seconds later) the LostFocus event is fired.

Please see my attachment, when the form is loading without the MDIForm, it works fine.

Thank you for your great job
with friendly regards Lars Schneider - ITVS

[TiKu]

Thanks for the sample. I can reproduce the behavior and will try to find the reason during the weekend.

Regards
TiKu

[TiKu]

Hi,

I've found a fix, but it still has some side-effects that I need to sort out. Also I want to do more tests before releasing a fixed version.

Regards
TiKu

[TiKu]

Hi,

here is a fixed version. I've changed handling of window messages quite a lot, so I suggest to test carefully before using this version in production.

Version 1.8.2 (Setup)
Version 1.8.2 (ZIP)

Best regards
TiKu

[ITVS]

HalloTiKu,
ich schreibe diesmal in deutsch .

Bin jetzt erst dazu gekommen das neue Release zu testen, vielen Dank.
Dennoch habe ich leider immernoch das Problem, dass die TextBox den Focus verliert, wenn das Frame-Control in einer MDI-Umgebung eingesetzt wird.

Ich habe aber einen kleinen Workaround gefunden:
Per SubClassing zuerst WM_MOUSEACTIVATE (&H21) ins Nirvana schicken, dann gibt es nur ein kleines Problem mit der Neuzeichnung, wenn das Click-Event ausgelöst wird.
Dann noch per SubClassing WM_LBUTTONDOWN (&H201) unterdrücken und die klick-Ereignisse (wenn aktiviert) simulieren, danach funktioniert das Control fehlerfrei.

Viele Grüße Lars Schneider - ITVS

[TiKu]

Hi,

könnte es sein, dass die gefixte Version des OCX einfach nur nochmal registrieren fehlt? Welche Version verwendet wird, sieht man im About-Dialog. Bei mir bekomme ich es mit der oben verlinkten Version 1.8.2 und dem MDI-Beispiel nicht mehr hin, per Doppelklick auf den Frame den Fokus zu verändern.

Grüße
TiKu

[TiKu]

Hi,

ist inzwischen bekannt, ob tatsächlich noch eine alte Version verwendet wurde? Ich würde die gefixte Version gern als Final veröffentlichen, was natürlich wenig sinnvoll ist, wenn das Problem noch besteht.

Grüße
TiKu

[ITVS]

Hi,

entschuldige die späte Antwort, bin zur Zeit im Außendienst tätig (zum Glück nur noch diese Woche ).
Habe es gerade nochmal versucht, das Problem tritt sowohl noch in der IDE, als auch im kompilierten Projekt auf (das gleiche Testprojekt).
Das verwendete OCX ist Version 1.8.2.150.

Habe es auch mal im XP-Mode (unter Win7 Pro., 64bit) versucht, da besteht auch das gleiche Problem!

Viele Grüße
Lars Schneider - ITVS

[TiKu]

Ich habe mal einen Screencast angefertigt, der zeigt, dass ich das Problem nicht mehr reproduzieren kann. Immer wenn der Mauszeiger kurz über dem Frame oder der Form verweilt, habe ich wie wild geklickt.
Betriebssystem: Windows 7 SP1 x64, aber auch unter XP lässt sich der Fehler nicht mehr nachstellen.

Hier das Video (38 MB): www.timosoft-software.de/stuff/btnctlsfocus.avi

Ich wüsste auch nicht woran es noch liegen kann. Der Code ist an sich korrekt. Der Frame prüft bei WM_MOUSEACTIVATE per GetMessagePos und WindowFromPoint, ob die Nachricht den Frame meint. Ist das der Fall, wird MA_NOACTIVATEANDEAT zurückgegeben. Dazu gibt es noch ein wenig Logik, damit die Doppelklick-Events auch weiterhin funktionieren.

Grüße
TiKu

[ITVS]

Hallo TiKu,

das Video erklärt einiges, vielen Dank dafür.

Das Problem ist nicht das Klicken im Frame selbst, sondern in den TextBoxen, wenn hier mind. 2 mal geklickt wird, dann wird das LostFocus-Event ausgelöst.
Wird jetzt die 2. Box angeklickt, feuert die erste kein Validate ab.

Anbei die grafische Version.

Viele Grüße und schöne Ostern
Lars Schneider - ITVS

[TiKu]

Ah, okay, danke. Ich schaus mir heute Abend mal an.

[TiKu]

Hi,

ich kann den Fehler reproduzieren, aber habe noch überhaupt keine Idee was da falsch läuft. Es deutet allerdings einiges darauf hin, dass es sich um einen (weiteren) Fehler in der ATL-Bibliothek handelt - was die Fehlersuche nicht wirklich vereinfacht.

Grüße
TiKu

[TiKu]

Ich glaube ich habs. Hier das aktualisierte Build:

Version 1.8.2 (Setup)
Version 1.8.2 (ZIP)

Ob es ein Fehler in ATL ist, lässt sich schwer sagen. Dazu müsste ich mir erstmal anschauen wie das z.B. in der MFC gelöst ist. Auf jeden Fall ist die ATL-Bibliothek an dieser Stelle so aufgebaut, dass ein ATL-basiertes Container-Control wie mein Frame mit an Sicherheit grenzender Wahrscheinlichkeit diesen Fehler aufweist.

Im Detail:
Die Klasse CComControlBase behandelt die Nachricht WM_MOUSEACTIVATE so, dass es das Control bei Erhalt dieser Nachricht aktiviert. WM_MOUSEACTIVATE wird allerdings von Windows entlang der Fensterhierarchie nach oben geleitet bis ein Fenster die Nachricht behandelt. Klickt man in die Textbox auf dem Frame, wird die Nachricht also an den Frame geleitet (nur ab dem 2. Klick, weil die Textbox den ersten Klick selbst behandelt). Das führt dazu, dass CComControlBase das Frame-Control aktiviert, was wiederum zum Fokuswechsel auf COM-Ebene führt. Um den Fehler zu umgehen, muss das Frame-Control solche WM_MOUSEACTIVATE-Nachrichten explizit an CComControlBase vorbeischleusen. Nachrichten vor CComControlBase zu verstecken ist allerdings nicht gerade üblich - man wird also von ATL in eine Richtung gelenkt, die zum Fehler führt.

Grüße
TiKu