Bonjour,
J'ai un problème de taille avec le designer d'interface du C#.
J'ai une application composée des éléments suivants:
L'interface en C#, c'est le programme principal.
Une assembly .NET en C++ manage
Une DLL Win32 qui est utilisée par l'assembly .NET.
Ma partie C# comporte plusieurs users controls.
Ces user controls accèdent à des méthodes placés dans l'assembly en C++
Manage.
Le problème est le suivant:
Quand je fait un clean sur la solution, ou que le build de mon assembly C++
Manage se passe mal, le designer d'interface echoue à initialiser les users
controls qui sont intégrés dans mes forms ( vu que généralement les
constructeurs de mes users controls C# utilisent des objects définis dans
mon assembly C++ manage qui n'existent plus.. ), et prend carrément
l'initiative de détuire tous les appels aux contructeurs de toutes les
instance de ces users controls. En clair, mes windows forms se vident de
leurs users controls, le code est tout simplement détruit par le designer
d'interface.
C'est particulièrement pénible.
A chaque clean de solution, quasiement toute mon interface est détruite.
Est est possible d'indiquer a l'interface builder qu'il ne doit pas détruire
les appels aux constructeurs des users controls ?, même si ils référencent
des classes contenues dans une assembly externe et qui ne sont pas
disponibles à un instant t, pour une raison ou une autre?.
Toute aide sera sincèrement la bienvenue.
Cordialement,
David Alloza.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Guillaume Davion
Ou se trouvent les appels à tes constructeurs? Si ils sont dans la section Designer generated code, il va systématiquement t'embeter à mon avis... Il faudrait que tu tente de les mettres ailleurs, si c'est possible
Ou se trouvent les appels à tes constructeurs? Si ils sont dans la
section Designer generated code, il va systématiquement t'embeter à
mon avis... Il faudrait que tu tente de les mettres ailleurs, si c'est
possible
Ou se trouvent les appels à tes constructeurs? Si ils sont dans la section Designer generated code, il va systématiquement t'embeter à mon avis... Il faudrait que tu tente de les mettres ailleurs, si c'est possible
David Alloza
ils sont effectivement dans cette section.. vu qu'il sont générés par le designer d'interface. C'est d'ailleur un des principaux intérets des users controls, celui de s'intégrer totalement au designer d'interface. Donc de ce coté la.. je ne peut pas changer grand chose.
"Guillaume Davion" a écrit dans le message de news:
Ou se trouvent les appels à tes constructeurs? Si ils sont dans la section Designer generated code, il va systématiquement t'embeter à mon avis... Il faudrait que tu tente de les mettres ailleurs, si c'est possible
ils sont effectivement dans cette section.. vu qu'il sont générés par le
designer d'interface.
C'est d'ailleur un des principaux intérets des users controls, celui de
s'intégrer totalement au designer d'interface.
Donc de ce coté la.. je ne peut pas changer grand chose.
"Guillaume Davion" <marnheus@gmail.com> a écrit dans le message de news:
1112186625.669309.5040@f14g2000cwb.googlegroups.com...
Ou se trouvent les appels à tes constructeurs? Si ils sont dans la
section Designer generated code, il va systématiquement t'embeter à
mon avis... Il faudrait que tu tente de les mettres ailleurs, si c'est
possible
ils sont effectivement dans cette section.. vu qu'il sont générés par le designer d'interface. C'est d'ailleur un des principaux intérets des users controls, celui de s'intégrer totalement au designer d'interface. Donc de ce coté la.. je ne peut pas changer grand chose.
"Guillaume Davion" a écrit dans le message de news:
Ou se trouvent les appels à tes constructeurs? Si ils sont dans la section Designer generated code, il va systématiquement t'embeter à mon avis... Il faudrait que tu tente de les mettres ailleurs, si c'est possible
David Alloza
Bon, j'ai trouvé une solution temporaire mais satisfaisante. J'ai supprimé dans les constructeurs de mes users controls toutes les références vers des objects définis dans des assembly externes. Ainsi, même si ces assemblies ne sont pas valides, le constructeur par defaut du users controls s'execute correctement sous le designer d'interface, et mes instances d'objets ne sont pas éliminées. Si vous avez une autre solution. Cordialement, David Alloza.
"David Alloza" a écrit dans le message de news:
Bonjour, J'ai un problème de taille avec le designer d'interface du C#. J'ai une application composée des éléments suivants: L'interface en C#, c'est le programme principal. Une assembly .NET en C++ manage Une DLL Win32 qui est utilisée par l'assembly .NET.
Ma partie C# comporte plusieurs users controls. Ces user controls accèdent à des méthodes placés dans l'assembly en C++ Manage.
Le problème est le suivant: Quand je fait un clean sur la solution, ou que le build de mon assembly C++ Manage se passe mal, le designer d'interface echoue à initialiser les users controls qui sont intégrés dans mes forms ( vu que généralement les constructeurs de mes users controls C# utilisent des objects définis dans mon assembly C++ manage qui n'existent plus.. ), et prend carrément l'initiative de détuire tous les appels aux contructeurs de toutes les instance de ces users controls. En clair, mes windows forms se vident de leurs users controls, le code est tout simplement détruit par le designer d'interface.
C'est particulièrement pénible.
A chaque clean de solution, quasiement toute mon interface est détruite.
Est est possible d'indiquer a l'interface builder qu'il ne doit pas détruire les appels aux constructeurs des users controls ?, même si ils référencent des classes contenues dans une assembly externe et qui ne sont pas disponibles à un instant t, pour une raison ou une autre?.
Toute aide sera sincèrement la bienvenue. Cordialement, David Alloza.
Bon, j'ai trouvé une solution temporaire mais satisfaisante.
J'ai supprimé dans les constructeurs de mes users controls toutes les
références vers des objects définis dans des assembly externes.
Ainsi, même si ces assemblies ne sont pas valides, le constructeur par
defaut du users controls s'execute correctement sous le designer
d'interface, et mes instances d'objets ne sont pas éliminées.
Si vous avez une autre solution.
Cordialement,
David Alloza.
"David Alloza" <dalloza_PAS_DE_SPAM_@edengames.com> a écrit dans le message
de news: uSENiCSNFHA.4052@TK2MSFTNGP12.phx.gbl...
Bonjour,
J'ai un problème de taille avec le designer d'interface du C#.
J'ai une application composée des éléments suivants:
L'interface en C#, c'est le programme principal.
Une assembly .NET en C++ manage
Une DLL Win32 qui est utilisée par l'assembly .NET.
Ma partie C# comporte plusieurs users controls.
Ces user controls accèdent à des méthodes placés dans l'assembly en C++
Manage.
Le problème est le suivant:
Quand je fait un clean sur la solution, ou que le build de mon assembly
C++ Manage se passe mal, le designer d'interface echoue à initialiser les
users controls qui sont intégrés dans mes forms ( vu que généralement les
constructeurs de mes users controls C# utilisent des objects définis dans
mon assembly C++ manage qui n'existent plus.. ), et prend carrément
l'initiative de détuire tous les appels aux contructeurs de toutes les
instance de ces users controls. En clair, mes windows forms se vident de
leurs users controls, le code est tout simplement détruit par le designer
d'interface.
C'est particulièrement pénible.
A chaque clean de solution, quasiement toute mon interface est détruite.
Est est possible d'indiquer a l'interface builder qu'il ne doit pas
détruire les appels aux constructeurs des users controls ?, même si ils
référencent des classes contenues dans une assembly externe et qui ne sont
pas disponibles à un instant t, pour une raison ou une autre?.
Toute aide sera sincèrement la bienvenue.
Cordialement,
David Alloza.
Bon, j'ai trouvé une solution temporaire mais satisfaisante. J'ai supprimé dans les constructeurs de mes users controls toutes les références vers des objects définis dans des assembly externes. Ainsi, même si ces assemblies ne sont pas valides, le constructeur par defaut du users controls s'execute correctement sous le designer d'interface, et mes instances d'objets ne sont pas éliminées. Si vous avez une autre solution. Cordialement, David Alloza.
"David Alloza" a écrit dans le message de news:
Bonjour, J'ai un problème de taille avec le designer d'interface du C#. J'ai une application composée des éléments suivants: L'interface en C#, c'est le programme principal. Une assembly .NET en C++ manage Une DLL Win32 qui est utilisée par l'assembly .NET.
Ma partie C# comporte plusieurs users controls. Ces user controls accèdent à des méthodes placés dans l'assembly en C++ Manage.
Le problème est le suivant: Quand je fait un clean sur la solution, ou que le build de mon assembly C++ Manage se passe mal, le designer d'interface echoue à initialiser les users controls qui sont intégrés dans mes forms ( vu que généralement les constructeurs de mes users controls C# utilisent des objects définis dans mon assembly C++ manage qui n'existent plus.. ), et prend carrément l'initiative de détuire tous les appels aux contructeurs de toutes les instance de ces users controls. En clair, mes windows forms se vident de leurs users controls, le code est tout simplement détruit par le designer d'interface.
C'est particulièrement pénible.
A chaque clean de solution, quasiement toute mon interface est détruite.
Est est possible d'indiquer a l'interface builder qu'il ne doit pas détruire les appels aux constructeurs des users controls ?, même si ils référencent des classes contenues dans une assembly externe et qui ne sont pas disponibles à un instant t, pour une raison ou une autre?.
Toute aide sera sincèrement la bienvenue. Cordialement, David Alloza.
Paul Bacelar
Ne pas référencer l'assembly des contrôles dans le répertoire de sortie de son projet mais référencer une copie de cette dll ou utiliser une version dans le GAC, si le projet qui génère l'assembly ne l'enregistre pas dans le GAC.
-- Paul Bacelar
"David Alloza" wrote in message news:
Bon, j'ai trouvé une solution temporaire mais satisfaisante. J'ai supprimé dans les constructeurs de mes users controls toutes les références vers des objects définis dans des assembly externes. Ainsi, même si ces assemblies ne sont pas valides, le constructeur par defaut du users controls s'execute correctement sous le designer d'interface, et mes instances d'objets ne sont pas éliminées. Si vous avez une autre solution. Cordialement, David Alloza.
"David Alloza" a écrit dans le
message
de news: > Bonjour, > J'ai un problème de taille avec le designer d'interface du C#. > J'ai une application composée des éléments suivants: > L'interface en C#, c'est le programme principal. > Une assembly .NET en C++ manage > Une DLL Win32 qui est utilisée par l'assembly .NET. > > Ma partie C# comporte plusieurs users controls. > Ces user controls accèdent à des méthodes placés dans l'assembly en C++ > Manage. > > Le problème est le suivant: > Quand je fait un clean sur la solution, ou que le build de mon assembly > C++ Manage se passe mal, le designer d'interface echoue à initialiser
les
> users controls qui sont intégrés dans mes forms ( vu que généralement
les
> constructeurs de mes users controls C# utilisent des objects définis
dans
> mon assembly C++ manage qui n'existent plus.. ), et prend carrément > l'initiative de détuire tous les appels aux contructeurs de toutes les > instance de ces users controls. En clair, mes windows forms se vident de > leurs users controls, le code est tout simplement détruit par le
designer
> d'interface. > > C'est particulièrement pénible. > > A chaque clean de solution, quasiement toute mon interface est détruite. > > Est est possible d'indiquer a l'interface builder qu'il ne doit pas > détruire les appels aux constructeurs des users controls ?, même si ils > référencent des classes contenues dans une assembly externe et qui ne
sont
> pas disponibles à un instant t, pour une raison ou une autre?. > > Toute aide sera sincèrement la bienvenue. > Cordialement, > David Alloza. > >
Ne pas référencer l'assembly des contrôles dans le répertoire de sortie de
son projet mais référencer une copie de cette dll ou utiliser une version
dans le GAC, si le projet qui génère l'assembly ne l'enregistre pas dans le
GAC.
--
Paul Bacelar
"David Alloza" <dalloza_PAS_DE_SPAM_@edengames.com> wrote in message
news:eLo59lSNFHA.1308@TK2MSFTNGP15.phx.gbl...
Bon, j'ai trouvé une solution temporaire mais satisfaisante.
J'ai supprimé dans les constructeurs de mes users controls toutes les
références vers des objects définis dans des assembly externes.
Ainsi, même si ces assemblies ne sont pas valides, le constructeur par
defaut du users controls s'execute correctement sous le designer
d'interface, et mes instances d'objets ne sont pas éliminées.
Si vous avez une autre solution.
Cordialement,
David Alloza.
"David Alloza" <dalloza_PAS_DE_SPAM_@edengames.com> a écrit dans le
message
de news: uSENiCSNFHA.4052@TK2MSFTNGP12.phx.gbl...
> Bonjour,
> J'ai un problème de taille avec le designer d'interface du C#.
> J'ai une application composée des éléments suivants:
> L'interface en C#, c'est le programme principal.
> Une assembly .NET en C++ manage
> Une DLL Win32 qui est utilisée par l'assembly .NET.
>
> Ma partie C# comporte plusieurs users controls.
> Ces user controls accèdent à des méthodes placés dans l'assembly en C++
> Manage.
>
> Le problème est le suivant:
> Quand je fait un clean sur la solution, ou que le build de mon assembly
> C++ Manage se passe mal, le designer d'interface echoue à initialiser
les
> users controls qui sont intégrés dans mes forms ( vu que généralement
les
> constructeurs de mes users controls C# utilisent des objects définis
dans
> mon assembly C++ manage qui n'existent plus.. ), et prend carrément
> l'initiative de détuire tous les appels aux contructeurs de toutes les
> instance de ces users controls. En clair, mes windows forms se vident de
> leurs users controls, le code est tout simplement détruit par le
designer
> d'interface.
>
> C'est particulièrement pénible.
>
> A chaque clean de solution, quasiement toute mon interface est détruite.
>
> Est est possible d'indiquer a l'interface builder qu'il ne doit pas
> détruire les appels aux constructeurs des users controls ?, même si ils
> référencent des classes contenues dans une assembly externe et qui ne
sont
> pas disponibles à un instant t, pour une raison ou une autre?.
>
> Toute aide sera sincèrement la bienvenue.
> Cordialement,
> David Alloza.
>
>
Ne pas référencer l'assembly des contrôles dans le répertoire de sortie de son projet mais référencer une copie de cette dll ou utiliser une version dans le GAC, si le projet qui génère l'assembly ne l'enregistre pas dans le GAC.
-- Paul Bacelar
"David Alloza" wrote in message news:
Bon, j'ai trouvé une solution temporaire mais satisfaisante. J'ai supprimé dans les constructeurs de mes users controls toutes les références vers des objects définis dans des assembly externes. Ainsi, même si ces assemblies ne sont pas valides, le constructeur par defaut du users controls s'execute correctement sous le designer d'interface, et mes instances d'objets ne sont pas éliminées. Si vous avez une autre solution. Cordialement, David Alloza.
"David Alloza" a écrit dans le
message
de news: > Bonjour, > J'ai un problème de taille avec le designer d'interface du C#. > J'ai une application composée des éléments suivants: > L'interface en C#, c'est le programme principal. > Une assembly .NET en C++ manage > Une DLL Win32 qui est utilisée par l'assembly .NET. > > Ma partie C# comporte plusieurs users controls. > Ces user controls accèdent à des méthodes placés dans l'assembly en C++ > Manage. > > Le problème est le suivant: > Quand je fait un clean sur la solution, ou que le build de mon assembly > C++ Manage se passe mal, le designer d'interface echoue à initialiser
les
> users controls qui sont intégrés dans mes forms ( vu que généralement
les
> constructeurs de mes users controls C# utilisent des objects définis
dans
> mon assembly C++ manage qui n'existent plus.. ), et prend carrément > l'initiative de détuire tous les appels aux contructeurs de toutes les > instance de ces users controls. En clair, mes windows forms se vident de > leurs users controls, le code est tout simplement détruit par le
designer
> d'interface. > > C'est particulièrement pénible. > > A chaque clean de solution, quasiement toute mon interface est détruite. > > Est est possible d'indiquer a l'interface builder qu'il ne doit pas > détruire les appels aux constructeurs des users controls ?, même si ils > référencent des classes contenues dans une assembly externe et qui ne
sont
> pas disponibles à un instant t, pour une raison ou une autre?. > > Toute aide sera sincèrement la bienvenue. > Cordialement, > David Alloza. > >
