Passato a VS 2012 e ora il modulo non viene ridimensionato correttamente?

Question

Sono passato a VS 2012 ieri da VS 2010 e tutto sembrava andare bene eccetto questo.

Ho un pulsante sul mio modulo che quando premuto estende la larghezza del modulo per mostrare controlli aggiuntivi. Premi di nuovo il pulsante e riduce la larghezza per nascondere quei controlli. Ora tutto questo ha funzionato alla grande in VS 2010 e funziona bene anche quando eseguo il debug in VS 2012, ma non appena pubblico o compilo il progetto e apro l'exe quando fai clic sul pulsante, aggiunge 5 alla larghezza anziché 100+ ha bisogno di. Lo clicco di nuovo e lo cambierà in 372 come dovrebbe e mostrerà tutti i miei controlli. Lo faccio di nuovo clic per nascondere i controlli e nasconde parzialmente i controlli (va a 188 + il misterioso 5) Spero che tutto ciò abbia senso e spero che ci sia un modo migliore per eseguire il processo che ho bisogno.

Ecco il codice con cui sto attualmente lavorando e non ho cambiato nulla tra il passaggio dal 2010 al 2012. In effetti, se apro questa stessa soluzione nel 2010 e pubblico tutto funziona bene.

private void button1_Click(object sender, EventArgs e) 
    { 
     if (this.Width == 188) 
     { 
      this.Width = 372; 
      this.Height = 540; 
      progressBar.Value = 100; 
      copied_status.Text = ("Output View Enabled"); 
     } 
     else 
     { 
      progressBar.Value = 100; 
      copied_status.Text = ("Output View Disabled"); 
      this.Width = 188; 
      this.Height = 540; 
     } 

     if (this.Width == 372) 
     { 
      button1.Text = "<<"; 
     } 
     else 
      button1.Text = ">>"; 

    } 

Answer 1

La larghezza del modulo non è stata di 188 pixel in un tempo lungo. Ora con VS2012, Windows smette finalmente di mentire.

In questione sono i bordi della finestra di grasso in Aero. Erano un estremo problema di app quando la funzionalità è stata introdotta in Vista. Molto necessario perché quei due pixel dove si stenta a colpire con il mouse. Ma drasticamente incompatibile con il modo in cui un'applicazione crea una finestra. Richiede una dimensione specifica della finestra, la dimensione esterna, gli argomenti nWidth e nHeight della funzione CreateWindow(). Ma ciò che conta davvero è la dimensione dell'area cliente, la parte della finestra all'interno dei confini. Se Microsoft non avesse fatto qualcosa al riguardo, le vecchie applicazioni sarebbero finite con un'area client troppo piccola. Che sembra molto male, il contenuto della finestra non si adatta più. Ad esempio, un controllo verso il lato inferiore o destro del modulo non verrà visualizzato completamente.

Quindi, a malapena, Aero ingrandisce la finestra per la larghezza extra dei bordi grossi. E quando l'app chiede le dimensioni della finestra, si dice che è più piccola della stessa larghezza aggiunta. L'app non sa di meglio di quanto sia ancora in esecuzione con le stesse dimensioni della finestra che aveva su XP. Funziona abbastanza bene, ma non è esattamente l'ideale. Ad esempio, è difficile ottenere i bordi della finestra per allinearli correttamente con tale bugia.

Se Aero mentirà o meno alla dimensione della finestra si basa sul sistema operativo di destinazione registrato nell'intestazione EXE. Quando vede una versione più vecchia di 6.00, il numero di versione di Vista, allora supporrà che il tuo EXE sia un programma legacy che non conosce la funzione di bordo grassa. Quindi deve essere mentito. Sei stato in esecuzione con quel numero di versione di destinazione impostato su 4.00 per un lungo periodo, è scritto dal compilatore .NET quando crea il tuo programma. Puoi vederlo con dumpbin.exe /headers yourapp.exe.

Questo finalmente cambiato in VS2012 e .NET 4.5. Che è una versione .NET che non è disponibile in XP. Il compilatore può finalmente fare la dura supposizione che XP sia cronologico e si eseguirà su una versione di Windows che supporta Aero. Quindi imposta la versione di Windows di destinazione nell'intestazione EXE alle 6.00. Corrispondentemente, Aero ora smetterà di mentire riguardo alle dimensioni della finestra. Ottieni quello vero, non quello falso.

Quindi una soluzione rapida consiste nel modificare la versione di .NET framework di destinazione in 4.0. Questo è disponibile su XP, quindi ti verrà mentito di nuovo.

Ovviamente è meglio correggere il codice. Non usare mai le proprietà Size, Width o Height, esse dipenderanno inevitabilmente dalla dimensione del bordo e della didascalia. Usa invece la proprietà ClientSize, quella stabile e quella che ti interessa davvero.Ma fai attenzione anche con quella proprietà, un modulo può ridimensionarsi quando gira su una macchina che ha la sua scheda video impostata su oltre 96 punti per pollice. Un'altra caratteristica che è molto accessibile in Vista e fino. Ridimensionamento modifica proporzionalmente il client in base all'impostazione DPI.

La vera soluzione è utilizzare un campo bool invece che tenga traccia dello stato della finestra. E imposta la proprietà ClientSize in base alla posizione di un controllo che desideri nascondere o rivelare. Così approssimativamente:

private bool enlarged; 

private void button1_Click(object sender, EventArgs e) 
{ 
    enlarged = !enlarged; 
    int width = someControl.Left - 5; 
    if (enlarged) width = someControl.Right + 5; 
    this.ClientSize = new Size(width, this.ClientSize.Height); 
} 

Sostituire someControl in questo codice con il nome dei controlli.