Discussion :

[JeanNoel53]

bonjour
Je n'arrive pas à compiler le type string

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public ref class OpenAFile : public System::Windows::Forms::Form
	{
	private: 
	    System::Windows::Forms::Button^  button3;
		Form^ form1;
	public:
		std::string sFileToOpen;

Je suis en mode managé mais la documentation me dit que j'ai le droit de faire cohabiter du code managé et du code natif. Le compilateur n'a pas la même interprétation:
je vous joins le résultat de compilation

OpenAFile.h(7): error C4368: impossible de définir 'sFileToOpen' comme membre de 'Test6::OpenAFile' managé*: les types mixtes ne sont pas pris en charge

ce serait d'avoir un module qui accepte le type string

[stardeath]

bonsoir,

et inclure le header adéquate?

[JeanNoel53]

ou mieux

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#include <stdio.h>
#include <string>

Bien sur
en fait il faut déclare les objets comme des objets globales

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
std::string sFileToOpen;
std::string sPathOfTheFile;
std::string sDiskOfTheFile;
namespace Test6 {
	using namespace System;
	using namespace System::ComponentModel;
	using namespace System::Collections;
	using namespace System::Windows::Forms;
	using namespace System::Data;
	using namespace System::Drawing;
	using namespace System::IO;
    /// <summary>
	/// Description résumée de OpenAFile
	/// </summary>
	public ref class OpenAFile : public System::Windows::Forms::Form
	{
	private: 
		Form^ form1;
	public:
 
		OpenAFile::OpenAFile(void);
		OpenAFile::OpenAFile(Form^ form1);
		OpenAFile::~OpenAFile();
 
		void Test6::OpenAFile::InitializeComponent(void);

[bacelar]

NON.

Il ne faut pas mélanger les torchons et les serviettes.

Dans des classes managées, vous ne devez utiliser que des classes managées.

.NET dispose de la classe System::String, bien plus sympa que la classe std::string.

[JeanNoel53]

Les deux sont effectivement possible. J'ai opté pour la seconde. Ce choix est provisoire, je prendrai à ce sujet une décision pour le projet définitif. Pour l'instant je dois d'abord faire marcher la maquette.

[bacelar]

Votre choix n'est pas une option, c'est un cul de sac.
Faites-moi confiances.

Il ne faut pas mélanger le monde managé et natif.
Le code intermédiaire entre ces mondes est complexe et il est inutile de complexifier votre maquette pour rien.

Revenez sur votre choix.
Il suffira de supprimer vos std::string une par une et de remplacer le code en erreur indiqué par le compilateur par le nom du membre static de la classe.
Il n'y a aucun refactoring à faire, juste du copier-coller de nom de membre.
Cela devrait prendre 1 minute par variable, au grand maximum, pour un projet de la taille d'une maquette.

C'est simple, rapide et cela vous épargnera bien des désagréments.

[JeanNoel53]

Comme je l'ai dit ailleurs j'ai une application de 50 000 lignes de code à migrer sous Visual Studio. Ce code est écrit en C++ natif.
Pour passer sous Visual Studio C++, je me suis mis au C++/CLI, ok et au sein de la classe, je n'ai pas de problème à utiliser les type System::String. Cependant pour passer à l'application je dois repasser en std::wstring pour être compatible avec le code existant. il y a deux problèmes: convertir les System::String en wchar_t* et affecter les variables locales. le premier est résolu par le code ci après

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
                wsLocalString = openFileDialog2->FileName;
		using namespace Runtime::InteropServices;
                const wchar_t* chars = (const wchar_t*)(Marshal::StringToHGlobalUni( wsLocalString)).ToPointer();
                .
                .// affecter la variable  finale avec le resultat acquit dans chars.
                .// et libérer les ressources
                Marshal::FreeHGlobal(IntPtr((void*)chars));

il reste que l'accès des variables globales de type std::wstring n'est pas trivial; actuellement je n'ai pas de solution qui marche.

[bacelar]

Globale ou pas, le mécanisme de Marshaling des string entre le code managé et natif est le même.

[JeanNoel53]

la fenêtre de mémoire n'est toujours pas ouverte. Quoi qu'il en soit on est maintenant dans le domaine de l'emploi du debugger. Je clos donc cette discussion

[bacelar]

http://social.msdn.microsoft.com/For...8-bfde358d0501

[Bousk]

une application de 50 000 lignes de code à migrer sous Visual Studio. Ce code est écrit en C++ natif.
Pour passer sous Visual Studio C++, je me suis mis au C++/CLI

Je ne vois pas le rapport.
Visual Studio supporte très bien et est adapté à faire du C++ "classique".
En tous cas le CLI n'est pas du tout obligatoire pour convertir en projet Visual Studio son application.