SoloCodigo

Para que te funcione en otro ordenador, tienes que compilar en Release en lugar de Debug, y creo que para aplicaciones de Visual C++ 6 no necesitas instalar el runtime de C/C++ porque todos los ordenadores lo traen. No obstante esa descarga ya no existe en los sitios de Microsoft porque VC 6 es antediluviano, así que una opción es que vayas localizando en tu equipo de desarrollo las DLL que te faltan (el programa te las irá diciendo) y las pongas en el nuevo ordenador.

Visual C++ 2008 y Visual C++ 6 son completamente iguales, excepto que el 2008 tiene como diez mil cosas más y las que son comunes están en diferente sitio.

El que te vaya o no dependerá del driver de vídeo o incluso del SP que tengas instalado, te lo garantizo.

Actualizar al Borland C++ 5.5 sigue siendo más de lo mismo: un compilador más que obsoleto, que sólo acepta código antiguo (hay por lo menos dos revisiones de C++ que el Borland no acepta) y que encima no acepta ni siquiera bien el código que acepta.  

Es a eso a lo que me refiero: aprender gráficos con BGI es como aprender electrónica de válvulas. Aprender el C++ de un compilador tan antiguo es como aprender mecánica de vapor para mover coches. Y que tenga cierto renombre o no no importa: es viejo y obsoleto. Anda, pregúntale que te explique las plantillas en función, los predicados y si la STL es una buena biblioteca de contenedores y algoritmos o no.

Me apuesto un gallinfante a que ni siquiera estás aprendiendo buen C++.

Respecto a lo que nos ocupa, el BGI es tan viejo que ni siquiera está soportado por el ya de por sí viejo BC++ 5.5. Lo más moderno que te pueda servir sería el Borland C++ 5.02, que todavía es más viejo que el 5.5 (que es C++Builder 1). Es decir, no puedes pasar eso porque el compilador no lo soporta.

Con el tema de recorrer los archivos en linux no tengo ni idea ya que in la biblioteca de C ni la de C++ traen nada como estándar. Para las cadenas sí, puedes usar igualmente strtok o el equivalente d C++ para ir partiendo la cadena original.

Je je, ya ves.  

Aunque no suelo pasarme mucho, si veo algo sin responder que no sea muy viejo y lo sé, pues respondo.  

Hasta donde yo sé, OpenFileDialog() pertenece al .NET Framework, no a Win32 ni a MFC...

Si te estás refiriendo a la función de .NET, la clase tiene un método llamado Title que contiene el título de la ventana... Sin embargo, si quieres hacer aplicaciones internacionales en .NET es mucho más fácil:

http://msdn.microsoft.com/es-es/library/t18274tk(VS.80).aspx

Por lo que veo la variable CBitmap es local al método en el que lo cargas, por lo que cuando salga de ámbito será destruida y el bitmap (que se asocia con el handle del CBitmap, no se copia), apuntará a cualquier lado. El bitmap ha de ser una variable miembro del diálogo. Ésta permanece pintada hasta que el botón se invalida y cuando tira a pintarse a sí mismo, el bitmap ya no está.

Otra cosa, cuando asignes el bitmap al botón, debes hacerlo mediante la llamada GetSafeHandle() del propio bitmap.

Por otro lado, podrías usas CBitmapButton, y especificar tres bitmpas diferentes, uno para el botón normal, otro para cuando esté presionado y uno más para cuando esté deshabilitado.

Eternal, nunca la tuve porque nunca usé CreateThread por lo dicho. Siempre lo he hecho con _beginthreadex.

¿Con TID te refieres a TLS? Thread Local Storage. Si te refieres a eso, sí, el problema viene de ahí, y es más gordo en la versión DLL que en la estática, ya que el almacenamiento local no se inicializa bien y funciones con variables estáticas (como por ejemplo strtok) fallan estrepitosamente y hasta podrían tumbar la aplicación.

Si TID es otra cosa, ni idea de lo que es.

Si no usas ninguna ruta en el nombre de los ficheros, se guardarán donde el ejecutable.

Hola.

No necesariamente, se guarda en el directorio actual. El que en general sean el mismo no quiere decir que siempre vayan a hacerlo. Una forma de cambiarlo es poner otra ruta en el "Start In" (lo siento mis Windows están en inglés) del acceso directo.

Cita de: "rfog"

Hola, no hace falta que construyas dinámicamente el array, lo puedes hacer de forma estática

en ningun lado use allocacion dinamica de memoria, intenta leer bien mi codigo!

 

No he dicho asignación dinámica de memoria, he dicho "construir dinámicamente el array" frente a hacerlo de forma estática. Es decir, en mi caso, ya sea un array global o local, es el compilador el que genera el array (realmente estará en RODATA y lo que hará será poner un puntero a ese área). Mi programa funcionará más rápido que el tuyo, usará menos memoria y encima, si por error se intentara escribir en el array para la comparación, el compilador lo detectaría.

Además, en el código de ejemplo que has puesto, si el usuario introduce "Enero" o "enERO" etc, el programa no encontrará el mes. Recuerda el teorema del universo y los usuarios.

Me parece muy obvio lo que pido, al menos yo no quiero estar leyendo todo el codigo que no tenga nada que ver con el problema, quiero ver pura y exclusivamente lo que tenga que ver con el mismo. Y no quiero tener que crear un esqueleto para compilarlo.

Eso resulta evidente por sí mismo, y es lo menos que debe hacer quien pregunta. Además, a veces, cuando uno intenta aislar el problema... descubre qué estaba haciendo mal. A veces, con constructos complejos, el error ni siquiera viene de la línea en donde el compilador lo detectó, y al aislar el problema nos damos cuenta de por dónde van los tiros.    

Realmente no entiendo qué quieres hacer, pero el método normal para comunicar un hilo secundario con el principal es enviarle un mensaje personalizado (WM_USER+<valor>) y el bucle de mensajes principal lo coge y hace lo que tenga que hacer con él.

Otra forma es comunicarse mediante eventos. Mira CreateEvent().

Hasta donde yo sé no es posible enviar mensajes de un proceso a otro en Windows. Eso se conoce como "saltar la barrera del proceso" y si se pudiera hacer de forma sencilla resultaría un enorme y engorroso fallo de seguridad (imagina un ActiveX instalado en el Internet Explorer que forzara al programador de tareas mediante envío de mensajes inter-proceso el crear una tarea para formatear el disco duro durante el siguiente arranque. A esto mismo se lo conoce como "escalada de privilegios a través del bucle de mensajes").

Eso no quiere decir que no se pueda hacer, sólo quiere decir que es bastante complejo de hacer. Jeffrey Ritcher en sus libros sobre programación de sistemas para Win32 lo explica; la última versión publicada se llama "Windows via C/C++", que tento pendiente de leer y que sólo está de momento en inglés y que por eso no sé si sigue contándolo o no. Todos los anteriores están descatalogados y hay alguna traducción al castellano también descatalogada.

El tema está en lo que se conoce como "Inyectar una DLL en otro proceso" y basícamente se trata de eso: crear una DLL que se inyecta en otro proceso y que al estar en ese otro proceso ya es capaz de enviar localmente los mensajes adecuados.

El tema es un poco *complicadillo*, pero seguro que en San Google encuentras por dónde empezar si buscas "DLL process injection" o similar.

Una vez que sepas cómo y qué hacer, si tienes dudas puntuales quizás podamos ayudarte...

La últma versión del Turbo C++ Explorer (gratuita) te la puedes bajar de aqu: http://turboexplorer.com/downloads.

Y creo, sólo creo, que no funciona bajo Vista, ya que exige la instalación del .NET 1.1 y éste no se puede instalar en Vista.