Discussion :

[parabole33]

bonjour ,

Je suis débutant en Visual . Je doit basculer mes anciens codes Borland RAID en Visual . ( pas le choix ..... )

J'ai un problème sur les déclarations de class personnelles en Visual . En Borland , on déclare une class par : ex :: test Test ;

dans les déclarations de variables globales en tête de cpp .

en visual ca plante . Il faut intancier une class dans une fonction ?

Bizarre ...

Dans ce cas , pour un projet CLI WinForm , ou je déclare cette class ?

Merci beaucoup pour les infos

[parabole33]

Pour les class j'ai trouvé tout seul comme un grand .......

[bacelar]

Un projet C++/CLI Winform est un projet utilisant le Framework .NET.

Comme il n' y pas de séparation entre la déclaration et la définition, les fichiers utilisés sont des .h. La déclaration est construite par le compilateur par déduction des sources.

Si vous ne connaissez pas .NET, je vous conseil de vérifier si un autre framework graphique C++ comme MFC ou Qt ne serait pas plus pertinent.

[parabole33]

Un projet C++/CLI Winform est un projet utilisant le Framework .NET.

Comme il n' y pas de séparation entre la déclaration et la définition, les fichiers utilisés sont des .h. La déclaration est construite par le compilateur par déduction des sources.

Si vous ne connaissez pas .NET, je vous conseil de vérifier si un autre framework graphique C++ comme MFC ou Qt ne serait pas plus pertinent.

J'ai fait une simple erreur . Je voulais un projet Win32 Natif ( visual Express ) et non FrameWork CLI. J'en ai assez vu en C# ....

Je cherchai un EDI en gratuit avec un assistant pour les contrôles ... Natif windows . Visual Expres pas possible .... La même chose que Borland C++ RAID mais en gratuit .

J'ai ragardé DEV C++ . La prise en main est assez compliquée . Alors j'oublie . Dommage ...

Alors obligé de faire du Win32 et de coller à la main la création de tous les contrôles et tout le reste ..... Dur dur ....


merci !

[moldavi]

Bonjour.

Je me permets de relancer le sujet, parce que j'ai l'impression qu'il y a confusion.

Comme vous, je souhaitais utiliser une API pratique pour les interfaces graphiques, tout en continuant de coder en C++ natif les modules sensibles (du moins, garder en natif le code pour lequel j'avais l'habitude).

J'ai commencé avec le mix-managed. J'avais donc du code C++/Cli et du code C++ natif (il fallait utiliser #pragma unmanaged).

Et puis à force de travailler avec le Framework .net, je me suis rendu compte que c'était plutôt intéressant. En fait beaucoup mieux sur de nombreux points. Par exemple, pour la gestion réseau et xml, j'ai pratiquement basculé tous mes codes en C++/Cli.

Maintenant, je programme mes interfaces graphiques et même plus en deux/deux avec le framework. Et lorsque ce n'est pas possible, je fais des dll COM en C++ natif que j'intègre à la Winform (exemple avec des dll DirectShow/DirectX).

Le conseil que je vous donne :

vous voulez être productif dans la conception d'interface graphique, alors utilisez les winforms. Vous voulez conservez du code C++ natif, faîtes des dll COM et utilisez-les dans le programme .net.

C'est pas facile au début, mais une fois que l'on gère la chose, le gain de temps est vraiment appréciable.

[parabole33]

Bonjour.

Je me permets de relancer le sujet, parce que j'ai l'impression qu'il y a confusion.

Comme vous, je souhaitais utiliser une API pratique pour les interfaces graphiques, tout en continuant de coder en C++ natif les modules sensibles (du moins, garder en natif le code pour lequel j'avais l'habitude).

J'ai commencé avec le mix-managed. J'avais donc du code C++/Cli et du code C++ natif (il fallait utiliser #pragma unmanaged).

Et puis à force de travailler avec le Framework .net, je me suis rendu compte que c'était plutôt intéressant. En fait beaucoup mieux sur de nombreux points. Par exemple, pour la gestion réseau et xml, j'ai pratiquement basculé tous mes codes en C++/Cli.

Maintenant, je programme mes interfaces graphiques et même plus en deux/deux avec le framework. Et lorsque ce n'est pas possible, je fais des dll COM en C++ natif que j'intègre à la Winform (exemple avec des dll DirectShow/DirectX).

Le conseil que je vous donne :

vous voulez être productif dans la conception d'interface graphique, alors utilisez les winforms. Vous voulez conservez du code C++ natif, faîtes des dll COM et utilisez-les dans le programme .net.

C'est pas facile au début, mais une fois que l'on gère la chose, le gain de temps est vraiment appréciable.

merci beaucoup pour tout ces conseils .

Morale de l'histoire .. Je viens de Borland C++ . On a pas besoins de .Net pour faire des WinForn et interfaces graphiques complexes. Beaucoup plus simple pour un déploiement . Ne pas être obligé de mettre à jours les PC avec .Net ....

@+

[moldavi]

Ok.

Je me tapais les interfaces graphiques avec Win32, ça m'a vite soûlé. C'est pour cela que je suis passé aux winforms. J'avoue que les Mfc, Qt et autres, j'ai jamais adhéré. Il y des technologies comme ça qui ne passent pas. Mais j'ai eu la chance de pouvoir choisir...

Par contre je reste en C++ pour DirectX/DirectShow.