Autor Tema: Formato Bmp (Leído 60777 veces)

senzao18

Estoy usando VB.Net.

Logre hacerlo con la clase BinaryReader.

Muchas gracias por tu aporte.

Geo

Cita de: "Geo"

Una cosa, ¿con qué lenguaje estás trabajando ?

Cita de: "senzao18"

Estoy usando VB.Net.

Jaja, a ver si pongo más atención a los títulos en los nicks

.

senzao18

Cita de: "Geo"

Cita de: "Geo"
Una cosa, ¿con qué lenguaje estás trabajando ?
Cita de: "senzao18"
Estoy usando VB.Net.
Jaja, a ver si pongo más atención a los títulos en los nicks .

Jajaja pues yo creo que si....

Una preguntilla. Con que imagenes me deberia de fallar el programa ya probe con la de JuanK y una jpg que teniamos que pasar a BMP y salen bien.

JuanK o alguien, En la salida a que te refieres con retroalimentacion cuando la imagen no es del formato especificado?

senzao18

Pues ya lo envie JuanK espero esté bien

JuanK

sele debe informar al usuario, eso es retroalimentacion.

Por ejemplo: si no es una ext bmp se le debe infromar o si el identificador no corresponde a un bmp tambien.

Nagisa

Cita de: "JuanK"

Cita de: "Nagisa"

De hecho al final lo lei todo de una vez... A mi tambien me parecio mas optima una sola peticion de lectura

Saludos!
Pero aun no me has enviado tus fuentes actualizados.

Si, son los que te mande...

JuanK

Cita de: Nagisa,Julio 21, 2006 11:43 am

Pero aun no me has enviado tus fuentes actualizados.

Si, son los que te mande... [/QUOTE]
Ok, ya lo recibi.

Hasta el momento he recibido los programas de:

Nagisa
Diodo
Enko
Geo
Zenzao18

Juank

Aparentemente solo falta Danielo amenos que alguien mas confirme y terminamos.

Ya cada cual sabe las debilidades y fortalezas de sus programas, asi que si desean hacer algun ajuste final, pueden hacerlo entes de que entregue Daniel, ya que en ese momento se cierra el reto.

Danielo

Estoy teniendo lío con la parte de cargar el bmp desde cualquier ubicación, primero se me ocurrió utilizar un treeview para obtener la ruta y un listbox para obtener el nombre del archivo. El tema es que como lo estoy haciendo con el API no me está resultando para nada sencillo.
Ahora estoy intentando con un cuadro de diálogo que contiene 2 controles edit, uno para introducir manualmente la ruta y el otro para el nombre del bmp y 2 botones (Aceptar y Cancelar). Cuando escribo la ruta y el nombre se que están funcionando porque las puedo ver con un MessageBox, pero a la hora de asignarle la ruta al procedimiento que me carga el bitmap me da error, debido a que tiene que estar necesariamente entre:

Código: Text

case WM_PAINT:
           ...
           ...
           break;
 

y el botón Aceptar está dentro de:

Código: Text

WM_COMMAND:
           ...
           ...
           break;
 

o sea, no veo la forma de ejecutar lo que está dentro del WM_PAINT desde dentro del WM_COMMAND

intuyo que la solución debe estar en hacer una función que retorne la ruta y nombre de archivo obtenida a partir del cuadro de diálogo, pero por ahora no se me ocurre como hacerla

JuanK

para una solucion mas limpia yo tendria que ver mejor tu codigo... y hace rato que no hago nada con la win32 Bored API.

pero por el momento, porque no usas una variable global?

Geo

Yo usaría una variable global (no he programado una aplicación con la WinAPI), y para obtener el nombre del archivo mediante un diálogo:

GetOpenFileName Function

Saludos,
JJ (Geo).

Danielo

Cita de: "Geo"

Yo usaría una variable global (no he programado una aplicación con la WinAPI), y para obtener el nombre del archivo mediante un diálogo:

GetOpenFileName Function

Saludos,
JJ (Geo).

ya me parecía raro que no existiera algo parecido a los InputBox

.
Buena idea lo de la variable global, vengo intentandolo desde hace un buen rato

y ahora me doy cuenta donde estaba la falla: por alguna extraña razón la maravillosa función GetOpenFileName retorna rutas como por ejemplo esta:

c:\imagenes\archivo.bmp

y me estaba dando error porque mi procedimiento de cargar bitmpap:

imagenBMP *CargarBitmapArchivo(char nombreArchivo[]);

espera: c:\\imagenes\\archivo.bmp

ahora me doy cuenta que el carácter "\" al ser un carácter de escape, era lo que me estaba dando problemas

.

Viendo la documentación de GetOpenFileName parecería que no hay forma de convertir la ruta al "formato" que entiende mi CargarBitmapArchivo, así que a menos que alguien me diga lo contrario creo que no tendré más remedio que implementar un procedimiento que solucione el problema del carcacter de escape "\"

Enko

Que yo recuerde, '\' se usa para poner despes los caracteres especiales, pero solo desde el compilador.
Si no me equivoco, si la entrada se hace por teclado, es decir por el usuario, en tiempo de ejecucion, la barra '\' es un caracter m'as.

JuanK

asi es.

Enko

Cita de: "JuanK"

asi es.

Entonces cual es el problema que tiene Danielo

JuanK

Saludos,
con motivo que Geo me envio su programa con WxWidgets y C++ y me lo paso en versiones linux y windows y funciono OK, me propuse a revisar mejor lo del proyecto Mono asi que trate de ejecutar mis 2 proyectos del reto hechos en C# en un linux ubunto y no me funciono :'(...

la razon resulta que el runtime de mono en el momento solo soporta hasta C# 1.1, el soporte para C# 2.0 aun no esta completo y desde luego mis programas se compilaron con C# 2.0.

Asi que decidi instalar el monodevelop en linux ubuntu , cree un proyecto con mis fuentes de la libreria que hice y la compile... compilo perfecto!!!

Despues procedi a compilar los dos proyectos que hice para el reto, el extra y el de la entrega, el Extra compilo perfecto y funciono perfecto , pero el del reto no porque utiliza cosas de C# 2.0, pude haber instalado el gmcs ( el compilador de mono para c# 2.0) pero no porque eso implicaria invertirle mas tiempo, sin embargo vi la documentacion y verifique que el unico error por el que no compilabara ya esta soportado en C# 2.0 para mono.

Lo mas interesante fue que coji mi libreria y el aplicativo compilado en linux ubuntu con C#1.1 y me lleve el ejecutable tal como se genero en linux y me funciono en windosw XP sin hacerle nada

ya que al tener en windows XP instalado el runtime del .net framework 2.0 tengo soporte para todas las versiones anteriores de c#

.

Hice la prueba invertida, busque en mi pc algunos proyecto antiguos que tenia de C# 1.1 , un hola mundo y otra aplicacion de consola, y me lleve los exe tal cual a linux ubuntu... funcionaron de inmediadto... de maravilla

Danielo

Lo que pasa es que cuando se abre un fichero en C++ con fopen y el archivo tiene path, hay que abrirlo así

:

Código: Text

FILE* handle = fopen(&#34;D:&#092;&#092;path-name&#092;&#092;fichero.nnn&#34;, &#34;r+b&#34;);
 

más info en: http://www.zator.com/Cpp/E5_5_2a.htm

JuanK

Antes de que me digan nada ya mire que ya esta disponible el compilador gms completo , de hecho esta comom opcion por defecto

Lo que pasa es que me da mucha pereza este cuento de linux, para evitarme la fatiga lo habia instalado desde synaptic pero al parecer no todos los paquetes que oferecn estan actualizadod... pero estoy bajando el binario a ver si esta noche hago el deber... lo que si ya esta confirmado es que monodevelop no soportara c# 2.0 hsta que no se libere la version 1.0 de monodevelop lo cual no se cuando sera...

asi que tendre que compilar por linea de comandos... y con la manotada de referencias que usé

JuanK

Cita de: "Danielo"

Lo que pasa es que cuando se abre un fichero en C++ con fopen y el archivo tiene path, hay que abrirlo así :
Código: Text
FILE* handle = fopen("D:\\path-name\\fichero.nnn", "r+b");

más info en: http://www.zator.com/Cpp/E5_5_2a.htm

sigo sin entender tu problema... es decir y que hay con eso. por eso no te puede fallar

Danielo

Cita de: "JuanK"

Cita de: "Danielo"
Lo que pasa es que cuando se abre un fichero en C++ con fopen y el archivo tiene path, hay que abrirlo así :
Código: Text
FILE* handle = fopen("D:\\path-name\\fichero.nnn", "r+b");

más info en: http://www.zator.com/Cpp/E5_5_2a.htm
sigo sin entender tu problema... es decir y que hay con eso. por eso no te puede fallar

si no está fallando eso, el error debe estar por otro lado y me temo que es porque el procedimiento que muestra el bitmap en pantalla no puede recibir la ruta y el archivo a cargar:

Código: Text

/*  Esta función es invocada por la función DispatchMessage()  */
LRESULT CALLBACK WindowProcedure(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
OPENFILENAME ofn;       // common dialog box structure
char szFile[260];       // buffer for file name
HANDLE hf;              // file handle
 
// Initialize OPENFILENAME
ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hwnd;
ofn.lpstrFile = szFile;
//
// Set lpstrFile[0] to '&#092;0' so that GetOpenFileName does not 
// use the contents of szFile to initialize itself.
//
ofn.lpstrFile[0] = '&#092;0';
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFilter = &#34;All&#092;0*.*&#092;0Text&#092;0*.TXT&#092;0&#34;;
ofn.nFilterIndex = 1;
ofn.lpstrFileTitle = NULL;
ofn.nMaxFileTitle = 0;
ofn.lpstrInitialDir = NULL;
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
 
static HINSTANCE hInstance; // inicializo instancia... no si sirve para algo
 
HDC hDC;
PAINTSTRUCT ps;     
unsigned long x,y;    
 
    switch (msg)                  /* manipulador del mensaje */
    {
        case WM_COMMAND:
           switch(LOWORD(wParam)) {
              case CM_ABRIR:
                // Display the Open dialog box. 
                if (GetOpenFileName(&ofn)==TRUE){ 
                  hf = CreateFile(ofn.lpstrFile, GENERIC_READ,0, (LPSECURITY_ATTRIBUTES) NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,(HANDLE) NULL);
                                    
                MessageBox(hwnd, szFile, &#34;Mensaje de prueba&#34;, MB_OK); // Muestra ruta del bitmap
                imagenBMP *bmp=CargarBitmapArchivo(szFile);
                 hDC = BeginPaint(hwnd, &ps);
                 for(y =0;y&#60; getAltoBitmap(bmp); y++){
                  for(x = 0; x &#60; getAnchoBitmap(bmp); x++)
                  SetPixelV(hDC,x,y,getPixelMatrizBMP(y,x,bmp));
                 }
                 EndPaint(hwnd, &ps); 
                }
                break;
              case CM_SALIR:                 
                 PostQuitMessage(0);    /* envía un mensaje WM_QUIT a la cola de mensajes */
                 break;
           }
           break;   
        case WM_DESTROY:
           PostQuitMessage(0);    /* envía un mensaje WM_QUIT a la cola de mensajes */
           break;
        default:                  /* para los mensajes de los que no nos ocupamos */
           return DefWindowProc(hwnd, msg, wParam, lParam);
    }
    return 0;
}
 

Mi programa, tiene un menú sencillo que por ahora solo tiene la opción de Abrir y Salir, entonces, cuando selecciono Abrir se ejecuta GetOpenFileName y obtengo la ruta y nombre del bitmap a mostrar en pantalla, luego veo la ruta con un messagebox y se ve correctamente.
El problema tal vez viene en el paso siguiente ya que me sale un mensaje que dice:
"se ha detectado un problema y debe cerrarse"

Aparentemente lo que pasa es que salta el error cuando se procesa:

imagenBMP *bmp=CargarBitmapArchivo(szFile);

Esta función lo que hace es leer los datos del bitmap y funciona bien porque la he probado, es por eso que en un principio pensé que el path y el archivo que vienen en szFile no estaban siendo bien interpretados por fopen (función que se encuentra detro de CargarBitmapArchivo.

Tal vez no es dentro del case CM_ABRIR que tengo que escribir el codigo de mostrar el bitmap en pantalla, no lo se. He intentado escribir ese mismo código en el case CM_PAINT y tampoco funciona bien

Geo

Cita de: "JuanK"

Saludos,
con motivo que Geo me envio su programa con WxWidgets y C++ y me lo paso en versiones linux y windows y funciono OK, me propuse a revisar mejor lo del proyecto Mono asi que trate de ejecutar mis 2 proyectos del reto hechos en C# en un linux ubunto y no me funciono :'(...

la razon resulta que el runtime de mono en el momento solo soporta hasta C# 1.1, el soporte para C# 2.0 aun no esta completo y desde luego mis programas se compilaron con C# 2.0.

Asi que decidi instalar el monodevelop en linux ubuntu , cree un proyecto con mis fuentes de la libreria que hice y la compile... compilo perfecto!!!

Despues procedi a compilar los dos proyectos que hice para el reto, el extra y el de la entrega, el Extra compilo perfecto y funciono perfecto , pero el del reto no porque utiliza cosas de C# 2.0, pude haber instalado el gmcs ( el compilador de mono para c# 2.0) pero no porque eso implicaria invertirle mas tiempo, sin embargo vi la documentacion y verifique que el unico error por el que no compilabara ya esta soportado en C# 2.0 para mono.

Lo mas interesante fue que coji mi libreria y el aplicativo compilado en linux ubuntu con C#1.1 y me lleve el ejecutable tal como se genero en linux y me funciono en windosw XP sin hacerle nada ya que al tener en windows XP instalado el runtime del .net framework 2.0 tengo soporte para todas las versiones anteriores de c# .

Hice la prueba invertida, busque en mi pc algunos proyecto antiguos que tenia de C# 1.1 , un hola mundo y otra aplicacion de consola, y me lleve los exe tal cual a linux ubuntu... funcionaron de inmediadto... de maravilla

Jeje, se me olvidó comentarte

. Cuando me pasaste tu código, lo compilé en Ubuntu instalando monodevelop, la librería compiló sin muchos problemas, el problema fué cuando intenté con tu aplicación principal, chequé documentación y versiones, no recuerdo si era algo con Windows.Forms (y también con las características del 2.0), así que ya no le busqué (te repito, no sé C# aunque poco a poco me voy metiendo

).

Es muy común que en los repositorios no cuentes con las últimas versiones de algún programa/librería, ya que pasan por un proceso de "candidato->estable", aunque hasta ahora desconozco el proceso real de integración de un paquete a Ubuntu y a Debian.

Lo de tu ejecutable que funciona en Windows, era una de las cosas que me preguntaba pues, cuando compilé con mono, vi que le agrega la extensión .exe a los programas, chequé el formato del ejecutable resultante y dice ¡ejecutable de Windows

!

Saludos,
JJ (Geo).

JuanK

claro asi es, de hecho corrobore que cualquier ejecutable compilado en una u otra plataforma corre sin problemas en la otra sn necesidad de compilar de nuevo, salvo problemas de version como los que comente.

Incluso mono te permite generar una version de ejecutable para linux, supongo que para poder ejecutarlos como un programa linux normal sin tener que anteponer la palabra mono.

Danielo

lamentablemente... sigo teniendo problemas con la ruta del bitmap

Mi último intento un poco más coherente y entendible que el anterior

es el siguiente:

Código: Text

 
LRESULT CALLBACK WindowProcedure(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
OPENFILENAME ofn;       // common dialog box structure
static char szFile[260];       // buffer for file name
//HWND hwnd;              // owner window
HANDLE hf;              // file handle
 
// Initialize OPENFILENAME
ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(OPENFILENAME);//sizeof(ofn);
ofn.hwndOwner = hwnd;
ofn.lpstrFile = szFile;
//
// Set lpstrFile[0] to '&#092;0' so that GetOpenFileName does not 
// use the contents of szFile to initialize itself.
//
//ofn.lpstrFile[0] = '&#092;0';
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFilter = &#34;bmp&#092;0*.BMP&#092;0&#34;;
ofn.nFilterIndex = 1;
ofn.lpstrFileTitle = NULL;
ofn.nMaxFileTitle = 0;
ofn.lpstrInitialDir = NULL;
ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
 
 
static HINSTANCE hInstance; // inicializo instancia.
 
HDC hDC;
PAINTSTRUCT ps;     
unsigned long x,y;    
static imagenBMP *bmp;
static bool dibujarBMP=false;
 
 
    switch (msg)                  /* manipulador del mensaje */
    {
        case WM_CREATE:
         hInstance = ((LPCREATESTRUCT)lParam)-&#62;hInstance;
         break;
        case WM_PAINT:      
         if (dibujarBMP){
          //bmp=CargarBitmapArchivo(&#34;E:&#092;&#092;img&#092;&#092;graf1.bmp&#34;);                              
          bmp=CargarBitmapArchivo(szFile);                                        
          hDC = BeginPaint(hwnd, &ps);
          TextOut(hDC, 10, 300, szFile, strlen(szFile));             
          for(y =0;y&#60; getAltoBitmap(bmp); y++){
           for(x = 0; x &#60; getAnchoBitmap(bmp); x++)
             SetPixel(hDC,x,y,getPixelMatrizBMP(y,x,bmp));
          }          
          EndPaint(hwnd, &ps); 
          dibujarBMP=false;
          }  
         break;
        case WM_COMMAND:
           switch(LOWORD(wParam)) {
              case CM_ABRIR:
                // Display the Open dialog box. 
                if (GetOpenFileName(&ofn)==TRUE){ 
                  hf = CreateFile(ofn.lpstrFile, GENERIC_READ,0, (LPSECURITY_ATTRIBUTES) NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL,(HANDLE) NULL);                                                
                  dibujarBMP=true;                                              
                  MessageBox(hwnd,szFile, &#34;Mensaje de prueba&#34;, MB_OK);                  
                }
                break;
              case CM_SALIR:
                 PostQuitMessage(0);    /* envía un mensaje WM_QUIT a la cola de mensajes */
                 break;
           }
           break;   
        case WM_DESTROY:
           PostQuitMessage(0);    /* envía un mensaje WM_QUIT a la cola de mensajes */
           break;
        default:                  /* para los mensajes de los que no nos ocupamos */
           return DefWindowProc(hwnd, msg, wParam, lParam);
    }
    return 0;
}
 

Por lo que he leido necesariamente el código que dibuja el bitmap en pantalla tiene que estar en WM_PAINT, pero para pasarle la ruta del archivo que quiero cargar tengo que controlar con un booleano que se inicializa a true cuando se selecciona el archivo a cargar con GetOpenFileName. Lo que está pasando y siempre me ha pasado y me sigue dando error

es que la variable szFile (que tiene almacenada la ruta del bitmap) no parece llegar al WM_PAINT. Llegue a pensar que podria estar pasando que llegara con caracteres basura, pero aparentemente no es eso, tambien he intentado limpiar la cadena y nada, tampoco funciona una variable global.

Sin embargo, si anulo la linea: bmp=CargarBitmapArchivo(szFile);
y habilito: bmp=CargarBitmapArchivo("E:\\img\\graf1.bmp");
se carga correctamente graf1.bmp y lo mas extraño es que: TextOut(hDC, 10, 300, szFile, strlen(szFile)); muestra en pantalla cualquier ruta que seleccione con
GetOpenFileName. Entonces si el TextOut está mostrando la ruta correctamente, ¿por qué razón no funciona bien szFile?... ya no se que pensar...

JuanK

y le has hecho debug paso a paso?

que cadena esta llegando al propceso del bitmap cuando ocurre el llamado?

JuanK

Ya probaste abriendolo con ofn.lpstrFile?

tambien es conveniente que le hagas un

ZeroMemory (szFile)

o bien un

memset(szFile,'\0',sizeof(szFile))

Ademas debes verificar y estar seguro que la cantidad de caracteres del path , en tu caso nunca supere los 259 caracteres, o bien cambiar la forma en que defines el ancho de la cadena porque esta algo limitado.

Danielo

Cita de: "JuanK"

y le has hecho debug paso a paso?

que cadena esta llegando al propceso del bitmap cuando ocurre el llamado?

si, intenté con el debug que viene con el dev-cpp, previamente habiendo marcado en las opciones del compilador la opción para que generara la información de debug al linkear, el tema es que por más que intento hacerle un watch a la variable szFile o ofn.lpstrFile o a la que sea, no quiere aceptar las variables (al seleccionar añadir watch). Se me ocurrió entonces que tal vez el gdb no era el último y efectivamente, busque entre las actualizaciones y veo que está el GNU gdb 6.3 y el que tenía antes era el 5.1, pero lo actualicé y sigo sin poder hacer watch y sin poder debugear paso a paso, cosa que no sucede si intento debugear cualquier código que corra en DOS.

Citar

que cadena esta llegando al propceso del bitmap cuando ocurre el llamado?

Como no puedo utilizar el debug

lo que hice fue colocar un message box antes de que se haga el llamado al bitmap:

Código: Text

MessageBox(hwnd,szFile, &#34;valor de szFile&#34;, MB_OK);
          bmp=CargarBitmapArchivo(szFile);
 

... y el message box esta desplegando la ruta correctamente al igual que la etiqueta:

Código: Text

TextOut(hDC, 10, 300, szFile, strlen(szFile)); 
 

... que dibuja en pantalla la cadena del path.

Probé con ofn.lpstrFile en lugar de szFile y no se soluciona nada, y tambien haciendo:

Código: Text

ZeroMemory(&szFile, sizeof(szFile)); o memset(szFile,'&#092;0',sizeof(szFile));
 

En este último caso, la cosa empeora porque si agrego alguna de esas líneas de código al correr el ejecutable explota en la línea TextOut(hDC...

Citar

Ademas debes verificar y estar seguro que la cantidad de caracteres del path , en tu caso nunca supere los 259 caracteres, o bien cambiar la forma en que defines el ancho de la cadena porque esta algo limitado.

Si, esto es algo que supongo se podría mejorar, pero por el momento no estoy probando con rutas de más de 259 caracteres, como mucho tendrán unos 20 caracteres, así que no creo que esté fallando por ese lado.

También intenté limpiando (por las dudas) la cadena szFile:

Código: Text

char cadena[strlen(szFile)];  
strncpy(cadena,szFile,strlen(szFile));
cadena[strlen(szFile)]='&#092;0';
 

... y tampoco

Y por el momento eso es todo lo que he intentado, acepto sugerencias, críticas, etc.