Truc simple : j'ai une lib de composants
(System.ComponentModel.Component) qui dérivent tous d'une classe de
base dans la même lib. Situation classique donc.
Tout marche impect, mais quand j'installe la dll, bien entendu la
classe de base est aussi montée dans la palette. Et ça je ne veux pas
car elle est en quelque sorte "abstraite" et ne doit pas apparaitre
dans la palette.
Il doit y avoir un attribut pour commander ça, mais je n'arrive pas à
le trouver..
Donc comment dire dans le code source "cette classe ne doit pas être
installée dans la toolbox" ?
Truc simple : j'ai une lib de composants (System.ComponentModel.Component) qui dérivent tous d'une classe de base dans la même lib. Situation classique donc. Tout marche impect, mais quand j'installe la dll, bien entendu la classe de base est aussi montée dans la palette. Et ça je ne veux pas car elle est en quelque sorte "abstraite" et ne doit pas apparaitre dans la palette.
Il doit y avoir un attribut pour commander ça, mais je n'arrive pas à le trouver..
Donc comment dire dans le code source "cette classe ne doit pas être installée dans la toolbox" ?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcomponentmodeltoolboxitemattributeclassctortopic1.asp
--
Paul Bacelar
"Merlin" <Merlin@LesFees.Net> wrote in message
news:mn.73507d5a3736ceaa.18651@LesFees.Net...
Salut tout le monde,
Truc simple : j'ai une lib de composants
(System.ComponentModel.Component) qui dérivent tous d'une classe de
base dans la même lib. Situation classique donc.
Tout marche impect, mais quand j'installe la dll, bien entendu la
classe de base est aussi montée dans la palette. Et ça je ne veux pas
car elle est en quelque sorte "abstraite" et ne doit pas apparaitre
dans la palette.
Il doit y avoir un attribut pour commander ça, mais je n'arrive pas à
le trouver..
Donc comment dire dans le code source "cette classe ne doit pas être
installée dans la toolbox" ?
Truc simple : j'ai une lib de composants (System.ComponentModel.Component) qui dérivent tous d'une classe de base dans la même lib. Situation classique donc. Tout marche impect, mais quand j'installe la dll, bien entendu la classe de base est aussi montée dans la palette. Et ça je ne veux pas car elle est en quelque sorte "abstraite" et ne doit pas apparaitre dans la palette.
Il doit y avoir un attribut pour commander ça, mais je n'arrive pas à le trouver..
Donc comment dire dans le code source "cette classe ne doit pas être installée dans la toolbox" ?
j'ai déjà lu cette aide... mais je n'arrive pas à voir où se trouve la solution à mon problème (enfin les deux problèmes : cacher un classe d'une dll et fixer la page de toolbox quand on installe des compos dans l'ide)...
Si tu as des exemples plus précis je suis donc preneur..
j'ai déjà lu cette aide... mais je n'arrive pas à voir où se trouve la
solution à mon problème (enfin les deux problèmes : cacher un classe
d'une dll et fixer la page de toolbox quand on installe des compos dans
l'ide)...
Si tu as des exemples plus précis je suis donc preneur..
j'ai déjà lu cette aide... mais je n'arrive pas à voir où se trouve la solution à mon problème (enfin les deux problèmes : cacher un classe d'une dll et fixer la page de toolbox quand on installe des compos dans l'ide)...
Si tu as des exemples plus précis je suis donc preneur..
j'ai déjà lu cette aide... mais je n'arrive pas à voir où se trouve la solution à mon problème (enfin les deux problèmes : cacher un classe d'une dll et fixer la page de toolbox quand on installe des compos dans l'ide)...
Si tu as des exemples plus précis je suis donc preneur..
j'ai déjà lu cette aide... mais je n'arrive pas à voir où se trouve la
solution à mon problème (enfin les deux problèmes : cacher un classe
d'une dll et fixer la page de toolbox quand on installe des compos dans
l'ide)...
Si tu as des exemples plus précis je suis donc preneur..
j'ai déjà lu cette aide... mais je n'arrive pas à voir où se trouve la solution à mon problème (enfin les deux problèmes : cacher un classe d'une dll et fixer la page de toolbox quand on installe des compos dans l'ide)...
Si tu as des exemples plus précis je suis donc preneur..
Je ne comprends pas trop là, ce n'est pas "général" par défaut, c'est l'utilisateur qui choisi.
Justement, pour installer un lib de composants, je ne veux pas que l'utilisateur choisisse... je veux pouvoir répartir mes composants dans des palettes dont le nom est significatif. Le pauvre utilisateur ne peut pas forcément savoir par défaut comment organiser une lib qu'il est en train d'installer donc qu'il ne connait pas bien encore...
Je ne comprends pas trop là, ce n'est pas "général" par défaut, c'est
l'utilisateur qui choisi.
Justement, pour installer un lib de composants, je ne veux pas que
l'utilisateur choisisse... je veux pouvoir répartir mes composants dans
des palettes dont le nom est significatif.
Le pauvre utilisateur ne peut pas forcément savoir par défaut comment
organiser une lib qu'il est en train d'installer donc qu'il ne connait
pas bien encore...
Je ne comprends pas trop là, ce n'est pas "général" par défaut, c'est l'utilisateur qui choisi.
Justement, pour installer un lib de composants, je ne veux pas que l'utilisateur choisisse... je veux pouvoir répartir mes composants dans des palettes dont le nom est significatif. Le pauvre utilisateur ne peut pas forcément savoir par défaut comment organiser une lib qu'il est en train d'installer donc qu'il ne connait pas bien encore...
Ne le prends pas pour un crétin non plus. -- Paul Bacelar
"Merlin" wrote in message news:
Paul Bacelar a écrit : > Je ne comprends pas trop là, ce n'est pas "général" par défaut, c'est > l'utilisateur qui choisi.
Justement, pour installer un lib de composants, je ne veux pas que l'utilisateur choisisse... je veux pouvoir répartir mes composants dans des palettes dont le nom est significatif. Le pauvre utilisateur ne peut pas forcément savoir par défaut comment organiser une lib qu'il est en train d'installer donc qu'il ne connait pas bien encore...
Ne le prends pas pour un crétin non plus.
--
Paul Bacelar
"Merlin" <Merlin@LesFees.Net> wrote in message
news:mn.901e7d5abec6856b.18651@LesFees.Net...
Paul Bacelar a écrit :
> Je ne comprends pas trop là, ce n'est pas "général" par défaut, c'est
> l'utilisateur qui choisi.
Justement, pour installer un lib de composants, je ne veux pas que
l'utilisateur choisisse... je veux pouvoir répartir mes composants dans
des palettes dont le nom est significatif.
Le pauvre utilisateur ne peut pas forcément savoir par défaut comment
organiser une lib qu'il est en train d'installer donc qu'il ne connait
pas bien encore...
Ne le prends pas pour un crétin non plus. -- Paul Bacelar
"Merlin" wrote in message news:
Paul Bacelar a écrit : > Je ne comprends pas trop là, ce n'est pas "général" par défaut, c'est > l'utilisateur qui choisi.
Justement, pour installer un lib de composants, je ne veux pas que l'utilisateur choisisse... je veux pouvoir répartir mes composants dans des palettes dont le nom est significatif. Le pauvre utilisateur ne peut pas forcément savoir par défaut comment organiser une lib qu'il est en train d'installer donc qu'il ne connait pas bien encore...
Certes pas, mais je créé des lib de compos assez grosses et répartir plusieurs dizaines de classes sur plusieurs tabs quand tu ne connais pas encore la lib, et d'une c'est super chiant à faire (et un bon produit doit être simple à installer) et de deux c'est vraiment pas évident si tu ne connais pas exactement le rôle de chaque classe. De fait, que la répartition dans les tabs soit fixée dans la lib de composants me semble un minimum.
D'ailleurs sous .NET c'est bien dans le code du composant que tu indiques par un attribut dans quelle catégorie une propriété va apparaître. On pourrait dire aussi que l'utilisateur peut le faire à la main... mais ça ne serait ni évident (pas toujours simple d'attribuer une catégorie) et super chiant (vu le nombre de propriétés). Donc, dans .NET c'est prévu de pouvoir fixer ça dans la classe. Ce que je trouve très étrange c'est que les gars se soient arrêter avant la fin du raisonnement : il faut pouvoir faire pareil pour les classes elles-mêmes vis à vis des tabs du toolbox.
D'ailleurs, si tu connais un EDI comme Delphi, c'est par le truchement d'une méthode "Register" qui , si elle est présente dans la lib, que l'enregistrement des classes se fait. Et quand on enregistre un composant, on peut bien entendu choisir la palette. le user peut changer les compos de palette après coup si àa le chante, mais par défaut tu lui proposes un organisation.
Voila. Je cherche juste à avoir des libs propres qui s'installent sans prise de tête pour le user qui n'est pas un crétin, mais qui est un client qui aime que ça soit simple :-)
Certes pas, mais je créé des lib de compos assez grosses et répartir
plusieurs dizaines de classes sur plusieurs tabs quand tu ne connais
pas encore la lib, et d'une c'est super chiant à faire (et un bon
produit doit être simple à installer) et de deux c'est vraiment pas
évident si tu ne connais pas exactement le rôle de chaque classe.
De fait, que la répartition dans les tabs soit fixée dans la lib de
composants me semble un minimum.
D'ailleurs sous .NET c'est bien dans le code du composant que tu
indiques par un attribut dans quelle catégorie une propriété va
apparaître. On pourrait dire aussi que l'utilisateur peut le faire à la
main... mais ça ne serait ni évident (pas toujours simple d'attribuer
une catégorie) et super chiant (vu le nombre de propriétés).
Donc, dans .NET c'est prévu de pouvoir fixer ça dans la classe.
Ce que je trouve très étrange c'est que les gars se soient arrêter
avant la fin du raisonnement : il faut pouvoir faire pareil pour les
classes elles-mêmes vis à vis des tabs du toolbox.
D'ailleurs, si tu connais un EDI comme Delphi, c'est par le truchement
d'une méthode "Register" qui , si elle est présente dans la lib, que
l'enregistrement des classes se fait. Et quand on enregistre un
composant, on peut bien entendu choisir la palette. le user peut
changer les compos de palette après coup si àa le chante, mais par
défaut tu lui proposes un organisation.
Voila. Je cherche juste à avoir des libs propres qui s'installent sans
prise de tête pour le user qui n'est pas un crétin, mais qui est un
client qui aime que ça soit simple :-)
Certes pas, mais je créé des lib de compos assez grosses et répartir plusieurs dizaines de classes sur plusieurs tabs quand tu ne connais pas encore la lib, et d'une c'est super chiant à faire (et un bon produit doit être simple à installer) et de deux c'est vraiment pas évident si tu ne connais pas exactement le rôle de chaque classe. De fait, que la répartition dans les tabs soit fixée dans la lib de composants me semble un minimum.
D'ailleurs sous .NET c'est bien dans le code du composant que tu indiques par un attribut dans quelle catégorie une propriété va apparaître. On pourrait dire aussi que l'utilisateur peut le faire à la main... mais ça ne serait ni évident (pas toujours simple d'attribuer une catégorie) et super chiant (vu le nombre de propriétés). Donc, dans .NET c'est prévu de pouvoir fixer ça dans la classe. Ce que je trouve très étrange c'est que les gars se soient arrêter avant la fin du raisonnement : il faut pouvoir faire pareil pour les classes elles-mêmes vis à vis des tabs du toolbox.
D'ailleurs, si tu connais un EDI comme Delphi, c'est par le truchement d'une méthode "Register" qui , si elle est présente dans la lib, que l'enregistrement des classes se fait. Et quand on enregistre un composant, on peut bien entendu choisir la palette. le user peut changer les compos de palette après coup si àa le chante, mais par défaut tu lui proposes un organisation.
Voila. Je cherche juste à avoir des libs propres qui s'installent sans prise de tête pour le user qui n'est pas un crétin, mais qui est un client qui aime que ça soit simple :-)
Paul Bacelar a écrit : > Ne le prends pas pour un crétin non plus.
Certes pas, mais je créé des lib de compos assez grosses et répartir plusieurs dizaines de classes sur plusieurs tabs quand tu ne connais pas encore la lib, et d'une c'est super chiant à faire (et un bon produit doit être simple à installer) et de deux c'est vraiment pas évident si tu ne connais pas exactement le rôle de chaque classe. De fait, que la répartition dans les tabs soit fixée dans la lib de composants me semble un minimum.
D'ailleurs sous .NET c'est bien dans le code du composant que tu indiques par un attribut dans quelle catégorie une propriété va apparaître. On pourrait dire aussi que l'utilisateur peut le faire à la main... mais ça ne serait ni évident (pas toujours simple d'attribuer une catégorie) et super chiant (vu le nombre de propriétés). Donc, dans .NET c'est prévu de pouvoir fixer ça dans la classe. Ce que je trouve très étrange c'est que les gars se soient arrêter avant la fin du raisonnement : il faut pouvoir faire pareil pour les classes elles-mêmes vis à vis des tabs du toolbox.
D'ailleurs, si tu connais un EDI comme Delphi, c'est par le truchement d'une méthode "Register" qui , si elle est présente dans la lib, que l'enregistrement des classes se fait. Et quand on enregistre un composant, on peut bien entendu choisir la palette. le user peut changer les compos de palette après coup si àa le chante, mais par défaut tu lui proposes un organisation.
Voila. Je cherche juste à avoir des libs propres qui s'installent sans prise de tête pour le user qui n'est pas un crétin, mais qui est un client qui aime que ça soit simple :-)
Le plus simple serait de customiser VS à l'installation de vos composants.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vxconcontrollingtoolbox.asp
--
Paul Bacelar
"Merlin" <Merlin@LesFees.Net> wrote in message
news:mn.935c7d5a90d5c3dc.18651@LesFees.Net...
Paul Bacelar a écrit :
> Ne le prends pas pour un crétin non plus.
Certes pas, mais je créé des lib de compos assez grosses et répartir
plusieurs dizaines de classes sur plusieurs tabs quand tu ne connais
pas encore la lib, et d'une c'est super chiant à faire (et un bon
produit doit être simple à installer) et de deux c'est vraiment pas
évident si tu ne connais pas exactement le rôle de chaque classe.
De fait, que la répartition dans les tabs soit fixée dans la lib de
composants me semble un minimum.
D'ailleurs sous .NET c'est bien dans le code du composant que tu
indiques par un attribut dans quelle catégorie une propriété va
apparaître. On pourrait dire aussi que l'utilisateur peut le faire à la
main... mais ça ne serait ni évident (pas toujours simple d'attribuer
une catégorie) et super chiant (vu le nombre de propriétés).
Donc, dans .NET c'est prévu de pouvoir fixer ça dans la classe.
Ce que je trouve très étrange c'est que les gars se soient arrêter
avant la fin du raisonnement : il faut pouvoir faire pareil pour les
classes elles-mêmes vis à vis des tabs du toolbox.
D'ailleurs, si tu connais un EDI comme Delphi, c'est par le truchement
d'une méthode "Register" qui , si elle est présente dans la lib, que
l'enregistrement des classes se fait. Et quand on enregistre un
composant, on peut bien entendu choisir la palette. le user peut
changer les compos de palette après coup si àa le chante, mais par
défaut tu lui proposes un organisation.
Voila. Je cherche juste à avoir des libs propres qui s'installent sans
prise de tête pour le user qui n'est pas un crétin, mais qui est un
client qui aime que ça soit simple :-)
Paul Bacelar a écrit : > Ne le prends pas pour un crétin non plus.
Certes pas, mais je créé des lib de compos assez grosses et répartir plusieurs dizaines de classes sur plusieurs tabs quand tu ne connais pas encore la lib, et d'une c'est super chiant à faire (et un bon produit doit être simple à installer) et de deux c'est vraiment pas évident si tu ne connais pas exactement le rôle de chaque classe. De fait, que la répartition dans les tabs soit fixée dans la lib de composants me semble un minimum.
D'ailleurs sous .NET c'est bien dans le code du composant que tu indiques par un attribut dans quelle catégorie une propriété va apparaître. On pourrait dire aussi que l'utilisateur peut le faire à la main... mais ça ne serait ni évident (pas toujours simple d'attribuer une catégorie) et super chiant (vu le nombre de propriétés). Donc, dans .NET c'est prévu de pouvoir fixer ça dans la classe. Ce que je trouve très étrange c'est que les gars se soient arrêter avant la fin du raisonnement : il faut pouvoir faire pareil pour les classes elles-mêmes vis à vis des tabs du toolbox.
D'ailleurs, si tu connais un EDI comme Delphi, c'est par le truchement d'une méthode "Register" qui , si elle est présente dans la lib, que l'enregistrement des classes se fait. Et quand on enregistre un composant, on peut bien entendu choisir la palette. le user peut changer les compos de palette après coup si àa le chante, mais par défaut tu lui proposes un organisation.
Voila. Je cherche juste à avoir des libs propres qui s'installent sans prise de tête pour le user qui n'est pas un crétin, mais qui est un client qui aime que ça soit simple :-)