none
MoveWindow Problem RRS feed

  • Frage

  • Kennt ihr das Problem, dass wenn man z.B. 2 Buttons hat auf einem Fenster und wegen einem WM_WINDOWPOSCHANGED nun diese Buttons mit MoveWindow verschiebt (um sie z.B. rechtsbündig zu halten), dass sie dann falsch gezeichnet werden? Also konkret:

    Button A wird verschoben und überlappt dann mit Button B. Button B wird darauf verschoben und überlappt nicht mehr mit Button A. Jetzt ist aber auf Button A noch ein "Abbruck" bzw. die alte Zeichnung vom Button B zu sehen.

    Ich kann das umgehen, wenn ich SetWindowPost mit SWP_NOCOPYBITS verwende. Aber im Grunde wäre ja diese Optimierung schon sinnvoll. Darum jetzt meine Frage: mach ich was falsch, dass das passier? Müsste ich noch irgendwelche Flags/Styles anders setzen? Oder ist das einfach... na ja, ein Bug im Windows?

    Rudolf

    Mittwoch, 21. Juni 2017 09:58

Antworten

  • Ah... DeferWindowPos... das ist es, was ich gesucht habe. Damit müsste es viel besser laufen.

    Rudolf

    • Als Antwort markiert Rudolf Meier Mittwoch, 21. Juni 2017 17:17
    Mittwoch, 21. Juni 2017 17:17

Alle Antworten

  • Ja, kenn ich. Als bug in Windows würde ich das aber nicht bezeichnen.

    Krieg man nur wieder hin, wenn man Button A dann nochmal neu malt nach Bewegen von Button B (m_btnA.RedrawWindow).

    Ich würde aber eher mit WM_WINDOWPOSCHANGING schon die Buttons verschieben, dann umgehst du das Problem mit dem langem Schieben und Überlappen können die Buttons dann eigentlich auch nicht. Dies macht übrigens der Developer ab 2015 auch schon. Da kann man Move und Resize von Controls im Resource Editor definieren. Mit welchem Developer arbeitest du?

    Gruß Guido

    Mittwoch, 21. Juni 2017 11:55
  • Nun ja, es passiert ja im Handler vom WM_WINDOWPOSCHANGED vom Parent dieser beiden Buttons. Das heisst, das MoveWindow vom ersten Buttons ist direkt die Zeile vor dem MoveWindow des zweiten Buttons. Und... wenn das jetzt da dazwischen kurzzeitig überlappt, dann... na ja, kann man das sicher fast als Bug ansehen. Aber ok, man könnte sich drüber streiten.

    Einen Gui Editor verwende ich keinen dafür (bzw. teilweise eine eigene Lösung). Aber ist ein interessanter Hinweis, dass der 2015er Code dazu generiert. Mal sehen was der so tut.... etwas reverse-engineering kann nie schaden um auf neue Ideen zu kommen :-).

    Danke für den Tip.

    Rudolf

    Mittwoch, 21. Juni 2017 14:54
  • Ah... DeferWindowPos... das ist es, was ich gesucht habe. Damit müsste es viel besser laufen.

    Rudolf

    • Als Antwort markiert Rudolf Meier Mittwoch, 21. Juni 2017 17:17
    Mittwoch, 21. Juni 2017 17:17