Perché, in WPF, impostiamo un oggetto su Stretch tramite le proprietà di Allineamento invece di Larghezza / Altezza?

Question

Perché, in WPF, impostiamo un oggetto su Stretch tramite le proprietà di Allineamento invece di Larghezza / Altezza?

#1 da (2 voti)

5

In XAML di WPF, possiamo dire a un elemento di riempire il suo contenitore in questo modo:

<Button HorizontalAlignment="Stretch" VerticalAlignment="Stretch" />

Perché quando impostiamo un elemento su Stretch, lo facciamo tramite le proprietà HorizontalAlignment e VerticalAlignment? Perché il team di progettazione WPF ha deciso di adottare questo approccio per avere Width="Stretch" e Height="Stretch" ? Presumo che sia stata una decisione calcolata, e sono curioso del ragionamento.

I CSS, tra le altre tecnologie, seguono la convenzione secondo cui lo stretching viene eseguito tramite le proprietà width e height e quell'allineamento influisce sul posizionamento esclusivamente . Questo sembra abbastanza intuitivo: allungare l'elemento sta manipolando la sua larghezza e altezza, dopo tutto! Usare la corrispondente proprietà di allineamento per allungare un elemento sembra controintuitivo e insolito in confronto. Questo mi fa pensare che non hanno scelto questa opzione senza motivo: hanno preso una decisione calcolata e hanno avuto delle motivazioni.

Larghezza e Altezza usano il doppio tipo di dati, che normalmente significherebbe assegnargli una stringa sarebbe sciocco. Tuttavia, gli oggetti Window di WPF possono assumere Width="Auto" , che viene trattato come double.NaN . Impossibile Width="Stretch" essere memorizzato come double.PositiveInfinity o qualche altro valore?

design wpf xaml

posta doppelgreener 02.07.2013 - 05:53

fonte

1 risposta

Leggi altre domande sui tag design wpf xaml

Come progettare un pattern composito in Python? svn vs git per l'unico sviluppatore? [chiuso]

score 2 · Accepted Answer

Perché double.NaN e double.PositiveInfinity hanno già significati molto specifici. È una pessima pratica rivalutare valori speciali come quello in un contesto completamente diverso, dove avrebbe un significato significativamente diverso. Solo perché un elemento non può essere NaN o PositiveInfinity (o per quanto riguarda -1 ) le unità di larghezza non significano che dovresti riutilizzare quel valore arbitrariamente per significare qualcos'altro. Supponete di aver calcolato il con di un elemento in modo dinamico, NaN o PositiveInfinity rappresenterebbero comunque una divisione per zero e significa che qualcosa non va nel calcolo, non che l'elemento dovrebbe allungarsi.

È vero che WPF ti permette di specificare Width="Auto" che viene memorizzato internamente come NaN , tuttavia direi che questo è davvero un cattivo design (o almeno non un ottimo design - almeno "Auto" non è davvero un numero), per i motivi sopra elencati. Non posso dire perché il team di WPF abbia scelto di concedere un valore speciale, e non l'altro, tranne che forse era semplicemente l'opzione migliore per mantenere i loro algoritmi di layout semplici e flessibili. NaN ha il vantaggio aggiunto che qualsiasi operazione aritmetica eseguita su di essa rimane NaN , mentre molte operazioni su PositiveInfinity danno come risultato NaN . Questo potrebbe rendere NaN più adatto per la memorizzazione di valori speciali di PostitiveInfinity .

Una soluzione molto migliore può essere trovata nella struttura GridLength , che rappresenta misure discrete e valori speciali (come * e auto ) in modo appropriato. I progettisti di WPF potrebbero aver usato una struttura simile per rappresentare la larghezza / altezza di tutti gli elementi del framework, ma questo avrebbe probabilmente reso la maggior parte anche degli algoritmi di layout più elementari molto più difficili.