Mensajes

No conozco ningún manual que hable de todas esas posibilidades, ni creo que lo haya, dado que en general se trata de proyectos creados por distintas organizaciones y para propósitos diferentes. Te puedo dar algunos términos de búsqueda que te faciliten encontrar información de cada tema. Por ejemplo, para generar dinámicamente HTML mediante C++, y otros lenguajes, la forma "clásica" es mediante CGI (Common Gateway Interface). CppCMS es otro sistema que veo mencionar mucho. En general, si buscas "C++ web backends" deberían aparecerte varias opciones, y a partir de ahí, probablemente haya manuales para el sistema específico que te interese.

En cuanto a las aplicaciones de escritorio, no es exactamente HTML5 lo que se usa con Qt, aunque es muy similar. En realidad, lo que se puede usar para las interfaces gráficas en Qt, aparte de C++, es QML, que es un sencillo lenguaje declarativo (como HTML) que además admite javascript. También es posible usar CSS. La web de Qt tiene mucha documentación, y hay varios manuales y tutoriales de Qt, y generalmente le dedican al menos algún capítulo a QML. En todo caso, ése es el término a buscar.

La forma de hacerlo era, y es, simplemente asegurarse de forma manual que, en medio de las tareas pesadas, los eventos se están procesando de manera periódica. Digamos que tenemos una función que consiste en un bucle con instrucciones complejas, que se repite un número grande de veces (por ejemplo, aplicar un filtro a cada píxel de una imagen). Haciendo algo como esto:

Código [Seleccionar] Expandir

for (i = 0; i < NUMERO_MUY_GRANDE; i++) {
    /* Operaciones costosas
     * ...
     */
    if (hay_mensajes())
        procesa_mensajes();
}

Se logra que, en cada repetición, se efectúe una pequeña parte de los cálculos y luego se verifique si hay mensajes de ventana (por ejemplo, el usuario presionó un botón) y, de ser así, procesarlos. De esa manera el tiempo se reparte entre el manejo de la GUI y las tareas complejas del programa.

Sí, a partir de Windows Vista, es parte del sistema. Para programar es recomendable usar Visual C++, ya que aunque el compilador MinGW soporta las APIs de Windows, lo hace de forma limitada y te podría dar algún problema.

Nunca he hecho nada parecido a lo que quieres con DWM (he visto cómo se hace pero nunca lo he intentado), así que no te puedo ayudar mucho más. Con la forma antigua sí tengo experiencia, pero como te decía, tiene problemas con los Windows modernos.

No me gusta nada la manera en que Microsoft implementó esto con DWM. No es nada elegante ni me parece bien diseñado, y es más complejo de lo que debería, pero... nada que no se pueda superar con algo de paciencia 

Gracias por las respuestas..

me queda claro todo, lo único si que no comprendí bien el por qué de dos cosas

por qué dices que no debo usar system("cls"); de que otra forma puedo limpiar pantalla?..  (conozco otro método que es insertar 100 lineas vacías pero esto haría que el contenido se muestre abajo)

y lo otro, es el std::endl;  la otra forma que conozco es con la secuencia de escape \n

Saludos!

Aunque no fui yo quien te mencionó esos dos puntos, aquí te comento algunas cosas.

Deberías evitar llamar a system(), ya que lo que sucede cuando la invocas no es simplemente que estés llamando a una función (como pasa con printf, scanf, etc.) sino que creas un proceso nuevo, en el cual ejecutas un programa distinto al tuyo, y todo eso es bastante pesado, y casi nunca se justifica. Es una práctica bastante mala.

Lamentablemente no hay una forma estándar de limpiar la pantalla. Insertar líneas es una solución pobre y, como dices, no te deja el cursor al inicio (a menos que en tu programa lleves todo el tiempo un seguimiento de dónde está el cursor). La forma de hacerlo es específica de cada sistema operativo. En Windows es una manera bastante fea y requiere varias líneas de código, pero es lo que hay. Existen bibliotecas/librerías multiplataforma, como ncurses, pero para algo tan simple, no le veo mucho sentido a usarlas. En casos así, yo siempre recurro a las APIs de cada SO, que además suelen ser más eficientes y dar menos problemas.

En cuanto a std::endl, no hay nada de malo en que la uses, salvo que estás tecleando de más sin necesidad. Es común leer que, dado que endl provoca que además de imprimir una nueva línea, se limpie el buffer (lo que ocasiona que se escriban/muestren inmediatamente los datos) es menos eficiente que '\n' (que sólo imprime una nueva línea, sin limpiar el buffer, por lo que los datos podrían no imprimirse en ese momento) pero a cambio garantiza que los datos se muestren correctamente, cuando deben. Todo eso aplica cuando estamos escribiendo a un archivo, pero cuando estamos usando la salida estándar stdout (la consola/terminal/línea de comandos), como en el caso de cout, no hay ninguna diferencia. En Linux, de forma predeterminada stdout es "line buffered", es decir, el buffer se limpia automáticamente cuando se encuentra un caracter de nueva línea, así que ambos, endl y '\n', tienen el mismo efecto. En Windows stdout ni siquiera usa buffer (por defecto) así que imprimas lo que imprimas, se mostrará tan pronto como sea posible. De nuevo, es irrelevante si usas endl o '\n'.

Poder, se puede casi todo con la API de Windows, incluso crear ventanas con formas irregulares. La cosa es que no hay, que yo sepa, ninguna función que te permita cambiar lo que quieres de manera simple. Hay que escribir una buena cantidad de código, y depende de la versión del SO. Anteriormente era sólo cuestión de, por ejemplo, manejar el mensaje WM_NCPAINT, dibujar y acomodar manualmente la barra de título a tu gusto, y manejar los eventos de los botones. Pero eso sólo funciona hasta Windows XP.

Lo anterior ya era un poco complicado, pero para versiones más modernas de Windows lo es aún más. Ahora es necesario usar la API DWM (Desktop Window Manager). No es que sea demasiado difícil pero vas a necesitar implementar un montón de cosas que normalmente Windows hace por ti. Y se necesita tener ya unos conocimientos muy sólidos de la API de Windows. Puedes buscar en Google la API que te menciono y darte una idea, pero sí implica bastante trabajo.

Puedes probar con secuencias de escape ANSI. No te aseguro que funcione pero probablemente lo haga, dado que Android se basa en Linux. Por ejemplo, para simular gotoxy(10,5):

Código (c) [Seleccionar] Expandir

printf("\x1b[10;5f");
Sólo sustituyes 10;5 por ncolumna;nfila.

Cuidado, que en ese link dan 2 soluciones para limpiar el buffer, pero una de ellas, la que usa fseek, es casi tan mala como fflush(stdin). La verdad es que esa opción también es bastante antigua, y su problema es que parte de una premisa incorrecta: que stdin es un archivo, lo cual es falso. Lo tratamos como un archivo, pero en general, cuando nos referimos a la terminal (línea de comandos) no lo es.

La cuestión es que, en algunos sistemas stdin permite hacer búsquedas (fseek) y en otros no. Esa solución puede funcionar en Windows, igual que fflush(stdin) (aunque no hay garantía de que siempre lo haga... igual que fflush(stdin)), pero va a fallar en otros sistemas operativos, como Linux (igual que... creo que el punto está claro). De hecho, hasta hay documentación que lo dice. En Linux y algunos otros sistemas tipo Unix, la implementación de fseek llama internamente a la función del sistema lseek. La documentación oficial dice sobre esa función:

On Linux, using lseek() on a terminal device fails with the error ESPIPE.

Es decir, que usar lseek (y por lo tanto, fseek) en una terminal falla con el error ESPIPE.

Así que para limpiar el buffer lo mejor son las alternativas que te propusieron (getchar,() fgetc(stdin)), o la primera que aparece en ese link:

Código (cpp) [Seleccionar] Expandir

while((c = getchar()) != '\n')

Eso sí, mejor usar '\n', como te lo puse, que 0xA, que es lo que ponen en el link.

Creo que ya te explicaron bastante bien cuál era el problema, pero por si te queda la duda de por qué comentando esa línea específica el programa te funcionaba, te digo una posible causa, que además es una buena oportunidad para que veas por qué puede ser tan complicado detectar errores en el manejo de la memoria.

Cuando un programa se ejecuta, se reserva cierto espacio de memoria para él. En una parte se coloca el código del programa, en otras los datos, (como las variables y otro tipo de información), y algo de memoria extra que reservan como previsión (por si acaso más adelante hace falta, es más eficiente tenerla ya lista). Toda esa memoria "pertenece" a tu programa. Aparte de esto, el programa puede establecer permisos para ciertas zonas de la memoria, por ejemplo, el código del programa se suele colocar en un segmento de memoria marcado como de sólo lectura. Los errores de violación de acceso/segmento se dan cuando un proceso -o programa en ejecución- intenta acceder a memoria que no le pertenece, o bien, intenta hacer algo indebido con memoria que le pertence (por ejemplo, escribir en regiones de sólo lectura), pero para simplificar, me enfoco en el primer caso.

Cuando tienes un puntero sin inicializar, como cadenados, originalmente contendrá "basura", es decir, apunta a una dirección de memoria impredecible. Si intentas acceder a ella, y se trata de una dirección que tu programa no ha reservado, se producirá el fallo. Pero si por casualidad apunta a una dirección que sí le pertenece a tu programa, puede que funcione sin problema aparente . La razón es que los errores de violación de acceso se producen a nivel de sistema operativo (con apoyo del procesador) y obviamente éste no sabe si estás usando bien o no los punteros; sólo le interesa si tu programa en general tiene permisos de acceso o no. Aún así es un error, y para muestra tu programa.

Si no te falla después del gets, significa que en tu PC, cadenados, por casualidad, está apuntando a memoria reservada por tu programa.
Dices que el error se da si descomentas esta línea:

Código (c) [Seleccionar] Expandir

//printf("pp->cadenatres %s\n", pp->cadenatres);

Pero ahí sólo accedes a cadenatres. Mi suposición es que la dirección a la que se inicializa por azar cadenados es la dirección del miembro cadenatres. Así, cuando gets modifica los datos apuntados por cadenados, accidentalmente estás sobrescribiendo cadenatres, que ahora está apuntando a una dirección impredecible. En este caso, probablemente a memoria que no te pertenece, y por eso el printf falla, por intentar acceder a memoria no válida.

Siguiendo con este supuesto, esto no tendría por qué fallar:

Código (c) [Seleccionar] Expandir

if(strcmp(cadenauno,cadenados)==0){

Ya que cadenados apunta a memoria "válida" (desde el punto de vista del sistema operativo).

No sé si también te funcionaba esta línea:

Código (c) [Seleccionar] Expandir

if(strcmp(cadenauno,pp->cadenatres)==0){

pero de ser así, probablemente significa que cadenatres quedó apuntando a una dirección que está cerca del final de una región reservada por tu programa. Me explico: una cadena de C termina cuando se encuentra el caracter de fin de cadena '\0'. Así, la variable cadenauno apunta a la cadena "hola\0". Imagina que la dirección a donde quedó apuntando cadenatres contiene esto: "#5&bfdfgfgfhgh6(\0". Sería posible que los primeros, digamos 4 caracteres, apunten a memoria que anteriormente reservó el programa, y a partir del 5o caracter, entramos a memoria no válida. Eso significaría que, mientras no intentes acceder más allá de su 4o caracter, no habrá error. La función printf, naturalmente, intentará imprimir la cadena entera, y por lo tanto, fallará. El caso de strcmp es distinto, ya que desde el primer caracter detectará que las cadenas son distintas, y por lo tanto deja de procesarlas, y te devuelve el resultado, sin haber llegado nunca a intentar leer el 5o caracter, y por eso no falla.

Todo esto es sólo suposición mía, pero es una posibilidad válida, y más de una vez me he encontrado con casos así. Como ves, un error en un puntero terminaría dejando a otra variable (cadenatres) en un estado inválido, y esta última sería la que provocara fallos. Y no habría nada en el código que indique que cadenados modificó a cadenatres, por lo que, si se tratara de un programa más grande, podría ser muy difícil dar con el fallo.

La moraleja: ten mucho cuidado al manejar punteros y nunca los uses sin inicializar. Eso te evitará muchos dolores de cabeza.

Ah, ya  . Es la versión para Windows de la BGI de Borland. Es sencilla, aunque lenta , pero para un buscaminas puede bastar.

¿Probaste con su función getmouseclick? Debería devolverte las coordenadas correctas en su segundo y tercer parámetros.

Necesitas especificar qué estás usando. Dices que la librería graficos, pero imagino que no se llama así, ¿cierto? Y es que hay muchas diferentes.