Quelque chose qui avait été relativement facile à coder était l’exposition des propriétés du code des effets pleine image (dégradés, bruits, etc.) dans un formulaire, de manière automatique ; c’est-à-dire qu’à chaque fois que j’ajoutais une propriété ou un paramètre au code, il s’ajoutait à la page des propriétés automatiquement (Visual Property Page).

Avec WPF, c’est toute une autre histoire : ça ne fonctionne pas de la même façon (parce que WPF est conçu pour afficher des applications sur toutes sortes de plateformes), les éléments visuels ne se placent pas de la même façon, leurs caractéristiques ne sont pas les mêmes, la gestion de leurs événements non plus, etc. Mais j’ai réussi… presque.

Ce petit bout de fonctionnalité est extrêmement important parce que très tôt dans le développement j’étais confronté à la multiplicité des possibilités, au nombre croissant de paramètres que je pouvais modifier dans le code et je voulais trouver un moyen de les rendre accessibles à l’interface sans avoir à coder, recoder ad nauseam.

Le .NET Framework permet au code de s’observer et s’analyser lui-même et on peut attribuer à chaque méthode ou propriété des identifiants additionnels (attributs) qui sont utilisés par le code pour déterminer le modèle de présentation. Comme par exemple dans l’effet Bruit, il y a un paramètre “octave” qui peut prendre une valeur numérique. En ajouter des attributs à ce paramètre, comme par exemple le type de donnée (entier), le type de contrôle visuel (textbox) et les valeurs minimales et maximales permises, le code de génération de la Visual Property Page sait comment faire et comment se connecter au code de l’effet de bruit.

Les couleurs dans l’exemple vidéo ci-dessous n’y sont que pour me permettre de voir comment réagissent les contrôles visuels les uns par rapport aux autres. Ce que j’aime bien c’est leur réorganisation automatique selon l’espace disponible.

* * *

Something that was relatively easy to code was exposing automatically code properties of effects applicable image-wise (gradients, noises, etc.) in a form; that is, every time I added a property or parameter to the code, it added itself to the Visual Property Page.

With WPF, it’s quite another story: it does not work the same way (because WPF is designed to display applications on all kinds of platforms), the visual elements are not positioned in the same way, their properties have different names and behave differently, their events are not managed the same way, etc. But I succeded… almost.

This little bit of functionality is extremely important because very early in the development I was confronted with the multiplicity of possibilities, and with the increasing number of parameters that I could modify in the code I wanted to find a way to make them accessible to the interface without having to code, re-code ad nauseam.

The .NET Framework allows the code to observe and analyze itself, and each method or property can be assigned additional identifiers (attributes) that are used by the code to determine the presentation template, among other things. As for example in the Noise effect, there is an “octave” parameter which can take a numeric value. Adding attributes to this parameter, such as the data type (integer), the type of visual control (textbox) and the minimum and maximum allowed, the generation code of the Visual Property Page knows how to build it and how to connect to the code of the noise effect.

The colors in the video example above are only there to allow me to see how the visual controls react to each other. What I like is their automatic reorganization according to the available space.