Discussion :

[ctxnop]

Bonjour.
J'ai un souci avec le Designer de Visual Studio.
J'utilise beaucoup les composants de DevExpress et beaucoup d'entre eux, comme par exemple les XtraTreeList demandent impérativement des ImageList comme source d'image au lieu de permettre de définir directement l'image. Cependant, dans mon projet, j'ai écrit un gestionnaire de ressource qui gère les images de facon complètement différente :
- Un singleton, accessible par tout le AppDomain
- Il lit des fichiers .resources ou des assembly .dll pour en extraire les ressources.
- il index les ressources selon une norme que j'ai définit, tous les fichiers luts sont à la bonne norme.
- Ensuite on peux obtenir une image soit par son index, soit par un identifiant non unique. L'identifiant n'est pas unique pour gérer un simple cas : les images identiques mais disponibles en plusieur taille selon où elle doivent être affichée.
Tout ceci fonctionne parfaitement tant qu'on peux définir directement l'image. Mais dans le cas des ImageList c'est la misère.
Le composant System.Windows.Forms.ImageList est sealed, donc impossible à dériver.
DevExpress fournit un composant quasi identique, ImageCollection. Cependant toutes les méthodes utiles à l'obtention des images sont protégée ou non surchargeables ....

Je dispose des sources de DevExpress, je peux donc les modifier à souhait, cependant, quand je le fait, le composant n'apparait plus ensuite comme choix de source d'image dans le designer de Visual Studio .

Je cherche donc un moyen pour qu'un composant, surchargé ou entierement écrit par moi, peu m'importe, soit listé comme source d'image des propriétés ImageList des autres composants, au même titre que les ImageList et les ImageCollection. Quelqu'un à une idée ?

Merci d'avance de votre aide

[theMonz31]

salut

question bete : Pourquoi ne pas créer une ImageList et l'alimenter avec ton système de gestion d'image ?

Après tout, ton imageList est juste un contain d'image qui va être utilisé par des controles de ton application. JE ne vois pas en quoi cela pourrait etre genant que tu es une méthode qui s'appuie sur ton dev d'image ressource pour alimenter cette image List au début de l'application par exemple

[ctxnop]

Pour 2/3 raisons :
- le gestionnaire de ressource gère l'accès à plus de 20 000 images, les ImageList ne stockent pas des références à l'image mais l'image elle-même. Donc pour que toutes mes images soient accessibles il faudrait toutes les charger et les copier dans l'ImageList ce qui ferait prendre plus de 600Mo au process, je doute que ce soit acceptable. De plus, il faut multiplier ce poid par le nombre d'ImageList à être instanciés, et y'en a quelques un...

- les ressources sont indexée par plage afin de permettre une catégorisation et des ajouts futurs. Ce qui fait qu'il y a des "trous" dans les indexes, ce que n'accepte pas l'ImageList.

- les ressources, au sein du logiciel, sont identifiées par une chaine de texte (l'identifiant non unique dont je parlais), les index numériques uniques sont déterminé par mappage avec une base de donnée. Ce qui fait que, par exemple dans la TreeList, lorsqu'elle est remplit, la source de donnée qui la remplit me donne une chaine de texte et non un identifiant numérique comme demandé.

- je ne vois aucun moyen de faire intervenir mon gestionnaire de ressource dans le processus d'affichage des images issues de l'ImageList.

- Le gestionnaire de ressource à besoin d'accèder à la base de données pour savoir quel fichier charger pour obtenir une ressource.

- EDIT : Un autre problème, les ImageList imposent une taille prédéfinit, mais mon gestionnaire de ressource lui en fournit une multitude et n'a d'ailleur pas réelle connaissance des tailles des images

[ctxnop]

Il semblerait que ce que je cherche a faire n'est pas vraiment possible. En faite, les composants DevExpress supportent des ImageList et des ImageCollections, mais les composants de bases ne supportent que des ImageList, il n'y a donc aucun héritage comme je le pensait au début.
J'ai écrit à DevExpress pour leurs demander de passer certaines méthodes/propriétés en virtual histoire qu'on puisse les surcharger mais même s'il le font ca ne se fera pas demain.
En attendant, je vais passer par une solution assez lourde : surcharger tous les composants DevExpress qu'on utilise avec des ImageList, afin de modifier les fonctions d'obtention des index dans ces ImageList. Ces fonctions sont surchargeables elles. Mais bon, ca signifie surcharger une 10aines de composant et passer dans tout le logiciels pour modifier les types de tous les composant par les nouveaux ....
Pourquoi les gens s'obstinent a faire des composant non dérivable ?! Sérieusement, si on dérive n'importe comment c'est notre problème, mais laissez nous la possibilité de le faire !

[ctxnop]

J'ai des news ! Sont très sympas chez DevExpress, ils vont me faire une version rien pour moi en ajoutant un ou deux virtual sur les propriétés que je voulais surcharger