Programación vc, mira ¿qué hay de malo en lo que escribo así?
VC es realmente una herramienta muy estúpida y hostil. Digámoslo de esta manera, VC (MFC) es la más popular ahora. net framework java es como la Edad de Piedra en comparación con la era industrial
WC_DEFAULTCHAR, strWideChar, strWideChar.GetLength(), (char *)buf, //convertir al buffer 20, //max Bytes 0, 0
De manera similar, si desea que la cadena que recibe se muestre normalmente en la interfaz, debe convertirla en una representación de bytes amplia:
char chBytes[8]; (chBytes, "aaaaaaa\0", 8); WCHAR wch[9]; n = MultiByteToWideChar( //Convertir Unicode a Ansi CP_ACP, 0, chBytes, 8, wch, //Convertir a buffer Medio 8 //Número máximo de bytes); wch[n] = '\0';
De esta manera, cada vez que obtiene datos de la interfaz y los muestra en la interfaz, primero debe realizar el procesamiento, pero usted También puede configurar el entorno de compilación en "Conjunto de caracteres de varios bytes" para evitar tales conversiones (desafortunadamente, el código estaba casi terminado cuando lo descubrí). Simplemente en "Propiedades de configuración del proyecto-General-Conjunto de caracteres, seleccione "Usar juego de caracteres Unicode" para usar el juego de caracteres Uncode, seleccione "Usar juego de caracteres de varios bytes" para usar el juego de caracteres de varios bytes.
Capítulo Me atraparon dos veces, Dios, me tomó mucho tiempo encontrar el problema:
Encontré un código fuente escrito por un extranjero muy amable en CodeProject que hereda la clase de formulario CDialog CResizableDialog. class La función es permitir que los controles en el formulario se coloquen (Auchor) cuando el formulario MFC se amplía o reduce. No subestimes esta pequeña función que se usa todos los días. Es realmente problemático implementarla con MFC. Admiro mucho a ese extranjero por haber escrito tanto código (por supuesto, tiene algo que ver con sus condiciones. Los trabajadores en los países capitalistas pueden simplemente encontrar un trabajo y tener suficiente comida y ropa. El gobierno se hará cargo de ellos cuando estén enfermos). Estamos "pateados" y vivimos como trabajadores inmigrantes. Por supuesto, no tenemos ese tiempo libre. No quiero escribir un código tan bueno para que otros lo usen de forma gratuita, lo cual es una digresión. p>Tomé ese proyecto ya preparado y hice referencia directa a su proyecto en mi proyecto. Todo funcionó perfecto. Publiqué el proyecto como Lanzamiento y no pasó nada después de hacer doble clic en él para ejecutarlo. ¡Muy extraño! el mensaje y descubrí que no apareció cuando lo ejecuté en la función DoModal. ¡No pude obtener el error incluso con try and catch! Mi formulario hereda la clase de formulario escrita por un extranjero. herede CDialog. El problema debe estar en su proyecto, pero no hay ningún problema con el programa de muestra que proporcionó. MFC es muy grave cuando falla, ¡simplemente no funciona! p>
Tomé otro programa de prueba y lo hice heredar de CResizableDialog, y no hubo ningún problema.
Simplemente no funcionó. Estoy confundido y sin palabras. El problema es que la versión no se puede depurar como Debug. Después de reproducir un montón de cuadros de mensajes, todavía no sé dónde está el problema.
Según la experiencia, podemos saber que puede haber un error fatal, como el acceso fuera de los límites a la memoria en el programa, lo que hará que el programa se cierre "silenciosamente", pero ¿qué salió mal exactamente?
Justo cuando estaba perdido, descubrí que llamar a la función miembro EnableSaveRestore de CResizableDialog provocaría un error de enlace: "Símbolo externo no definido, no habría ningún error si no hacía referencia a él". no habría errores si el programa de prueba hiciera referencia a él. Generalmente este error ocurre porque la función de referencia está activa. h archivo, pero en. Tampoco hay una definición en cpp. definición de archivo cpp y. Los parámetros en h no coinciden. Pero no puede ser este error en este momento porque no hay ningún error en el programa de prueba. La intuición me dice que esta es la clave para resolver el problema de "el programa sale directamente después del lanzamiento". Tal vez el problema de esta llamada a función esté resuelto y el problema del lanzamiento también esté resuelto.
MFC es realmente poderoso no sólo es "como un laberinto, con monstruos dentro, nunca podrás salir si ingresas accidentalmente", sino que también te permite avisarte siempre cuando lo hagas. Te encuentras con un monstruo con un poco de luz de las estrellas, mientras no te rindas, aparecerán milagros y lograrás una magia incomparable. Esto es similar a las novelas de artes marciales. Cada vez que el protagonista llega a un momento crítico de vida o muerte, ocurrirá un milagro y se convertirá en un maestro invencible. Mira cómo encontré la solución, muy complicada.
Dado que se produjo un error al llamar a EnableSaveRestore que no debería haber ocurrido, comience a buscarlo desde esta función. Esta función es así:
declaración del archivo .h void EnableSaveRestore(LPCTSTR pszSection, BOOL bRectOnly = FALSE); definición del archivo .cpp void CResizableDialog::EnableSaveRestore(LPCTSTR pszSection, BOOL bRectOnly/* = FALSE */ )
No hay errores en el código anterior. Dado que no hay errores, debe utilizar los siguientes métodos para encontrarlos:
1. Reescribir una función para CResizableDialog. No tiene parámetros y se llama It, no se encontraron errores, parece que hay algún problema con los parámetros.
2. Dado que no hay ningún error en una función sin parámetros, simplemente elimine los parámetros de la función problemática y no habrá ningún error. El problema debe estar en los parámetros.
3. Elimine uno de los parámetros y la prueba encontró que es un problema con LPCTSTR pszSection, no con BOOL bRectOnly.
4. En este caso, cambiemos la expresión, reemplacemos LPCTSTR pszSection con WCHAR* pszSection, ejecútelo y no habrá ningún error. Si abre la definición de macro MFC, encontrará que LPCTSTR y WCHAR * son en realidad lo mismo que MFC.
5. Sin embargo, la función de esta función todavía no es normal. Cuando entro en la función, encuentro que la cadena pasada tiene solo un carácter. como carácter corto, el segundo byte \0 se usa como carácter de corte de la cadena, es decir, esta función usa caracteres cortos (Multi Byte) para procesar.
6. Mi proyecto utiliza un conjunto de caracteres amplio (Unicode Char). Resulta que el extranjero se compiló con VC6. El valor predeterminado es utilizar un conjunto de caracteres múltiples (Multi Byte). VC es realmente estúpido, dos proyectos con configuraciones completamente diferentes en una solución ni siquiera tienen indicaciones, ¡simplemente me mató!
7. Cambie el proyecto de referencia para usar el juego de caracteres Unicode y restaure la función EnableSaveRestore WCHAR* pszSection a su estado original, ¡listo! Como era de esperar, ¡no hay ningún problema con Release! Utilicé el antiguo programa de prueba para configurarlo en Multi Byte justo antes, por lo que no hubo errores, ¡Maldita sea!
Es solo una configuración. Si el mensaje de error de VC es mejor, al menos sería más fácil de usar si el conjunto de caracteres no coincide y no lo llama "símbolo externo indefinido". ¡Y ahora más personas usan VC menos!
Nota: En términos generales, VC no se refiere al uso. NET framework, que es muy simple y no requiere administración de memoria, generalmente se refiere a VC no administrado.