2009-08-31 12 views
5

Sono bloccato da alcuni comportamenti bizzarri nell'editor di moduli di Visual Studio. Ho visto questo su un paio di forme diverse nella mia applicazione. Ogni volta che apro il modulo nell'editor di layout di Visual Studio alcuni controlli si troveranno in una posizione diversa rispetto a quando li ho lasciati. In genere alcuni pulsanti si spostano solo leggermente dall'angolo in basso a destra. Ma non sono solo pulsanti, in un caso è un pannello contenitore che si muove. Devo riposizionarli quindi salvare e chiudere il modulo. Ho confermato che l'editor di layout modifica effettivamente la proprietà Location quando il modulo viene aperto perché se salvi e chiudi il modulo con i pulsanti nella posizione corretta, saranno corretti in fase di runtime.I controlli WinForms vengono dislocati ogni volta che viene visualizzato il modulo

Questo non è un problema con le proprietà Anchor o Dock non impostate correttamente. L'editor sta effettivamente cambiando la proprietà Location dei miei controlli. Ho esaminato il file .designer.cs e non vedo nulla di insolito. Ho provato a cancellare e ricreare questi controlli ma il problema persiste.

Qualche idea cosa posso fare?

Non è uno stopper. Devo solo essere molto attento a correggere i controlli manualmente ogni volta che lo apro nell'editor di layout di winforms.

Modifica: Visual Studio esegue effettivamente il checkout del file automaticamente per impostare Location in base a ciò che pensa ostinatamente debba essere.

+1

È questo uno stock VS2008 o viene applicata SP1? – Powerlord

+0

Sì SP1 è installato. La sua VS2008 Team Edition + SP1. –

+0

Ciao. Hai trovato una soluzione a questo problema? All'improvviso sto vivendo lo stesso identico comportamento! – Jalil

risposta

2

Ho trovato la risposta a questo problema, ma sembra proprio un bug per me. Non è mai stato risolto dal 2003!

In breve: l'ereditarietà visiva non funziona bene con l'ancoraggio.

risposta completa qui: http://weblogs.asp.net/rweigelt/archive/2003/09/24/28984.aspx

+0

ha risolto il problema? Non ho più accesso al codice, quindi non posso testarlo. –

+0

Forse potresti provare anche i numeri sugli archi ecc ;-) – Andrew

+0

Accetto questa risposta sulla base dei risultati di Jalil e poiché questa domanda è rimasta aperta per così tanto tempo questa sembra la migliore risposta che otterremo. Ma come autore originale della domanda non posso dire con certezza se questo risolvesse il mio problema originale perché non ho più accesso a quel codice. –

0

Molto probabilmente un problema correlato al DPI. Controllare designer.cs per una proprietà AutoScaleMode e provare a modificarlo (o aggiungerne uno) per impostare il modulo.AutoscaleMode = Font

+0

Era già impostato su AutoScaleMode = Font, lo stesso di tutti i miei altri moduli. –

0

Provare a bloccare i controlli in modalità progettazione e quindi vedere come va.

+0

Ho dimenticato di dirlo ma ci ho provato. –

1

Sono d'accordo con PaulG, il suo più probabile un problema relativo al DPI

Si prega di modificare le impostazioni della scheda video da grande (120dpi) a Normale (96 dpi).

+0

Questo non ha funzionato per me. – Jalil

2

L'editor WinForms è un WYSIWYG che richiede all'editor di eseguire effettivamente il codice di layout per mostrare esattamente come sarà il modulo. Pur essendo estremamente conveniente, ci sono un certo numero di problemi di pollo e uova che iniziano a devastare il tuo editor.

Un problema comune è quello del dimensionamento. A volte le proprietà del controllo sono ordinate in modo errato (e, essendo auto-generate, non è possibile risolvere questo problema). Il risultato è che alcuni valori necessari non sono impostati fino a dopo la proprietà che ne ha bisogno. Un esempio famoso è SplitContainer e MinSize di Panel2 (vedere http://social.msdn.microsoft.com/Forums/en-US/winformsdesigner/thread/ee6abc76-f35a-41a4-a1ff-5be942ae3425). È possibile che tu stia riscontrando un problema di root simile, ma il risultato è che la posizione dei controlli sta cambiando.

Vorrei esaminare l'ordine delle proprietà nella finestra di progettazione e provare a determinare se questa potrebbe essere la radice del problema. Se lo è, potrebbe essere necessario impostare alcune proprietà in fase di esecuzione. In generale, però, raramente c'è una "correzione" reale: la risoluzione è più spesso di una "soluzione".

Questi tipi di problemi facevano parte della motivazione per la creazione di WPF. La natura dichiarativa di XAML aiuta a prevenire questo tipo di occorrenza pur fornendo la sensazione WYSIWYG.

Problemi correlati