XProfanprogramm hat Problem beim Neuzeichnen

  • Hallo Frank


    Ich habe ein kleines Problem mit Deinem Editor. In letzter Zeit hatte ich manchmal den seltsamen Effekt, daß XProfan-Programme plötzlich recht seltsam aussahen und nun konnte ich den Effekt mit Deinem Editor in Verbindung bringen.


    Das kleine Progrämmchen mag als anschauliches Beispiel dienen. Wenn Dein Editor das Fenster überdeckt verschwinden Rahmen und
    Hintergrund des nicht mit Text gefüllten Bereichs der Liste. Der Effekt ist auch an anderen Controls zu beobachten.
    Mag Dein Editor kein XProfan :lol:? Oder liegt's an meinem System? Mit den anderen hier vorgestellten Editoren und dem von Roland kann ich das Verhalten nicht nachvollziehen.


    Mein System: Vista 32bit Home Premium SP2


    Gruß Volkmar

  • Zitat

    Wenn Dein Editor das Fenster überdeckt verschwinden Rahmen und
    Hintergrund des nicht mit Text gefüllten Bereichs der Liste. Der Effekt ist auch an anderen Controls zu beobachten.

    Hm? Du meinst, wenn dein Code ausgeführt wird und das Editorfenster überlagert dein Programmfenster kurz und wird dann wieder zur Seite geschoben, haben sich Rahmen in deinem Programmfenster verändert?


    Nein, kann ich nicht nachvollziehen. Unter XP (32 Bit) und 2 x Windows 7 (32/64) Bit ist das noch nie passiert. Ich benutze meinen XProfEd-A ja selber jeden Tag zum programmieren (XProfan & Asm), da wäre mir das ja aufgefallen.
    Ist eigentlich auch, so wie ich das sehe, ein Neuzeichnen-Problem deines Programms, dass seinen Hintergrund ja restaurieren muß. Setz mal bitte dein %maxx -300 in Klammern.


    ralph: Danke für den Code, aber ich benutze eigene Splitter. Aber sicher wird Roland darauf zurück greifen. :)

    Gruß, Frank

  • Hallo Frank


    Ja ungefähr so. Ich habe mal die Positionen der Fenster so gestellt, daß ich mein Programm nur teilweise mit Deinem Editor überdecke. Dann kann ich sehen, daß die Controls anfangen, teilweise unsichtbar zu werden, wenn Dein Editor geöffnet wird. Ich dachte erst, es läge daran, daß das betreffende Programm uralt ist, weiß nicht mehr so genau, womit compiliert. Habe dann das Beispiel mit XProfan11 probiert und da passiert das Gleiche.
    Ist zwar unschön, aber wenn's anderswo läuft, dann lassen wir das. Bringt ja nichts, wenn Du das Problem auf verschiedenen Systemen nicht nachvollziehen kannst.


    Gruß Volkmar

  • Setz mal bitte dein %maxx -300 in Klammern. Kann XProfan mitunter verwirren, das Minus an der falschen Stelle. Oder verwende mal nur Cls, ohne das Window davor.
    Wie gesagt eher ein Neuzeichenproblem deiner Exe. Da kann meine Exe eigentlich nichts dazu.

    Gruß, Frank

  • Hallo Frank


    Beide Versuche, Klammern und auch nur CLS bringen das gleiche Ergebnis. Und eben nie ein Problem, wenn ich einen der anderen Editoren oder auch jedes andere Programm starte. Sonst hätte ich es als allgemeine Frage gestellt.
    Wenn das Problem aber auf anderen Systemen nicht nachvollziehbar ist, dann habe eben ich den schwarzen Peter :D. Mir fällt aber nichts ein, was ich ändern könnte.


    Trotzdem Danke und Gruß Volkmar

  • Volkmar, du kannst dir ja mal den Quellcode meines Editors ansehen und ein bischen damit experimentieren. Wenn du einen Auslöser für den Effekt findest, tausch ich ihn natürlich gerne aus, wenn das möglich ist. :)

    Gruß, Frank

  • Hallo Frank


    Wäre eine Möglichkeit, daß ich mal reingucke. Ich habe das Problem hier und wenn ich was finde, dann sehe ich auch gleich, ob das was bringt.


    Gruß Volkmar

  • Habe jetzt alles versucht, bekomme aber den Effekt, den Volkmar schildert, nicht hin.
    Im Interpreter stellt sich die Listbox VOR den Editor.
    Als EXE-Datei stellt sich der Editor VOR die Listbox.
    Alles bleibt erhalten und nichts ändert sich.
    XProfan-Version, die Neueste und Franks Editor, der Neueste.
    Windows-7

  • Horst
    Der Editor stellt sich immer vor die Listbox. Das betroffene Programm läuft bereits, wenn ich den Editor starte. Nur dann kann ich das Problem beobachten.


    Frank
    Erster Ansatz, eben festgestellt. Nur, wenn ich bei Start des Editors ein Projekt drin habe, was mehrere Tabs öffnet. Völlig leerer Editor oder nur ein offener Tab macht keine Probleme.


    Gruß Volkmar

  • Es passiert bei mir nur, wenn ich den Code als EXE-Datei laufen lasse. Dann wird der Listbox-Rahmen entfernt. Der Text bleibt aber ?!
    Im Interpreter-Modus ändert sich nichts !

  • Ja, Horst, der Inhalt bleibt. Edit oder Listbox sind dann einfach nur noch Text. Lustig wird's dann, wenn eine leere Liste oder ein leerer Editor im Spiel ist. Das verschwindet dann vollständig. Aber bei mir auch, wenn ich das Beispiel via Interpreter laufen lasse. Aber das könnte man dann noch mit den unterschiedlichen Betriebssystemen erklären, etwa in der Art wie etwas anderes Timing bei der Botschaftsbehandlung.


    Gruß Volkmar

  • Ich sehe aber nicht, wie das mit der Anzahl Tabs beim Start meines Editors zusmmen hängen soll. Erscheinen die Rahmen denn gar nicht mehr? Oder sind sie nach einem Neuzeichnen deines Fenster wieder da?

    Gruß, Frank

  • Hallo Frank


    Ist aber leider so und ich verstehe es auch nicht. Wenn ich mit der Maus über die Liste fahre, wird der Rahmen wieder angezeigt. Aber war die Liste nicht voll, bleibt der Hintergrund in dem Bereich, der keinen Text enthält in der Hintergrundfarbe des Fensters. Da hilft dann auch nicht das Überdecken mit einem anderen Fenster, %hdc2 enthält dann schon das ungültige Abbild. Abhilfe schafft dann nur, das Fenster zu minimieren und wieder zu öffnen oder ein Repaint.
    Irgendeine Idee, was dagegen zu machen wäre, habe ich auch nicht.


    Gruß Volkmar

  • Zitat

    %hdc2 enthält dann schon das ungültige Abbild. Abhilfe schafft dann nur, das Fenster zu minimieren und wieder zu öffnen oder ein Repaint.


    %hdc2 wird aber nicht dazu benutzt, die Abbilder der Controlrahmen zu restaurieren, die haben ihren eigenen DC.
    Eine Überlagerung der Child-Controls durch ein anderes Fenster bewirkt auch nicht zwangsweise ein Neuzeichnen der Childfenster durch das Parentfenster. Minimierung oder Repaint jedoch in jedem Fall. Ist wie vermutet ein Neuzeichnen-Problem deines Fensters, ausgelöst wahrscheinlich durch den Zustand, dass mein Programm das Neuzeichnen in einem ungünstigen Moment stört, wahrscheinlich unglückliches Timing. Darauf deutet auch wohl hin, dass bei wenigen Tabs der Zustand nicht auftritt. Ist ähnlich wie wenn eine Listbox stetig gefüllt wird und der Computer mit dem Neuzeichnen nicht hinterher kommt, weil er grad mit Füllen beschäftigt ist... :)

    Gruß, Frank

  • Volkmar, spendiere deinem Fenster mal den WS_CLIPCHILDREN-Style. Damit passt dein Fenster besser auf, dass seine Controls neu gezeichnet werden. Sollte eigentlich helfen. Also so:


    Gruß, Frank

  • Da habe ich wohl mal wieder schneller geschrieben, als ich denken kann. Stimmt natürlich, daß Controls ihre eigene wm_Paint-Behandlung ausführen.
    Mit dem ws_ClipChildren-Stil klappt es. Danke für den Tip.


    Gruß Volkmar

  • Super. :)
    Vielleicht sollte Roland den Style von vornherein jedem XProfan-Hauptfenster mitgeben.


    Ich verschieb die Offtopics mal in einen eigenen Thread.

    Gruß, Frank

  • Zitat von Frabbing;846027

    Super. :)
    Vielleicht sollte Roland den Style von vornherein jedem XProfan-Hauptfenster mitgeben.


    Besser nicht, dann gibt es mit einigen Controls Probleme. Der Stil ist immer
    zu testen, und gerade beim Hauptfenster ist das gefährlich.
    Es flimmert zwar meist weniger, aber es kommen auch manche Events der
    Unterfenster nicht mehr an!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!