Por que, no WPF, definimos um objeto como Stretch através de suas propriedades Alignment em vez de Width / Height?

5

No XAML do WPF, podemos dizer a um elemento para preencher seu contêiner da seguinte forma:

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

Por que quando definimos um elemento para o Stretch, fazemos isso através das propriedades HorizontalAlignment e VerticalAlignment? Por que a equipe de design do WPF decidiu adotar essa abordagem por ter Width="Stretch" e Height="Stretch" ? Eu presumo que foi uma decisão calculada, e estou curioso sobre o raciocínio.

CSS, entre outras tecnologias, segue a convenção de que o alongamento é feito através das propriedades width e height, e que o alinhamento afeta o posicionamento exclusivamente . Isso parece bastante intuitivo: alongar o elemento está manipulando sua largura e altura, afinal! Usando a propriedade de alinhamento correspondente para esticar um elemento parece contra-intuitivo e incomum em comparação. Isso me faz pensar que eles não escolheram essa opção sem motivo: eles tomaram uma decisão calculada e tiveram razões por trás disso.

Largura e Altura usam o tipo de dado duplo, o que normalmente significa atribuir a ele uma string seria bobo. No entanto, os objetos Window do WPF podem usar Width="Auto" , que é tratado como double.NaN . Não foi possível% Width="Stretch" ser armazenado como double.PositiveInfinity ou algum outro valor?

    
por doppelgreener 02.07.2013 / 05:53
fonte

1 resposta

2

Porque double.NaN e double.PositiveInfinity já têm significados muito específicos. É uma prática muito ruim redirecionar valores especiais como esse em um contexto completamente diferente, onde teria significados significativamente diferentes. Só porque um elemento não pode ser NaN ou PositiveInfinity (ou mesmo quanto -1 ) unidades de largura não significa que você deve reutilizar esse valor arbitrariamente para significar outra coisa. Suponha que você calculou o com de um elemento dinamicamente, NaN ou PositiveInfinity ainda representaria uma divisão por zero e significa que algo está errado com o cálculo, e não que esse elemento deve ser estendido.

É verdade que o WPF permite que você especifique Width="Auto" que é armazenado internamente como NaN , mas eu diria que isso é de fato um design ruim (ou pelo menos não muito bom design - pelo menos "Auto" não é de fato um número), pelas razões listadas acima. Não posso dizer por que a equipe do WPF optou por permitir um valor especial, e não o outro, exceto que talvez fosse simplesmente a melhor opção para manter seus algoritmos de layout simples e flexíveis. NaN tem o benefício adicional de que quaisquer operações aritméticas executadas nela permanecem NaN , enquanto muitas operações em PositiveInfinity resultam em NaN . Isso pode tornar NaN mais adequado para armazenar valores especiais do que PostitiveInfinity .

Uma solução muito melhor pode ser encontrada na estrutura GridLength , que representa medidas discretas e valores especiais (como * e auto ) apropriadamente. Os designers do WPF poderiam ter usado uma estrutura semelhante para representar a largura / altura de todos os elementos da estrutura, mas isso provavelmente teria tornado a maioria dos algoritmos de layout mais básicos muito mais difíceis.

    
por 02.07.2013 / 06:26
fonte

Tags