Pregunta: ¿Tiene algo que ver el tamaño de una imagen para que TIMAGE la lea o no la lea?.
Me explico. Estoy haciendo un módulo de presentación de fotografías, para poder visualizar diversos formatos de mapas de bits. Utilizo para ello la clase TIMAGE como es lógico (con NViewLib32), pero resulta que los ficheros JPG de más de un mega no los lee ( me da: nWidth=0 y nHeight=0 ). Sin embargo si la achico con un programa de edición de fotos hasta ocupe 700k o por ahí si la lee. Lo mismo ocurre con BMP de más de 5 megas.
¿Hay forma de solventar ese inconveniente (terrible para mi programa por cierto)?
Tamaño de Imagenes
Tamaño de Imagenes
Nos Gusta Programar
No se si lo estroy haciendo mal, pero me da la impresión de que FreeImage está pensada para programar en 32 bits. O al menos, con el XP me da error.
Consigo abrir la librería "manualmente" pero después me da error en la librería GDI32.dll (.Por cierto, FreeImage tiene más de 8 carácteres y no se abre en XP con LoadLibrary ni a tiros. (A 16 bits con ese nombre).
El caso es que tengo un problema de cuidado. Pues con Windows 95,98 y WinMe se pueden abrir la mayoría de gráficos con nViewLib, pero en XP TImage utiliza nViewl16 (16 bits), en lugar de nViewlib (32 bits), pues pasa por la zona:
if ! ( IsWin95() )
::hBitmap = NViewLibLoad( AllTrim( cBmpFile ), ::nProgress )
else
::hBitmap = NViewLib32( AllTrim( cBmpFile ), ::nProgress )
endif
y como no es W95 pues abre nViewl16.
El problema es que con XP, si fuerzo la apertura de nViewlib, estás devuelve handles de más de 10 dígitos, algunos incluso, negativos. He intentado acortarlo con nLowWord(), nHiWord(), con una mezcla de ambos o restando 65536 antes o después de aplicar las funciones. Pero nada de nada. Por fortuna FreeImage me dió la idea de utilizar:
hBmp = nLoWord( WOWHandle16(hBmp, 8 ) ) ¡Y funciona!
El problema es que no lee ni la mitad de gráficos que con nViewl16. Utilizaría nViewl16, el problema es que con esa librería si un gráfico no lo puede leer te saca un mensaje de advertencia. Como mi programa ya tiene su propio sistema de mensajes (muy elaborado) y durante la lectura del albúm muestra un "Espere un momento, Por favor..." pues el programa se queda colgado hasta que se cierre el mensaje de la librería (que casualmente aparece por debajo del mío.).
Y si utilizo nViewlib, no da error si no lee un fichero, pero no lee tantos como con nViewl16. Por ahora he programado una solución de compromiso. Abro lo que puedo con nViewlib y lo demás si no es muy grande con nViewl16 rezando para que no se cuelgue. Será cuestión de advertir al cliente. No deja de ser una solución a medias.
Si alguién tiene alguna idea, le agradecería la ayuda.
Un saludo
Consigo abrir la librería "manualmente" pero después me da error en la librería GDI32.dll (.Por cierto, FreeImage tiene más de 8 carácteres y no se abre en XP con LoadLibrary ni a tiros. (A 16 bits con ese nombre).
El caso es que tengo un problema de cuidado. Pues con Windows 95,98 y WinMe se pueden abrir la mayoría de gráficos con nViewLib, pero en XP TImage utiliza nViewl16 (16 bits), en lugar de nViewlib (32 bits), pues pasa por la zona:
if ! ( IsWin95() )
::hBitmap = NViewLibLoad( AllTrim( cBmpFile ), ::nProgress )
else
::hBitmap = NViewLib32( AllTrim( cBmpFile ), ::nProgress )
endif
y como no es W95 pues abre nViewl16.
El problema es que con XP, si fuerzo la apertura de nViewlib, estás devuelve handles de más de 10 dígitos, algunos incluso, negativos. He intentado acortarlo con nLowWord(), nHiWord(), con una mezcla de ambos o restando 65536 antes o después de aplicar las funciones. Pero nada de nada. Por fortuna FreeImage me dió la idea de utilizar:
hBmp = nLoWord( WOWHandle16(hBmp, 8 ) ) ¡Y funciona!
El problema es que no lee ni la mitad de gráficos que con nViewl16. Utilizaría nViewl16, el problema es que con esa librería si un gráfico no lo puede leer te saca un mensaje de advertencia. Como mi programa ya tiene su propio sistema de mensajes (muy elaborado) y durante la lectura del albúm muestra un "Espere un momento, Por favor..." pues el programa se queda colgado hasta que se cierre el mensaje de la librería (que casualmente aparece por debajo del mío.).
Y si utilizo nViewlib, no da error si no lee un fichero, pero no lee tantos como con nViewl16. Por ahora he programado una solución de compromiso. Abro lo que puedo con nViewlib y lo demás si no es muy grande con nViewl16 rezando para que no se cuelgue. Será cuestión de advertir al cliente. No deja de ser una solución a medias.
Si alguién tiene alguna idea, le agradecería la ayuda.
Un saludo
Nos Gusta Programar