| |
| |
|
Bernd
Haase | Hallo Frank !
In meinen Listviews wird, wenn ich nach untern scrollen will, die Zeile unterbrochen. Aber immer nur beim Runterscrollen.
Hast Du nen Rat, wie man das abstellen kann oder ist das nen Hardwarefehler (Grafikkarte ?). |
|
| |
| Mit freundlichem Gruß Bernd Sind schon viele erfroren, aber noch keiner ist erstunken !![...]  | 04.07.2007 ▲ |
|
| |
|
|
 | Jojo typisches ListviewProblem - hatte ich auch schon einmal - hat vordergründig nix mit Franks DLL zu tun.
Ändere ein wenig die YGröße oder schalte das Manifest/Theme für dieses Control ab.  |
|
| |
| |
| |
|
|
Frank
Abbing | Ja, ein Bug im SysListview32. Da ist MS gefordert, nicht ich  .
Versuche iFs Rat oder schalte die Gitter aus. |
|
| |
| |
| |
|
|
| In Vista ist der Bug behoben also bitte OS updaten lol!  |
|
| |
| |
| |
|
|
| | Öhm jetzt grad sehe ich erst - er hat garnichtmal ein Theme/Manifest sichtbar - also bleibt nur YGröße ändern oder Gitter abschalten. |
|
| |
| |
| |
|
|
Thomas
Freier | ...oder kann man den Scrollbalken abschalten ?
...oder gar nur die Pfeile ?
...und warum tritt bei den Gridboxen nicht der gleiche Effekt auf?
denn beim Scrollen mit der Maus bleibt das Gitternetz erhalten, bzw. es wird auch nach 10 durchgescrollten Zeilen mit der Pfeiltaste wieder angezeigt. |
|
| |
| |
| |
|
|
Frank
Abbing | Nein, auch bei Gridboxen tritt der Effekt auf. Und bei externen Programmen habe ich es auch beobachtet.
Es passiert, wenn die Gitter aktiviert sind und die Scrollpfeile gedrückt werden und die Listviewhöhe und Texthöhe irgendwie nicht kompatibel genug sind. Besser kann ich es nicht beschreiben.
Ist aber definitiv ein Bug des SysListview32.
Scroller abschalten geht per Style. |
|
| |
| |
| |
|
|
| Dann beschreibe ichs mal besser
Es ist ein Rundungsfehler welcher bei der Berechnung auftritt für die Höhe des per BitBlit zu verschiebenden Bereiches. |
|
| |
| |
| |
|
|
Thomas
Freier | Frank, du hast recht, bei der Gridbox tritt es auch auf.
Ein Auge schlief wohl schon.
Merkwürdig jedoch, wenn schon Rundungsfehler, warum enden die fehlenden (oder verschobenen) Linien nach der zehnten Zeile, wenn mehr in einem Zug mit der Pfeiltaste gescrollt werden? |
|
| |
| |
| |
|
|
Bernd
Haase | AHA ! Dann muß man also versuchen, eine vernünftige Einstellung der ListviewGröße und des Schriftbildes hinzubekommen.  |
|
| |
| Mit freundlichem Gruß Bernd Sind schon viele erfroren, aber noch keiner ist erstunken !![...] | 05.07.2007 ▲ |
|
| |
|
|
| Thomas Freier
Frank, du hast recht, bei der Gridbox tritt es auch auf.
Ein Auge schlief wohl schon.
Merkwürdig jedoch, wenn schon Rundungsfehler, warum enden die fehlenden (oder verschobenen) Linien nach der zehnten Zeile, wenn mehr in einem Zug mit der Pfeiltaste gescrollt werden?
Erkläre ich Dir. MS ist ja nicht doof und wird natürlich auch Programmtechnisch immer nur das tun was unbedingt nötig ist. Wenn Du z.B. eine Zeile runterscrollst wird halt um eine Zeile alles hochgeblittet - und die unterste Zeile neu gepinselt. (Aber auch nur wenn nicht Softscroll/Listenscrollen optimieren aktiviert ist denn wenn optimiert wird sogar pixelweise gescrollt was das ganze soft aussehen lässt (imho ab nt4 im gui subsystem möglich) ) Wenn nun aber mehr als eine Zeile gescrollt wird so ändert sich natürlich die Anzahl der neu-zu-zeichnenden Zeilen. Hiermit ändern sich natürlich auch Werte (Koordinaten) des zu blittenden Bereiches wodurch der Rundungsfehler praktisch oft ausbleibt. Das ganze ist aber noch deutlich komplizierter denn es gibt tatsächlich sogar noch eine Effektivrechnung welche kurzum beurteilt ob es sich überhaupt lohnt (prozesstechnisch gesehen) einen bestimmten Bereich zu blitten - oder ihn gar neu zu pinseln. Diese Rechnung bezieht sogar die Geschwindigkeit des Computers/Grafikkarte mit ein. Und dann wird das ganze nochmal verkompliziert denn: Jede Zeichenanforderung wird überhaupt garnicht sofort ausgeführt - ganz im Gegenteil. Es landed alles in einer Anforderungsschleife (Spooler) welche vor jedem Zeichnen nochmals optimiert wird. In dieser letzten Ausführungsschicht für Zeichenoperationen wird z.B. auch die Z-Achse überprüft bzw. Zeichenoperationen wegoptimiert welche nicht sichtbar würden. Dank dieser letzten Schicht ist es auch möglich Zeichnungen trotz angeblicher Ausführung mit wm_setredraw zu beeinflussen. Auf Deutsch einen Pixel setzen ohne das dieser gezeichnet wird weil die letzte Ausführungsschicht der Zeichenoperationen sagt: nö. Dennoch ist das Pixel im Speicher natürlich geändert - wovon die GrKarte aber nix weiß.
Zurück zum Thema am Beispiel: Du hast ne Krücke von Rechner - die ewig braucht um was anzuzeigen - nun sendest Du 3 Mal ganz schnell per sendmessage an ein SysLV32 die Pfeilnachuntentaste. Das Windows-GUI wird nun nicht 3 Mal eine Zeile scrollen - sondern erkennen das es lohnenswerter ist gleich drei Zeilen zu scrollen. Die selbe Operation jedoch auf nem 12GHZ-Rechner könnte sogar dafür sorgen das nicht nur wirklich Dreimal eine Zeile gescrollt wird - sondern vielleicht sogar jede Zeile Pixelweise. Öhm. |
|
| |
| |
| |
|
|
Thomas
Freier | @iF: Danke für die ausführliche Erklärung.
Gedankenspiel: kann man die Darstellung in diesem Fall zwangsweise erneuern?
Ein Befehl so in der Art : %wmPaint |
|
| |
| |
| |
|
(514)
Deutsch
English
Français
Español
Italia