| |
| |
|
Bernd
Haase | allô Frank !
dans meinen Listviews wird, si je pour untern scrollen veux, qui la ligne unterbrochen. mais toujours seulement beim Runterscrollen.
la hâte Du nen conseil, comment on cela abstellen peux ou bien ist cela nen Hardwarefehler (Grafikkarte ?). |
|
| |
| Mit freundlichem Gruß Bernd Sind schon viele erfroren, aber noch keiner ist erstunken !![...]  | 04.07.2007 ▲ |
|
| |
|
|
 | Jojo typisches ListviewProblem - J'ai eu aussi déjà einmal - hat vordergründig nix avec Franks DLL trop 1faire.
Ändere un peu qui YGröße ou bien schalte cela Manifest/Theme pour cet Contrôle ab.  |
|
| |
| |
| |
|
|
Frank
Abbing | oui, un Bug im SysListview32. voilà MS gefordert, pas je  .
Versuche iFs conseil ou bien schalte qui Gitter aus. |
|
| |
| |
| |
|
|
| dans Vue ist qui Bug behoben alors s'il te plaît OS updaten lol!  |
|
| |
| |
| |
|
|
| | Öhm maintenant grad vois je seulement - il hat garnichtmal un Theme/Manifest sichtbar - alors bleibt seulement YGröße changement ou bien Gitter débrancher. |
|
| |
| |
| |
|
|
Thomas
Freier | ...ou bien peux on den Scrollbalken débrancher ?
...ou bien gar seulement qui Pfeile ?
...et pourquoi tritt chez den Gridboxen pas qui gleiche effet sur?
car beim Scrollen avec qui souris bleibt cela Gitternetz conservé, bzw. es wird aussi pour 10 durchgescrollten Zeilen avec qui Pfeiltaste wieder angezeigt. |
|
| |
| |
| |
|
|
Frank
Abbing | non, aussi chez Gridboxen tritt qui effet sur. et chez externe Programmen habe je es aussi beobachtet.
Es passiert, si le Gitter aktiviert sommes et qui Scrollpfeile gedrückt volonté et qui Listviewhöhe et Texthöhe irgendwie pas kompatibel genug sommes. Besser peux je es pas décrire.
Ist mais définitif un Bug des SysListview32.
Scroller débrancher allez per Style. |
|
| |
| |
| |
|
|
| ensuite beschreibe ego la fois besser
c'est un Rundungsfehler quel chez qui Berechnung auftritt pour qui Hauteur des per BitBlit trop verschiebenden Bereiches. |
|
| |
| |
| |
|
|
Thomas
Freier | Frank, tu as droite, chez qui Gridbox tritt es aussi sur.
un Auge schlief wohl déjà.
Merkwürdig cependant, si déjà Rundungsfehler, pourquoi enden qui fehlenden (ou bien verschobenen) Linien pour qui zehnten la ligne, si plus dans einem rame avec qui Pfeiltaste gescrollt volonté? |
|
| |
| |
| |
|
|
Bernd
Haase | AHA ! ensuite doit on alors versuchen, une vernünftige Einstellung qui ListviewGröße et des Schriftbildes hinzubekommen.  |
|
| |
| Mit freundlichem Gruß Bernd Sind schon viele erfroren, aber noch keiner ist erstunken !![...] | 05.07.2007 ▲ |
|
| |
|
|
| Thomas Freier
Frank, tu as droite, chez qui Gridbox tritt es aussi sur.
un Auge schlief wohl déjà.
Merkwürdig cependant, si déjà Rundungsfehler, pourquoi enden qui fehlenden (ou bien verschobenen) Linien pour qui zehnten la ligne, si plus dans einem rame avec qui Pfeiltaste gescrollt volonté?
Erkläre je Dir. MS ist oui pas doof et wird naturellement aussi Programmtechnisch toujours seulement cela 1faire quoi absolument nötig ist. si Du z.B. une la ligne runterscrollst wird arrêt um une la ligne alles hochgeblittet - et qui unterste la ligne récente peint. (mais aussi seulement si pas Softscroll/Listenscrollen optimaliser aktiviert ist car si optimiert wird sogar pixelweise gescrollt quoi cela ganze soft air peut (imho ab nt4 im gui subsystem possible) ) si eh bien mais plus que une la ligne gescrollt wird so ändert sich naturellement le nombre qui récente-trop-zeichnenden Zeilen. Hiermit changement sich naturellement aussi Werte (Koordinaten) des trop blittenden Bereiches wodurch qui Rundungsfehler pratique souvent ausbleibt. cela ganze ist mais encore deutlich komplizierter car il y a réellement sogar encore une Effektivrechnung quelle kurzum beurteilt si es sich überhaupt lohnt (prozesstechnisch gesehen) une certain Bereich trop blitten - ou bien ihn gar récente trop pinseln. cet la facture bezieht sogar qui Geschwindigkeit des Computers/Grafikkarte avec un. et ensuite wird cela ganze nochmal verkompliziert car: chacun Zeichenanforderung wird überhaupt garnicht tout de suite fonctionnement - entier im Gegenteil. Es landed alles dans einer Anforderungsschleife (Spooler) quelle avant chaque Zeichnen nochmals optimiert wird. dans cette letzten Ausführungsschicht pour Zeichenoperationen wird z.B. aussi qui Z-Achse überprüft bzw. Zeichenoperationen wegoptimiert quelle pas sichtbar würden. Dank cette letzten Schicht ist es aussi possible Zeichnungen trotz angeblicher Ausführung avec wm_setredraw trop beeinflussen. sur allemande une Pixel mettons sans cela cette gezeichnet wird weil qui dernier Ausführungsschicht qui Zeichenoperationen sagt: nö. toutefois ist cela Pixel im grenier naturellement geändert - de quoi qui GrKarte mais nix sais.
Zurück zum Thema am Beispiel: tu as ne Krücke de calculateur - qui ewig braucht um quoi anzuzeigen - eh bien sendest Du 3 la fois entier vite per sendmessage moins un SysLV32 qui Pfeilnachuntentaste. cela Windows-GUI wird eh bien pas 3 la fois une la ligne scrollen - mais erkennen cela es lohnenswerter ist juste trois Zeilen trop scrollen. qui selbe opération cependant sur nem 12GHZ-calculateur pourrait sogar pour sorgen cela pas seulement wirklich Dreimal une la ligne gescrollt wird - mais peut-être sogar chacun la ligne Pixelweise. Öhm. |
|
| |
| |
| |
|
|
Thomas
Freier | @iF: merci pour qui détaillé Erklärung.
Gedankenspiel: peux on qui représentation dans diesem le cas zwangsweise erneuern?
un Befehl so dans qui Art : %wmPaint |
|
| |
| |
| |
|
(1.113)
Deutsch
English
Français
Español
Italia