por para mando control configurar conectar .net winforms visual-studio-2008 visual-c++

.net - mando - driver control ps3 para pc windows 7



¿Por qué el Diseñador de Visual C++ no funciona después de que agregué un control a mi formulario? (3)

Quería activar el doble búfer en un panel, pero la única forma en que podíamos DoubleBuffered propiedad DoubleBuffered era crear una nueva clase heredada de System::Windows::Form::Panel , así:

#include "stdafx.h" public ref class CPPIConfig: public System::Windows::Forms::Panel { public: CPPIConfig() { this->DoubleBuffered = true; } };

Y nuestra forma se ve así, ahora:

#pragma once #using <system.drawing.dll> #include "CPPIConfig.h" [...] public ref class C3_User_Interface : public System::Windows::Forms::Form { [...] public: CPPIConfig^ pPPI; [...] } void InitializeComponent(void) { [...] this->pPPI = (gcnew CPPIConfig()); [...] } [...]

Se construye y funciona, no hay problema. Sin embargo, cuando intento ver el formulario en modo de diseño ahora, aparece el siguiente error:

Error del analizador C ++ CodeDOM: Línea: 144, Columna: 15 --- Tipo desconocido ''CPPIConfig''. Asegúrese de que se hace referencia al conjunto que contiene este tipo. Si este tipo es parte de su proyecto de desarrollo, asegúrese de que el proyecto se haya construido correctamente.

Mis preguntas:

  1. ¿Por qué el modo de diseño no funciona, incluso si el código se genera y se ejecuta? He intentado varias versiones limpias, pero ese no parece ser el problema.
  2. ¿Hay alguna manera de configurar DoubleBuffered en true sin usar este método?

Intente mover la inicialización de control debajo de la suspensión. Esto permite que el diseñador rinda correctamente sin el error de análisis CodeDOM.

Original era algo así como

#pragma region Windows Form Designer generated code /// <summary> /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> void InitializeComponent(void) { this->lblMessage = (gcnew System::Windows::Forms::Label()); this->SuspendLayout(); // lblMessage this->lblMessage->Location = System::Drawing::Point(12, 230); //..... }

Nuevo formato

#pragma region Windows Form Designer generated code /// <summary> /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> void InitializeComponent(void) { this->SuspendLayout(); // lblMessage this->lblMessage = (gcnew System::Windows::Forms::Label()); this->lblMessage->Location = System::Drawing::Point(12, 230); //..... }

La gran interrupción aquí realmente proviene de mi mezcla de código administrado vs. no gestionado. Fui a MSDN para leer más sobre él , pero el resultado es el siguiente: Visual Studio no puede manejar mi clase CPPIConfig dentro de este contexto porque es un código no administrado / nativo.

De la respuesta proporcionada para una pregunta similar :

El Diseñador de Windows Forms no puede reflejar en EXE de modo mixto. Asegúrese de compilar con / clr: pure o mover cualquier clase que requiera soporte de tiempo de diseño (por ejemplo, los componentes y controles en el formulario) a un proyecto de biblioteca de clase.

La reflexión, como lo señala esta página de MSDN , es lo que la vista Diseño está utilizando para representar el Formulario dentro del IDE. En pocas palabras, esto es lo que refleja:

La reflexión permite inspeccionar tipos de datos conocidos en tiempo de ejecución. La reflexión permite la enumeración de tipos de datos en un ensamblaje dado, y se pueden descubrir los miembros de una clase o tipo de valor determinado. Esto es cierto independientemente de si el tipo era conocido o referenciado en tiempo de compilación. Esto hace que la reflexión sea una característica útil para las herramientas de desarrollo y administración de código.

Ahh. Esto está comenzando a tener sentido.

Hay dos formas de solucionar este problema, hasta donde yo sé.

Use /clr:pure en las propiedades de su proyecto. Esto cambia el soporte de Common Language Runtime para el proyecto. Desde esta página de MSDN:

Los ensamblados puros (compilados con / clr: pure) pueden contener tipos de datos nativos y gestionados, pero solo funciones administradas. Al igual que los ensamblados mixtos, los ensamblados puros permiten la interoperabilidad con archivos DLL nativos a través de P / Invoke (consulte el uso de PInvoke explícito en C ++ (atributo DllImport)), pero las funciones de interoperabilidad de C ++ no están disponibles. Además, los ensamblados puros no pueden exportar funciones que se pueden llamar desde funciones nativas porque los puntos de entrada en un ensamblaje puro usan la convención de llamadas __clrcall.

Crea un proyecto de biblioteca de clase. Como sugirió la otra respuesta, si muevo los archivos a un proyecto de biblioteca de clase y lo hago referencia de esa manera, no vería este problema. Tal como lo entiendo, CPPIConfig código administrado CPPIConfig .

En última instancia, las limitaciones estructurales no hacen que ninguna de esas opciones sea viable, y por el bien del tiempo, hemos decidido renunciar al doble buffer en el panel por el momento. ¡Oh, bueno, al menos aprendí más sobre este entorno!