2009-09-10 19 views
7

Ho un paio di listboxes su un WPF di Windows, con Height="Auto" Width="Auto" impostato sul modulolayout di WPF in una finestra

La forma dimensioni perfettamente su diverse risoluzioni, ma il problema è che quando si preme il pulsante di ingrandimento una spessa "Black L" è visibile mentre il modulo viene ridimensionato. Ho visto questo su un bel po 'di applicazioni WPF, ma non ho dovuto risolvere il problema fino ad ora.

C'è un modo per DoubleBuffer della finestra o chiamare SuspendLayout() in WPF mentre i controlli del modulo vengono ridimensionati? Come posso liberarmi di questa brutta L nera?

+1

Puoi aggiungere uno screenshot del manufatto visivo che stai vedendo? Non riesco a immaginarlo. –

+0

Ho provato a stampare lo schermo ma Windows non ha riscontrato il problema, ma ho realizzato un rapido simulato in vernice. http://img16.imageshack.us/img16/403/25229633.png Il problema si verifica solo quando le caselle di riepilogo contengono dati. Se non aggiungo alcun dato, allora il problema non si verifica. È quasi come se le caselle di riepilogo ricaricassero i dati quando le finestre vengono ridimensionate. – Vault

+0

Sembra duplicato a questa domanda: http: // StackOverflow.it/questions/555326/how-can-i-make-resizing-wpf-windows-less-laggy –

risposta

3

Citando uno dei recenti Hanselminutes:

Ian Griffiths: ... C'è il win32 spunto che è un loop normale messaggio Win32 e WPF messaggi piscine fuori di questo e li mette su di essa la propria spunto e poi trattare con esso su di essa la propria dolce tempo, in parte perché vuole essere in grado di riordinare gli eventi come entrano. sarà la priorità certe cose sopra l'elaborazione di input, per esempio, e che, il modo, è il motivo si ottiene leggermente bizzarro ridisegno movimentazione sul ridimensionamento applicazioni WPF, voi avranno notato si ottiene un po 'di spazio vuoto che appare temporaneamente quando si ridimensiona una finestra è perché è riconoscere l'evento di ridimensionamento prima che in realtà davvero fa qualcosa con esso e quindi le vernici si verificano leggermente fuori sincrono con quello che normalmente c'è. Quindi, è una coda messaggi win32 ma non è la in realtà la coda messaggi principale in WPF e questo è tutto il tipo di implementazione dettagli il dispatcher tenta di nascondere quanto più possibile.

Sembra rilevante per il tuo problema, anche se non sono a conoscenza di una soluzione completa. Forse dovresti provare a cambiare alcune priorità del Dispatcher?

+0

grazie per il suggerimento, proverò che lo smantellamento della virtualizzazione non ha funzionato – Vault

0

Vault, penso che questo possa avere qualcosa a che fare con la virtualizzazione dell'interfaccia utente che le listbox eseguono. La virtualizzazione consente alla listbox di caricare solo gli elementi dell'interfaccia utente sottoposti a rendering. La listbox funziona con l'aiuto di VirtualizingStackPanel come ItemsPanelTemplate.

Quindi la mia ipotesi sembra essere ... che massimizzare la finestra avrebbe spinto le listbox a generare più elementi dell'interfaccia utente e il ritardo avrebbe inciso la 'L' nera.

È possibile rimuovere la virtualizzazione e controllare se appare ancora la "L" nera. A proposito, la virtualizzazione è in effetti una cosa "buona" e disattivarla è generalmente una cattiva idea.

+1

. Per essere onesti, ho riscontrato questo problema in diverse applicazioni WPF e gli sviluppatori spingono sempre il problema sul retro della coda poiché è considerato come priorità bassa – Vault

Problemi correlati