Xailer & OZ Software

Las aplicaciones con Xailer se vuelven "pesadas"... "lentas"... !!!
Igual se debe a xHarbour y no a Xailer, pero expongo aquí el detalle.
Cargamos el Administrador de Taresas de Windows... para visualizar el uso de
memória de la aplicación.
Cojemos como ejemplo el Sample que incluye Xailer MDI.
MdiSample1... lo compilamos y lo ejecutamos fuera del IDE... para que no
intervenga en el rendimiento de la aplicación.
Bien, pues si nos fijamos en la aplicación el uso de la memória se situa en
5052k...
Abrimos un FormNuevo y aumenta a 5188k, lo cerramos y sigue en 5188k...
Abrimos otro Form, otro + + + + + + +... hasta 10 o 15...
A mi me ha aumentado el uso de memória 5592k...
Y los cerramos TODOS...quedándonos solo con el Form MDIPADRE abierto...
PERO... ¿que pasa con el uso de la memória??? pues que me sigue con 5596k
!!!
¿Cuando se libera la memória??? ¿?¿?
Pues hablando por MSN con JoseLuis Capel, me dice... ¿y si minimizas la
aplicación???
Pues... que me baja la memória a 524k... MENOS QUE EN EL INICIO DE LA
APLICACION!!!
Y eso que estamos tratando con una aplicacion MINIMA!!! solo habre y cierra
Forms!!!
Por eso estoy preocupado por mi aplicación... cuando mas crece... mas
"pesada" se vuelve y mas lenta la noto.
Y decir que cuando se trata de imprimir una imagen de fondo que me ocupa
TODA la hoja A4... cuando tengo que imprimir mas de 10 páginas la aplicación
se vuelve "pesadísima" incluso llegando a utilizar mas de 135000k de
memoria... y NO LOS LIBERA!!!
Por lo visto... empieza a liberar memória cuando llega mas o menos a
250000k...
Como sabeis, utilizo también C3... y puedo deciros que el uso de memória de
las aplicaciones que tengo hechas son muy estables, y ese problema no
existe.
¿A quien hay que "picar" para que se ponga a arreglar este "agujero"???
o...
¿Como podemos hacer que nuestras aplicaciones sean mas "lijeras"???
Gracias
Un Saludo,
Xevi.

Saludos Xevi:
Ese mismo planteamiento lo he hecho en forma privada y en el foro
yo en el correo del dí­a 15/09/2006, porque he observado lo mismo que tú
comentas, la contestación está en esos correos, en los cuales se dice
que el Administrador de Memoria de Windows no es fiable, pero resulta
que yo tengo la misma aplicación que ya me funcionaba en Visual Objects
a la cual he añadido algunas mejoras funcionado con Xailer casi toda,
por lo tanto es la misma aplicación y en la ejecución del "exe" de
Visual Objects no necesito casi memoria ni casi aumenta y en cambio el
ejecutable de Xailer aumenta de forma importante, hasta que la cosa se
hace lenta, lo siento pero esa es la verdad, donde está la razón no lo
sé pero sobre todo en unas pruebas que hice los ComboBox y las Explorer
Bar no destruí­an la memoria que utilizaban, y de eso le mandé unos
ejemplos a José F., el cual me contestó que a su modo de ver funcionaban
correctamente, y otra cosa si cierro todos los formularios y solo dejo
el menú principal de la aplicación la memoria no disminuye se queda como
mí­nimo en lo mismo que tení­a, se dice que es para poder utilizar
posteriormente los mismos recursos, ¿pero entonces porque cuando vuelvo
a cargar uno de los formularios abiertos anteriormente vuelve a
aumentar?, por lo tanto no se por donde está la solución, aunque confí­o
en que la encuentren.
Perdonarme por decir esto, trabajar con Xailer se hace ameno y
fácil por lo menos a mí­ que vengo de Visual Objects, y que para poner
una imagen en la Shell hay que armar un buen follón, y es complicado de
saberse mover por él, Xailer en eso le da cien patadas pero en el tema
de estabilidad hasta ahora no.
José Ramón Castro.
Xevi escribió:
> Las aplicaciones con Xailer se vuelven "pesadas"... "lentas"... !!!
>
> Igual se debe a xHarbour y no a Xailer, pero expongo aquí­ el detalle.
>
>
> Cargamos el Administrador de Taresas de Windows... para visualizar el uso de
> memória de la aplicación.
>
> Cojemos como ejemplo el Sample que incluye Xailer MDI.
>
> MdiSample1... lo compilamos y lo ejecutamos fuera del IDE... para que no
> intervenga en el rendimiento de la aplicación.
>
> Bien, pues si nos fijamos en la aplicación el uso de la memória se situa en
> 5052k...
> Abrimos un FormNuevo y aumenta a 5188k, lo cerramos y sigue en 5188k...
> Abrimos otro Form, otro + + + + + + +... hasta 10 o 15...
> A mi me ha aumentado el uso de memória 5592k...
> Y los cerramos TODOS...quedándonos solo con el Form MDIPADRE abierto...
> PERO... ¿que pasa con el uso de la memória??? pues que me sigue con 5596k
> !!!
>
> ¿Cuando se libera la memória??? ¿?¿?
>
> Pues hablando por MSN con JoseLuis Capel, me dice... ¿y si minimizas la
> aplicación???
> Pues... que me baja la memória a 524k... MENOS QUE EN EL INICIO DE LA
> APLICACION!!!
>
> Y eso que estamos tratando con una aplicacion MINIMA!!! solo habre y cierra
> Forms!!!
>
> Por eso estoy preocupado por mi aplicación... cuando mas crece... mas
> "pesada" se vuelve y mas lenta la noto.
> Y decir que cuando se trata de imprimir una imagen de fondo que me ocupa
> TODA la hoja A4... cuando tengo que imprimir mas de 10 páginas la aplicación
> se vuelve "pesadí­sima" incluso llegando a utilizar mas de 135000k de
> memoria... y NO LOS LIBERA!!!
> Por lo visto... empieza a liberar memória cuando llega mas o menos a
> 250000k...
>
> Como sabeis, utilizo también C3... y puedo deciros que el uso de memória de
> las aplicaciones que tengo hechas son muy estables, y ese problema no
> existe.
>
> ¿A quien hay que "picar" para que se ponga a arreglar este "agujero"???
> o...
> ¿Como podemos hacer que nuestras aplicaciones sean mas "lijeras"???
>
>
> Gracias
>
> Un Saludo,
> Xevi.
>
>
>
>
>

José Ramón,
Yo persoalmente me puedo tirar vairas horas trabjando con el IDE de Xailer
que está hecho, como no, con el propio Xailer y funciona de forma súper
estable. No observo esos problemas que comentais.
El administrador de tareas da información sobre el uso de la memoría de cada
aplicación, pero la liberación final es cosa del propio sistema operativo, y
tan sólo se fuerza una destrucción de toda la memoria no necesaría cuando se
minimiza la aplicación. Por lo tanto y en mi opinión, todas aquellas
consideraciones que se hagan viendo los consumos de memoria que devuelva el
administrador de tareas no son válidas.
No me cabe ninguna duda que aquellos de vosotros que decis que las
apliaciones se vuelven lentas, realmente os este ocurriendo, pero tan sólo
puedo deciros que dudo que sean más grandes que el IDE.
Haremos ciertas pruebas con ejemplos que utilicen mucha memoria para ver si
hay realmente consumo indebido. Os agradecería igualmente que intentaseis
hacer pequeños ejemplos que después de un cierto tiempo mostrasen ese
comportamiento lento del que hablais. En concreto, Xevi, me gustaría tener
un ejemplo de impresión de esa imagen.
Gracias de antemano
Un saludo,
"José Ramón Castro Polinio" <jrcpoli@terra.es> wrote in message
news:4515c1eb$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Saludos Xevi:
>
> Ese mismo planteamiento lo he hecho en forma privada y en el foro yo
> en el correo del día 15/09/2006, porque he observado lo mismo que tú
> comentas, la contestación está en esos correos, en los cuales se dice que
> el Administrador de Memoria de Windows no es fiable, pero resulta que yo
> tengo la misma aplicación que ya me funcionaba en Visual Objects a la cual
> he añadido algunas mejoras funcionado con Xailer casi toda, por lo tanto
> es la misma aplicación y en la ejecución del "exe" de Visual Objects no
> necesito casi memoria ni casi aumenta y en cambio el ejecutable de Xailer
> aumenta de forma importante, hasta que la cosa se hace lenta, lo siento
> pero esa es la verdad, donde está la razón no lo sé pero sobre todo en
> unas pruebas que hice los ComboBox y las Explorer Bar no destruían la
> memoria que utilizaban, y de eso le mandé unos ejemplos a José F., el cual
> me contestó que a su modo de ver funcionaban correctamente, y otra cosa si
> cierro todos los formularios y solo dejo el menú principal de la
> aplicación la memoria no disminuye se queda como mínimo en lo mismo que
> tenía, se dice que es para poder utilizar posteriormente los mismos
> recursos, ¿pero entonces porque cuando vuelvo a cargar uno de los
> formularios abiertos anteriormente vuelve a aumentar?, por lo tanto no se
> por donde está la solución, aunque confío en que la encuentren.
>
> Perdonarme por decir esto, trabajar con Xailer se hace ameno y fácil
> por lo menos a mí que vengo de Visual Objects, y que para poner una imagen
> en la Shell hay que armar un buen follón, y es complicado de saberse mover
> por él, Xailer en eso le da cien patadas pero en el tema de estabilidad
> hasta ahora no.
>
> José Ramón Castro.
>
> Xevi escribió:
>> Las aplicaciones con Xailer se vuelven "pesadas"... "lentas"... !!!
>>
>> Igual se debe a xHarbour y no a Xailer, pero expongo aquí el detalle.
>>
>>
>> Cargamos el Administrador de Taresas de Windows... para visualizar el uso
>> de memória de la aplicación.
>>
>> Cojemos como ejemplo el Sample que incluye Xailer MDI.
>>
>> MdiSample1... lo compilamos y lo ejecutamos fuera del IDE... para que no
>> intervenga en el rendimiento de la aplicación.
>>
>> Bien, pues si nos fijamos en la aplicación el uso de la memória se situa
>> en 5052k...
>> Abrimos un FormNuevo y aumenta a 5188k, lo cerramos y sigue en 5188k...
>> Abrimos otro Form, otro + + + + + + +... hasta 10 o 15...
>> A mi me ha aumentado el uso de memória 5592k...
>> Y los cerramos TODOS...quedándonos solo con el Form MDIPADRE abierto...
>> PERO... ¿que pasa con el uso de la memória??? pues que me sigue con 5596k
>> !!!
>>
>> ¿Cuando se libera la memória??? ¿?¿?
>>
>> Pues hablando por MSN con JoseLuis Capel, me dice... ¿y si minimizas la
>> aplicación???
>> Pues... que me baja la memória a 524k... MENOS QUE EN EL INICIO DE LA
>> APLICACION!!!
>>
>> Y eso que estamos tratando con una aplicacion MINIMA!!! solo habre y
>> cierra Forms!!!
>>
>> Por eso estoy preocupado por mi aplicación... cuando mas crece... mas
>> "pesada" se vuelve y mas lenta la noto.
>> Y decir que cuando se trata de imprimir una imagen de fondo que me ocupa
>> TODA la hoja A4... cuando tengo que imprimir mas de 10 páginas la
>> aplicación se vuelve "pesadísima" incluso llegando a utilizar mas de
>> 135000k de memoria... y NO LOS LIBERA!!!
>> Por lo visto... empieza a liberar memória cuando llega mas o menos a
>> 250000k...
>>
>> Como sabeis, utilizo también C3... y puedo deciros que el uso de memória
>> de las aplicaciones que tengo hechas son muy estables, y ese problema no
>> existe.
>>
>> ¿A quien hay que "picar" para que se ponga a arreglar este "agujero"???
>> o...
>> ¿Como podemos hacer que nuestras aplicaciones sean mas "lijeras"???
>>
>>
>> Gracias
>>
>> Un Saludo,
>> Xevi.
>>
>>
>>
>>

Ignacio:
Yo personalmente he probado el comportamiento del IDE de Xailer con el
Administrador de Tareas de Windows y te puedo asegurar que si como decí­s
no es fiable el Administrador de Tareas, ¿porque con el IDE su
comportamiento es perfecto.?
Otra prueba realizada es hacer que el programa ejecutara el mismo
formulario y luego en el mismo ir directamente a la vista previa del
report de Xailer, y también he comprobado que el mismo cuando entra
aumenta la memoria pero cuando sale la destruye, y eso lo puede probar
cualquiera.
Por lo tanto en todos los casos los comportamientos de esas dos partes
de Xailer son correctas y funcionan perfectamente, aun cuando utilicemos
el Administrador de Tareas, que supuestamente no vale.
De lo que estamos hablando es del comportamiento de nuestras
aplicaciones, quizás y será lo más probable, algo estemos haciendo mal o
algo creamos que no destruimos, quizás esa sea la cuestión, pero por eso
me gustarí­a saber si el error es nuestro y poder corregirlo, o por el
contrario esto les ocurre a otros y no lo dicen y los malos de la
pelí­cula somos nosotros que lo decimos, o a lo mejor a ellos no les
ocurre y entonces los equivocados y los que tenemos el error somos
nosotros, y si es así­ yo personalmente lo diré claramente y reconoceré
el mismo, en fin yo personalmente estoy dispuesto a escuchar todo lo que
se diga y en este tema me gustarí­a que los demás dijeran algo.
Que quede claro que esto lo expongo aquí­ porque es un foro privado si
tuviera que exponerlo públicamente o en un lugar donde las
interpretaciones mal intencionadas o deseosas de escucharse, ¡no lo
harí­a nunca!, porque personalmente opino que es más lo que Xailer ofrece
que lo que tiene de problema para mi totalmente corregible.
Otra cosa es que si alguien conoce algún programa que pueda ser
utilizado para testear el uso de la memoria que no se el dichoso
Administrador de Tareas de Windows lo diga.

José Ramón Castro.
Ignacio Ortiz de Zúñiga escribió:
> José Ramón,
>
> Yo persoalmente me puedo tirar vairas horas trabjando con el IDE de Xailer
> que está hecho, como no, con el propio Xailer y funciona de forma súper
> estable. No observo esos problemas que comentais.
>
> El administrador de tareas da información sobre el uso de la memorí­a de cada
> aplicación, pero la liberación final es cosa del propio sistema operativo, y
> tan sólo se fuerza una destrucción de toda la memoria no necesarí­a cuando se
> minimiza la aplicación. Por lo tanto y en mi opinión, todas aquellas
> consideraciones que se hagan viendo los consumos de memoria que devuelva el
> administrador de tareas no son válidas.
>
> No me cabe ninguna duda que aquellos de vosotros que decis que las
> apliaciones se vuelven lentas, realmente os este ocurriendo, pero tan sólo
> puedo deciros que dudo que sean más grandes que el IDE.
>
> Haremos ciertas pruebas con ejemplos que utilicen mucha memoria para ver si
> hay realmente consumo indebido. Os agradecerí­a igualmente que intentaseis
> hacer pequeños ejemplos que después de un cierto tiempo mostrasen ese
> comportamiento lento del que hablais. En concreto, Xevi, me gustarí­a tener
> un ejemplo de impresión de esa imagen.
>
> Gracias de antemano
>
> Un saludo,
>
>
> "José Ramón Castro Polinio" <jrcpoli@terra.es> wrote in message
> news:4515c1eb$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
>> Saludos Xevi:
>>
>> Ese mismo planteamiento lo he hecho en forma privada y en el foro yo
>> en el correo del dí­a 15/09/2006, porque he observado lo mismo que tú
>> comentas, la contestación está en esos correos, en los cuales se dice que
>> el Administrador de Memoria de Windows no es fiable, pero resulta que yo
>> tengo la misma aplicación que ya me funcionaba en Visual Objects a la cual
>> he añadido algunas mejoras funcionado con Xailer casi toda, por lo tanto
>> es la misma aplicación y en la ejecución del "exe" de Visual Objects no
>> necesito casi memoria ni casi aumenta y en cambio el ejecutable de Xailer
>> aumenta de forma importante, hasta que la cosa se hace lenta, lo siento
>> pero esa es la verdad, donde está la razón no lo sé pero sobre todo en
>> unas pruebas que hice los ComboBox y las Explorer Bar no destruí­an la
>> memoria que utilizaban, y de eso le mandé unos ejemplos a José F., el cual
>> me contestó que a su modo de ver funcionaban correctamente, y otra cosa si
>> cierro todos los formularios y solo dejo el menú principal de la
>> aplicación la memoria no disminuye se queda como mí­nimo en lo mismo que
>> tení­a, se dice que es para poder utilizar posteriormente los mismos
>> recursos, ¿pero entonces porque cuando vuelvo a cargar uno de los
>> formularios abiertos anteriormente vuelve a aumentar?, por lo tanto no se
>> por donde está la solución, aunque confí­o en que la encuentren.
>>
>> Perdonarme por decir esto, trabajar con Xailer se hace ameno y fácil
>> por lo menos a mí­ que vengo de Visual Objects, y que para poner una imagen
>> en la Shell hay que armar un buen follón, y es complicado de saberse mover
>> por él, Xailer en eso le da cien patadas pero en el tema de estabilidad
>> hasta ahora no.
>>
>> José Ramón Castro.
>>
>> Xevi escribió:
>>> Las aplicaciones con Xailer se vuelven "pesadas"... "lentas"... !!!
>>>
>>> Igual se debe a xHarbour y no a Xailer, pero expongo aquí­ el detalle.
>>>
>>>
>>> Cargamos el Administrador de Taresas de Windows... para visualizar el uso
>>> de memória de la aplicación.
>>>
>>> Cojemos como ejemplo el Sample que incluye Xailer MDI.
>>>
>>> MdiSample1... lo compilamos y lo ejecutamos fuera del IDE... para que no
>>> intervenga en el rendimiento de la aplicación.
>>>
>>> Bien, pues si nos fijamos en la aplicación el uso de la memória se situa
>>> en 5052k...
>>> Abrimos un FormNuevo y aumenta a 5188k, lo cerramos y sigue en 5188k...
>>> Abrimos otro Form, otro + + + + + + +... hasta 10 o 15...
>>> A mi me ha aumentado el uso de memória 5592k...
>>> Y los cerramos TODOS...quedándonos solo con el Form MDIPADRE abierto...
>>> PERO... ¿que pasa con el uso de la memória??? pues que me sigue con 5596k
>>> !!!
>>>
>>> ¿Cuando se libera la memória??? ¿?¿?
>>>
>>> Pues hablando por MSN con JoseLuis Capel, me dice... ¿y si minimizas la
>>> aplicación???
>>> Pues... que me baja la memória a 524k... MENOS QUE EN EL INICIO DE LA
>>> APLICACION!!!
>>>
>>> Y eso que estamos tratando con una aplicacion MINIMA!!! solo habre y
>>> cierra Forms!!!
>>>
>>> Por eso estoy preocupado por mi aplicación... cuando mas crece... mas
>>> "pesada" se vuelve y mas lenta la noto.
>>> Y decir que cuando se trata de imprimir una imagen de fondo que me ocupa
>>> TODA la hoja A4... cuando tengo que imprimir mas de 10 páginas la
>>> aplicación se vuelve "pesadí­sima" incluso llegando a utilizar mas de
>>> 135000k de memoria... y NO LOS LIBERA!!!
>>> Por lo visto... empieza a liberar memória cuando llega mas o menos a
>>> 250000k...
>>>
>>> Como sabeis, utilizo también C3... y puedo deciros que el uso de memória
>>> de las aplicaciones que tengo hechas son muy estables, y ese problema no
>>> existe.
>>>
>>> ¿A quien hay que "picar" para que se ponga a arreglar este "agujero"???
>>> o...
>>> ¿Como podemos hacer que nuestras aplicaciones sean mas "lijeras"???
>>>
>>>
>>> Gracias
>>>
>>> Un Saludo,
>>> Xevi.
>>>
>>>
>>>
>>>
>

Hola,
Respecto a este tema expongo mi opinión, por si de algo sirve.
- Todas las aplicaciones, no exageradamente grandes, (porque no ha dado
tiempo), realizadas con xailer, la 1ª hace más de 1 año y usándolas a
diario, se han comportado "Super Estables", por lo que de la estabilidad de
xailer no dudo.
- El IDE es un ejemplo de estabilidad y de que "no se pone lento", no he
visto el código pero apostaría que usa casi el 100% del
GUI.
En una aplicación, partimos de una base, en este caso xHB y Xailer, a partir
de ahí, los programadores tecleamos miles de líneas, si practicamente
estamos casi seguros (como ejemplo el IDE), de que la base funciona bien y
estable, casi siempre, en esos miles de líneas podemos hacer cosas
incorrectas, que en un principio no vemos, nadie nos lo reporta porque el
producto es nuevo y usamos conceptos del API de windows que no conocemos o
por lo menos en profundidad. Por Ejemplo la creación y destrucción de
objetos que consumen recursos y que hay que liberar, fonts, brush, imágenes,
etc.
Cada vez más, en windows existen factores que hay conocer para "hacer bien
las cosas". Influyen demasiadas cosas en una aplicación, yo personalmente
analizaría "todo el código incluído por el programador" y si algo no va bien
en la base y lo localizamos, en un pequeño ejemplo (no siempre se puede)
debe "dar el cante". A partir de ahí, con una buena base, casi siempre la
piedra está en nuestro tejado.
Un Saludo,
Joaquín
"José Ramón Castro Polinio" <jrcpoli@terra.es> escribió en el mensaje
news:[email=451644c6@news.xailer.com...]451644c6@news.xailer.com...[/email]
> Ignacio:
>
> Yo personalmente he probado el comportamiento del IDE de Xailer con el
> Administrador de Tareas de Windows y te puedo asegurar que si como decís
> no es fiable el Administrador de Tareas, ¿porque con el IDE su
> comportamiento es perfecto.?
>
> Otra prueba realizada es hacer que el programa ejecutara el mismo
> formulario y luego en el mismo ir directamente a la vista previa del
> report de Xailer, y también he comprobado que el mismo cuando entra
> aumenta la memoria pero cuando sale la destruye, y eso lo puede probar
> cualquiera.
>
> Por lo tanto en todos los casos los comportamientos de esas dos partes de
> Xailer son correctas y funcionan perfectamente, aun cuando utilicemos el
> Administrador de Tareas, que supuestamente no vale.
>
> De lo que estamos hablando es del comportamiento de nuestras aplicaciones,
> quizás y será lo más probable, algo estemos haciendo mal o algo creamos
> que no destruimos, quizás esa sea la cuestión, pero por eso me gustaría
> saber si el error es nuestro y poder corregirlo, o por el contrario esto
> les ocurre a otros y no lo dicen y los malos de la película somos nosotros
> que lo decimos, o a lo mejor a ellos no les ocurre y entonces los
> equivocados y los que tenemos el error somos nosotros, y si es así yo
> personalmente lo diré claramente y reconoceré el mismo, en fin yo
> personalmente estoy dispuesto a escuchar todo lo que se diga y en este
> tema me gustaría que los demás dijeran algo.
>
> Que quede claro que esto lo expongo aquí porque es un foro privado si
> tuviera que exponerlo públicamente o en un lugar donde las
> interpretaciones mal intencionadas o deseosas de escucharse, ¡no lo haría
> nunca!, porque personalmente opino que es más lo que Xailer ofrece que lo
> que tiene de problema para mi totalmente corregible.
>
> Otra cosa es que si alguien conoce algún programa que pueda ser utilizado
> para testear el uso de la memoria que no se el dichoso Administrador de
> Tareas de Windows lo diga.
>
>
> José Ramón Castro.
>
> Ignacio Ortiz de Zúñiga escribió:
>> José Ramón,
>>
>> Yo persoalmente me puedo tirar vairas horas trabjando con el IDE de
>> Xailer que está hecho, como no, con el propio Xailer y funciona de forma
>> súper estable. No observo esos problemas que comentais.
>>
>> El administrador de tareas da información sobre el uso de la memoría de
>> cada aplicación, pero la liberación final es cosa del propio sistema
>> operativo, y tan sólo se fuerza una destrucción de toda la memoria no
>> necesaría cuando se minimiza la aplicación. Por lo tanto y en mi opinión,
>> todas aquellas consideraciones que se hagan viendo los consumos de
>> memoria que devuelva el administrador de tareas no son válidas.
>>
>> No me cabe ninguna duda que aquellos de vosotros que decis que las
>> apliaciones se vuelven lentas, realmente os este ocurriendo, pero tan
>> sólo puedo deciros que dudo que sean más grandes que el IDE.
>>
>> Haremos ciertas pruebas con ejemplos que utilicen mucha memoria para ver
>> si hay realmente consumo indebido. Os agradecería igualmente que
>> intentaseis hacer pequeños ejemplos que después de un cierto tiempo
>> mostrasen ese comportamiento lento del que hablais. En concreto, Xevi, me
>> gustaría tener un ejemplo de impresión de esa imagen.
>>
>> Gracias de antemano
>>
>> Un saludo,
>>
>>
>> "José Ramón Castro Polinio" <jrcpoli@terra.es> wrote in message
>> news:4515c1eb$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
>>> Saludos Xevi:
>>>
>>> Ese mismo planteamiento lo he hecho en forma privada y en el foro yo
>>> en el correo del día 15/09/2006, porque he observado lo mismo que tú
>>> comentas, la contestación está en esos correos, en los cuales se dice
>>> que el Administrador de Memoria de Windows no es fiable, pero resulta
>>> que yo tengo la misma aplicación que ya me funcionaba en Visual Objects
>>> a la cual he añadido algunas mejoras funcionado con Xailer casi toda,
>>> por lo tanto es la misma aplicación y en la ejecución del "exe" de
>>> Visual Objects no necesito casi memoria ni casi aumenta y en cambio el
>>> ejecutable de Xailer aumenta de forma importante, hasta que la cosa se
>>> hace lenta, lo siento pero esa es la verdad, donde está la razón no lo
>>> sé pero sobre todo en unas pruebas que hice los ComboBox y las Explorer
>>> Bar no destruían la memoria que utilizaban, y de eso le mandé unos
>>> ejemplos a José F., el cual me contestó que a su modo de ver funcionaban
>>> correctamente, y otra cosa si cierro todos los formularios y solo dejo
>>> el menú principal de la aplicación la memoria no disminuye se queda como
>>> mínimo en lo mismo que tenía, se dice que es para poder utilizar
>>> posteriormente los mismos recursos, ¿pero entonces porque cuando vuelvo
>>> a cargar uno de los formularios abiertos anteriormente vuelve a
>>> aumentar?, por lo tanto no se por donde está la solución, aunque confío
>>> en que la encuentren.
>>>
>>> Perdonarme por decir esto, trabajar con Xailer se hace ameno y fácil
>>> por lo menos a mí que vengo de Visual Objects, y que para poner una
>>> imagen en la Shell hay que armar un buen follón, y es complicado de
>>> saberse mover por él, Xailer en eso le da cien patadas pero en el tema
>>> de estabilidad hasta ahora no.
>>>
>>> José Ramón Castro.
>>>
>>> Xevi escribió:
>>>> Las aplicaciones con Xailer se vuelven "pesadas"... "lentas"... !!!
>>>>
>>>> Igual se debe a xHarbour y no a Xailer, pero expongo aquí el detalle.
>>>>
>>>>
>>>> Cargamos el Administrador de Taresas de Windows... para visualizar el
>>>> uso de memória de la aplicación.
>>>>
>>>> Cojemos como ejemplo el Sample que incluye Xailer MDI.
>>>>
>>>> MdiSample1... lo compilamos y lo ejecutamos fuera del IDE... para que
>>>> no intervenga en el rendimiento de la aplicación.
>>>>
>>>> Bien, pues si nos fijamos en la aplicación el uso de la memória se
>>>> situa en 5052k...
>>>> Abrimos un FormNuevo y aumenta a 5188k, lo cerramos y sigue en 5188k...
>>>> Abrimos otro Form, otro + + + + + + +... hasta 10 o 15...
>>>> A mi me ha aumentado el uso de memória 5592k...
>>>> Y los cerramos TODOS...quedándonos solo con el Form MDIPADRE abierto...
>>>> PERO... ¿que pasa con el uso de la memória??? pues que me sigue con
>>>> 5596k !!!
>>>>
>>>> ¿Cuando se libera la memória??? ¿?¿?
>>>>
>>>> Pues hablando por MSN con JoseLuis Capel, me dice... ¿y si minimizas la
>>>> aplicación???
>>>> Pues... que me baja la memória a 524k... MENOS QUE EN EL INICIO DE LA
>>>> APLICACION!!!
>>>>
>>>> Y eso que estamos tratando con una aplicacion MINIMA!!! solo habre y
>>>> cierra Forms!!!
>>>>
>>>> Por eso estoy preocupado por mi aplicación... cuando mas crece... mas
>>>> "pesada" se vuelve y mas lenta la noto.
>>>> Y decir que cuando se trata de imprimir una imagen de fondo que me
>>>> ocupa TODA la hoja A4... cuando tengo que imprimir mas de 10 páginas la
>>>> aplicación se vuelve "pesadísima" incluso llegando a utilizar mas de
>>>> 135000k de memoria... y NO LOS LIBERA!!!
>>>> Por lo visto... empieza a liberar memória cuando llega mas o menos a
>>>> 250000k...
>>>>
>>>> Como sabeis, utilizo también C3... y puedo deciros que el uso de
>>>> memória de las aplicaciones que tengo hechas son muy estables, y ese
>>>> problema no existe.
>>>>
>>>> ¿A quien hay que "picar" para que se ponga a arreglar este "agujero"???
>>>> o...
>>>> ¿Como podemos hacer que nuestras aplicaciones sean mas "lijeras"???
>>>>
>>>>
>>>> Gracias
>>>>
>>>> Un Saludo,
>>>> Xevi.
>>>>
>>>>
>>>>
>>>>
>>

Algo parecido al Administrador de Tareas de Windows, he estado utilizando el TuneUp Process Manager, que no lo he usado para lo que aqui exponen si no para poder tirar programas que a veces el de windows no puede terminar.
Saludos.
--
Ramón Zea
ramonzea@yahoo.com
zeasoftware@hotmail.com
zeasoft.movil@hotmail.com

http://www.paginasprodigy.com/zeasoft/
--

Xevi y todos,
Como te puedes imaginar, nosotros somos los primeros interesados en
solucionar los problemas, y más aún un problema de esta índole. Así que,
toda ayuda que nos dé pistas para solucionarlo es bienvenida.
Acabo de hacer varias pruebas con MdiSample1, y no encuentro nada extraño,
salvo claro está, esa manía del administrador de tareas de windows de
mostrar los valores que le da la gana en cada momento. Te cuento:
1) Al ejecutarlo, me ocupa 6.984KB, en mi ordenador
2) No me he limitado a abrir 10 ó 15 ventanas hijas, sino que he dejado los
dedos pegados en <Alt+N> para crear cientos de ventanas (he calculado unas
300). El consumo ha subido a 15.768KB
3) Las he dispuesto en "mosaico" y las he cerrado todas pulsando <Ctrl+F4>:
11.744KB
4) He vuelto a crear unas 300 ventanas: 15.752KB
5) Las he vuelto a cerrar: 10.992KB
6) He "minimizado" el programa: 1.008KB
7) Lo he "restaurado": 2.864KB
8) He vuelto a crear 300 ventanas: 13.228KB
9) Las he cerrado todas: 7.800KB
10) La columna "Uso máximo de memoria" muestra 15.840KB
Por lo tanto (me reitero), este ejemplo se comporta correctamente, excepto
en que se ve claramente que los valores que muestra el administrador de
tareas no son del todo fiables. Parece que cuando el programa libera la
memoria (p.ej. en el paso 3) windows no lo refleja del todo. También es
curioso que cuando se minimiza el programa, la memoria asignada es
anormalmente baja, y al restaurarlo se recupera en parte.
No obstante, tampoco se puede afirmar rotundamente que no se esté perdiendo
memoria. Imaginad p.ej. que se estén perdiendo 40 bytes de memoria (2
hb_items) por cada ventana; pues en cada ciclo de creación y destrucción de
300 ventanas se estarían perdiendo algo menos de 12KB, que es un valor que
no se puede apreciar en el administrador de tareas.
Otra cosa... hay que tener en cuenta cómo funciona el gestor de memoria y el
recolector de basura (GC) de [x]Harbour, ya que determinados procesos pueden
provocar un consumo desmedido de memoria de forma temporal. P.ej., este
inocente código:
LOCAL aMatriz := {}, n
FOR n := 1 TO 100000
AAdd( aMatriz, "Este es el elemento nº " + LTrim( Str( n ) ) )
NEXT
puede provocar precísamente un consumo enorme de memoria, que después es
liberada, pero que causa que si la cantidad de memoria consumida es cercana
o superior a la memoria física del ordenador, pues todo el ordenador se
"congela" para hacer "swapping" de todas las tareas y recuperar algo de
memoria física para continuar el proceso. Y da la impresión de que todo el
ordenador se ha vuelto lento y pesado. El código anterior se puede escribir
de forma que el consumo de memoria esté controlado en todo momento:
LOCAL aMatriz := Array( 100000 ), n
FOR n := 1 TO 100000
aMatriz[ n ] := "Este es el elemento nº " + LTrim( Str( n ) )
NEXT
Y este es sólo un pequeño ejemplo, pero es muy posible que haya otras
situaciones que provoquen efectos similares. Incluso es posible que nosotros
mismos hayamos escrito algo dentro de Xailer que lo provoque. Por eso es tan
importante detectarlo y encontrar la forma de reproducirlo (con algún
ejemplo) para que podamos solucionarlo en su caso.
Y una última cosa... la pérdida de bloques de memoria puede venir del
programa que estés haciendo, de Xailer, de xHarbour, de BCC++ e incluso del
propio windows. Estos últimos días hemos estado estudiando y probando un
sistema que nos permita localizar esas pérdidas, al menos hasta el nivel de
xHarbour (BCC++ y windows quedarían fuera en principio). Esperamos tenerlo
funcionando lo antes posible.
--
Un saludo,
José F. Giménez
http://www.xailer.com

Jose e Ignacio,
antes que nada, agradecer vuestro tiempo, esfuerzo y trabajo en vuestro proyecto... Xailer.
Como muy bien dice Jose Ramon Castro...
"es más lo que Xailer ofrece que lo que tiene de problema para mi totalmente corregible."
Intentaré reproducir, en un ejemplo, el "congelado" en el tema que mas me preocupa... la impresión de la imagen al facturar.
Nosotros, los usuarios de Xailer, como intermediarios de vuestro proyecto y el proyecto final que utilizan nuestros clientes, me atrevo a decir que somos quizás los MAS interesados en que se solucionen problemas de esta í­ndole. Pues cuando recibimos una llamada de uno de nuestros clientes diciendo que se le ha "muerto" el programa... que se le ha "congelado" y el programa no responde,... que le han desaparecido los Labels... No tenemos respuesta alternativa a... cierra la aplicación y vuelve a ejecutarla, pulsa Ctrl+Alt+Del y finaliza la aplicación o reinicia el ordenador... y la verdad... no son respuestas que me gusten dar, pero no puedo hacer mas por solucionarle el caso puntual.
OJO... NO estoy diciendo que me llaman mis clientes constantemente, NO es un "problema" constante... sinó que es un caso puntual, aleatorio, casual, de difí­cil pero posible solución.
Por cierto, el tema del refresco de los Labels y los Edits funciona perfectamente añadiendo los últimos OBJs del hilo "Problema con el lí­mite de la Memoria y su control" del 15/09/2006.
Gracias.
Un Saludo,
Xevi.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> ha escrit al missatge del grup de discussió: 4516ad66$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Xevi y todos,
>
> Como te puedes imaginar, nosotros somos los primeros interesados en
> solucionar los problemas, y más aún un problema de esta í­ndole. Así­ que,
> toda ayuda que nos dé pistas para solucionarlo es bienvenida.
>
> Acabo de hacer varias pruebas con MdiSample1, y no encuentro nada extraño,
> salvo claro está, esa maní­a del administrador de tareas de windows de
> mostrar los valores que le da la gana en cada momento. Te cuento:
>
> 1) Al ejecutarlo, me ocupa 6.984KB, en mi ordenador
> 2) No me he limitado a abrir 10 ó 15 ventanas hijas, sino que he dejado los
> dedos pegados en <Alt+N> para crear cientos de ventanas (he calculado unas
> 300). El consumo ha subido a 15.768KB
> 3) Las he dispuesto en "mosaico" y las he cerrado todas pulsando <Ctrl+F4>:
> 11.744KB
> 4) He vuelto a crear unas 300 ventanas: 15.752KB
> 5) Las he vuelto a cerrar: 10.992KB
> 6) He "minimizado" el programa: 1.008KB
> 7) Lo he "restaurado": 2.864KB
> 8) He vuelto a crear 300 ventanas: 13.228KB
> 9) Las he cerrado todas: 7.800KB
> 10) La columna "Uso máximo de memoria" muestra 15.840KB
>
> Por lo tanto (me reitero), este ejemplo se comporta correctamente, excepto
> en que se ve claramente que los valores que muestra el administrador de
> tareas no son del todo fiables. Parece que cuando el programa libera la
> memoria (p.ej. en el paso 3) windows no lo refleja del todo. También es
> curioso que cuando se minimiza el programa, la memoria asignada es
> anormalmente baja, y al restaurarlo se recupera en parte.
>
> No obstante, tampoco se puede afirmar rotundamente que no se esté perdiendo
> memoria. Imaginad p.ej. que se estén perdiendo 40 bytes de memoria (2
> hb_items) por cada ventana; pues en cada ciclo de creación y destrucción de
> 300 ventanas se estarí­an perdiendo algo menos de 12KB, que es un valor que
> no se puede apreciar en el administrador de tareas.
>
> Otra cosa... hay que tener en cuenta cómo funciona el gestor de memoria y el
> recolector de basura (GC) de [x]Harbour, ya que determinados procesos pueden
> provocar un consumo desmedido de memoria de forma temporal. P.ej., este
> inocente código:
>
> LOCAL aMatriz := {}, n
> FOR n := 1 TO 100000
> AAdd( aMatriz, "Este es el elemento nº " + LTrim( Str( n ) ) )
> NEXT
>
> puede provocar precí­samente un consumo enorme de memoria, que después es
> liberada, pero que causa que si la cantidad de memoria consumida es cercana
> o superior a la memoria fí­sica del ordenador, pues todo el ordenador se
> "congela" para hacer "swapping" de todas las tareas y recuperar algo de
> memoria fí­sica para continuar el proceso. Y da la impresión de que todo el
> ordenador se ha vuelto lento y pesado. El código anterior se puede escribir
> de forma que el consumo de memoria esté controlado en todo momento:
>
> LOCAL aMatriz := Array( 100000 ), n
> FOR n := 1 TO 100000
> aMatriz[ n ] := "Este es el elemento nº " + LTrim( Str( n ) )
> NEXT
>
> Y este es sólo un pequeño ejemplo, pero es muy posible que haya otras
> situaciones que provoquen efectos similares. Incluso es posible que nosotros
> mismos hayamos escrito algo dentro de Xailer que lo provoque. Por eso es tan
> importante detectarlo y encontrar la forma de reproducirlo (con algún
> ejemplo) para que podamos solucionarlo en su caso.
>
> Y una última cosa... la pérdida de bloques de memoria puede venir del
> programa que estés haciendo, de Xailer, de xHarbour, de BCC++ e incluso del
> propio windows. Estos últimos dí­as hemos estado estudiando y probando un
> sistema que nos permita localizar esas pérdidas, al menos hasta el nivel de
> xHarbour (BCC++ y windows quedarí­an fuera en principio). Esperamos tenerlo
> funcionando lo antes posible.
>
> --
> Un saludo,
>
> José F. Giménez
> http://www.xailer.com
>
>
>
--

Aquí­ teneis un ejemplo que muestra lo que comento sobre imprimir una imagen que ocupa toda la página de un A4.
http://es.geocities.com/aplicacionsdesoftware/Prova.zip
Compilamos y cerramos el IDE.
Ejecutamos la aplicación y mandamos a imprimir una página... funciona perfectamente.
Si mandamos a imprimir 5 páginas, igual... funciona perfectamente.
Ahora le mandamos a imprimir 8... y de momento funciona perfecto.
Pero... mandémosle a imprimir 10... cuando el ProgresBar llega a 6 o 7... se me "congela" TODO el sistema, y las últimas 3 o cuatro páginas se hacen muy "pesadas".
No digamos si le mando a imprimir 50!!! las primeras 6 o 8 bien, pero las restantes se hacen ETERNAS!!! cada página tarda mas!!!
Si abro el Administrador de Tareas para hacer el seguimiento de objetos GDI y Uso de Memoria, se aprecia como el uso de memoria se vuelve "loco" al procesar la página 6 o 8 en adelante.
Cuando arranca la aplicación, 37 GDI y 5456k.
al imprimir 1 página 88 GDIs y 59456k, cerramos el preview y se quedan 68 GDIs y 33824k.
al imprimir 5 página 118 GDIs y 291460k, cerramos el preview y se quedan 90 GDIs y 163644k.
al imprimir 10 página 150 GDIs y 678604k, cerramos el preview y se quedan 112 GDIs y 423128k.
al imprimir 15 por lo visto al llegar a la impresion de 5, 6 o 8 empieza a trabajar el recolector de basura y hace vaciado de memoria, y es ahí­ donde se hace "pesada" la aplicación" termina el proceso con 187 GDIs y 45004k, cerramos el preview y se quedan 139 GDIs y 9388k.
Por lo visto, los GDIs siempre aumentan... y el uso de la memoria se hace "pesada" cuando el proceso es "grandote"
Ah, y me ha "ralentizado" TODO mi Windows... tengo que volver a reiniciar el sistema!!!
¿Hago algo mal??
Gracias.
Un Saludo,
Xevi.
"Xevi" <xevicomas@gmail.com> ha escrit al missatge del grup de discussió: [email=4516c2ad@news.xailer.com...]4516c2ad@news.xailer.com...[/email]
Jose e Ignacio,
antes que nada, agradecer vuestro tiempo, esfuerzo y trabajo en vuestro proyecto... Xailer.
Como muy bien dice Jose Ramon Castro...
"es más lo que Xailer ofrece que lo que tiene de problema para mi totalmente corregible."
Intentaré reproducir, en un ejemplo, el "congelado" en el tema que mas me preocupa... la impresión de la imagen al facturar.
Nosotros, los usuarios de Xailer, como intermediarios de vuestro proyecto y el proyecto final que utilizan nuestros clientes, me atrevo a decir que somos quizás los MAS interesados en que se solucionen problemas de esta í­ndole. Pues cuando recibimos una llamada de uno de nuestros clientes diciendo que se le ha "muerto" el programa... que se le ha "congelado" y el programa no responde,... que le han desaparecido los Labels... No tenemos respuesta alternativa a... cierra la aplicación y vuelve a ejecutarla, pulsa Ctrl+Alt+Del y finaliza la aplicación o reinicia el ordenador... y la verdad... no son respuestas que me gusten dar, pero no puedo hacer mas por solucionarle el caso puntual.
OJO... NO estoy diciendo que me llaman mis clientes constantemente, NO es un "problema" constante... sinó que es un caso puntual, aleatorio, casual, de difí­cil pero posible solución.
Por cierto, el tema del refresco de los Labels y los Edits funciona perfectamente añadiendo los últimos OBJs del hilo "Problema con el lí­mite de la Memoria y su control" del 15/09/2006.
Gracias.
Un Saludo,
Xevi.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> ha escrit al missatge del grup de discussió: 4516ad66$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Xevi y todos,
>
> Como te puedes imaginar, nosotros somos los primeros interesados en
> solucionar los problemas, y más aún un problema de esta í­ndole. Así­ que,
> toda ayuda que nos dé pistas para solucionarlo es bienvenida.
>
> Acabo de hacer varias pruebas con MdiSample1, y no encuentro nada extraño,
> salvo claro está, esa maní­a del administrador de tareas de windows de
> mostrar los valores que le da la gana en cada momento. Te cuento:
>
> 1) Al ejecutarlo, me ocupa 6.984KB, en mi ordenador
> 2) No me he limitado a abrir 10 ó 15 ventanas hijas, sino que he dejado los
> dedos pegados en <Alt+N> para crear cientos de ventanas (he calculado unas
> 300). El consumo ha subido a 15.768KB
> 3) Las he dispuesto en "mosaico" y las he cerrado todas pulsando <Ctrl+F4>:
> 11.744KB
> 4) He vuelto a crear unas 300 ventanas: 15.752KB
> 5) Las he vuelto a cerrar: 10.992KB
> 6) He "minimizado" el programa: 1.008KB
> 7) Lo he "restaurado": 2.864KB
> 8) He vuelto a crear 300 ventanas: 13.228KB
> 9) Las he cerrado todas: 7.800KB
> 10) La columna "Uso máximo de memoria" muestra 15.840KB
>
> Por lo tanto (me reitero), este ejemplo se comporta correctamente, excepto
> en que se ve claramente que los valores que muestra el administrador de
> tareas no son del todo fiables. Parece que cuando el programa libera la
> memoria (p.ej. en el paso 3) windows no lo refleja del todo. También es
> curioso que cuando se minimiza el programa, la memoria asignada es
> anormalmente baja, y al restaurarlo se recupera en parte.
>
> No obstante, tampoco se puede afirmar rotundamente que no se esté perdiendo
> memoria. Imaginad p.ej. que se estén perdiendo 40 bytes de memoria (2
> hb_items) por cada ventana; pues en cada ciclo de creación y destrucción de
> 300 ventanas se estarí­an perdiendo algo menos de 12KB, que es un valor que
> no se puede apreciar en el administrador de tareas.
>
> Otra cosa... hay que tener en cuenta cómo funciona el gestor de memoria y el
> recolector de basura (GC) de [x]Harbour, ya que determinados procesos pueden
> provocar un consumo desmedido de memoria de forma temporal. P.ej., este
> inocente código:
>
> LOCAL aMatriz := {}, n
> FOR n := 1 TO 100000
> AAdd( aMatriz, "Este es el elemento nº " + LTrim( Str( n ) ) )
> NEXT
>
> puede provocar precí­samente un consumo enorme de memoria, que después es
> liberada, pero que causa que si la cantidad de memoria consumida es cercana
> o superior a la memoria fí­sica del ordenador, pues todo el ordenador se
> "congela" para hacer "swapping" de todas las tareas y recuperar algo de
> memoria fí­sica para continuar el proceso. Y da la impresión de que todo el
> ordenador se ha vuelto lento y pesado. El código anterior se puede escribir
> de forma que el consumo de memoria esté controlado en todo momento:
>
> LOCAL aMatriz := Array( 100000 ), n
> FOR n := 1 TO 100000
> aMatriz[ n ] := "Este es el elemento nº " + LTrim( Str( n ) )
> NEXT
>
> Y este es sólo un pequeño ejemplo, pero es muy posible que haya otras
> situaciones que provoquen efectos similares. Incluso es posible que nosotros
> mismos hayamos escrito algo dentro de Xailer que lo provoque. Por eso es tan
> importante detectarlo y encontrar la forma de reproducirlo (con algún
> ejemplo) para que podamos solucionarlo en su caso.
>
> Y una última cosa... la pérdida de bloques de memoria puede venir del
> programa que estés haciendo, de Xailer, de xHarbour, de BCC++ e incluso del
> propio windows. Estos últimos dí­as hemos estado estudiando y probando un
> sistema que nos permita localizar esas pérdidas, al menos hasta el nivel de
> xHarbour (BCC++ y windows quedarí­an fuera en principio). Esperamos tenerlo
> funcionando lo antes posible.
>
> --
> Un saludo,
>
> José F. Giménez
> http://www.xailer.com
>
>
>
--

/*
* Proyecto: Prova
* Fichero: Form1.prg
* Descripción:
* Autor:
* Fecha: 24/09/2006
*/
#include "Xailer.ch"
CLASS TForm1 FROM TForm
COMPONENT oButton1
COMPONENT oEdit1
COMPONENT oLabel1
COMPONENT oProgressBar1
METHOD CreateForm()
METHOD Button1Click( oSender )
ENDCLASS
#include "Form1.xfm"
//---------------------------------------------------------- --------------------
METHOD Button1Click( oSender ) CLASS TForm1
LOCAL n
If ::oEdit1:Value > 0
Application:lBusy := .T.
Printer:lPreview := .T.
* Printer:lPreviewModal := .T.
Printer:nPreviewShowMode := smMAXIMIZE
Printer:nPrintQuality := DMRES_HIGH
Printer:cJobTitle := "[Factura]"
Printer:nOrientation := DMORIENT_PORTRAIT
Printer:StartDoc()
Printer:oCanvas:nMapMode := mmHIMETRICS
::oProgressBar1:nMax := ::oEdit1:Value
For n:=1 to ::oEdit1:Value
::oProgressBar1:nValue := n
Printer:StartPage()
** Poner la imagen de fondo
CreaImagen()
//Printer:oCanvas:DrawPicture( { 0, 0, 2100, 2970 }, TPicture():Load( "Factura.jpg" ) )
Printer:EndPage()
Next
Printer:EndDoc()
Application:lBusy := .F.
Printer:Preview()
::oProgressBar1:nValue := 0
EndIf
RETURN Nil
//---------------------------------------------------------- --------------------
PROCEDURE CreaImagen()
LOCAL oJpg := TPicture():LoadFromFile("Factura.jpg")

Printer:oCanvas:DrawPicture( {0, 0, 2100, 2970 }, oJpg )
oJpg:Destroy()
RETURN
--

This is a multi-part message in MIME format.
------=_NextPart_000_0068_01C6E09B.49DDC060
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0069_01C6E09B.49DDC060"
------=_NextPart_001_0069_01C6E09B.49DDC060
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Xevi,
Aqu=ED teneis un ejemplo que muestra lo que comento sobre imprimir una =
imagen que ocupa toda la p=E1gina de un A4.
Gracias por el ejemplo.
Ejecutamos la aplicaci=F3n y mandamos a imprimir una p=E1gina... =
funciona perfectamente.
Si mandamos a imprimir 5 p=E1ginas, igual... funciona perfectamente.
Ahora le mandamos a imprimir 8... y de momento funciona perfecto.
Pero... mand=E9mosle a imprimir 10... cuando el ProgresBar llega a 6 o =
7... se me "congela" TODO el sistema, y las =FAltimas 3 o cuatro =
p=E1ginas se hacen muy "pesadas".
No digamos si le mando a imprimir 50!!! las primeras 6 o 8 bien, pero =
las restantes se hacen ETERNAS!!! cada p=E1gina tarda mas!!!
Efect=EDvamente, se est=E1 desbordando la memoria f=EDsica, y windows =
tiene que ir quitando memoria a todos los procesos para darsela al =
programa. Al quitarle memoria a los dem=E1s procesos, windows tiene que =
salvar a disco toda esa memoria, y eso es lo que lo hace tan tan =
leeeeento.
Si abro el Administrador de Tareas para hacer el seguimiento de =
objetos GDI y Uso de Memoria, se aprecia como el uso de memoria se =
vuelve "loco" al procesar la p=E1gina 6 o 8 en adelante.
Cuando arranca la aplicaci=F3n, 37 GDI y 5456k.
al imprimir 1 p=E1gina 88 GDIs y 59456k, cerramos el preview y se =
quedan 68 GDIs y 33824k.
al imprimir 5 p=E1gina 118 GDIs y 291460k, cerramos el preview y se =
quedan 90 GDIs y 163644k.
al imprimir 10 p=E1gina 150 GDIs y 678604k, cerramos el preview y se =
quedan 112 GDIs y 423128k.
al imprimir 15 por lo visto al llegar a la impresion de 5, 6 o 8 =
empieza a trabajar el recolector de basura y hace vaciado de memoria, y =
es ah=ED donde se hace "pesada" la aplicaci=F3n" termina el proceso con =
187 GDIs y 45004k, cerramos el preview y se quedan 139 GDIs y 9388k.
Por lo visto, los GDIs siempre aumentan... y el uso de la memoria se =
hace "pesada" cuando el proceso es "grandote"
Bueno, el tema de los objetos GDI no veo que sea ning=FAn problema. Se =
est=E1n consumiendo los que se usan realmente.
Ah, y me ha "ralentizado" TODO mi Windows... tengo que volver a =
reiniciar el sistema!!!
En realidad no necesitas reiniciar; s=F3lo tienes que dejarle tiempo =
para recuperarse.
=BFHago algo mal??
Hay varias cosas que no est=E1n bien o que ser=EDa mejor hacerlas de =
otra forma:
1) Est=E1s cargando una copia de la imagen por cada p=E1gina, que =
adem=E1s no liberas. Lo correcto es cargar una sola copia de la imagen y =
destruirla al final. En el proyecto adjunto lo puedes ver.
2) El formato jpeg no es prec=EDsamente el m=E1s adecuado para lo que =
est=E1s haciendo. De hecho, si lo conviertes a gif y lo pruebas ver=E1s =
que va mejor, aunque sigue siendo un formato poco adecuado. Piensa que =
aunque tu veas que el fichero .jpg ocupa s=F3lo 345KB, al pintarlo en el =
canvas se convierte en bitmap, que a ese tama=F1o ocupa casi 25MB. =
Vamos, que en cada p=E1gina estas cargando 345KB + 25MB al descomprimir =
la imagen en memoria + otros 25MB al pegarla en el canvas (en formato =
emf). En el caso de usar un gif, el tama=F1o de la imagen descomprimida =
es de unos 8MB, debido a que s=F3lo almacena 1 byte por pixel (256 =
colores) frente a los 4 bytes por pixel (16,8 millones de colores) del =
jpeg.
3) El formato ideal para la plantilla es emf, que puedes hacerlo con =
corel, freehand, ilustrator o alg=FAn otro programa de dibujo vectorial =
similar. Yo he hecho la plantilla de tu ejemplo en emf (no est=E1 =
perfecta porque la he hecho r=E1pido como ejemplo) y ver=E1s que ocupa =
unos 10KB. Pero lo mejor es que despu=E9s, en memoria, sigue ocupando =
esos 10KB. Prueba el ejemplo y ver=E1s que puedes imprimir 99 p=E1ginas =
sin problema y con un consumo de memoria muy reducido. Adem=E1s, al ser =
emf un formato vectorial, puedes ampliarlo todo lo que quieras sin =
perder nada de calidad (prueba a hacer zoom en ambos casos y ver=E1s lo =
que digo).
--=20
Un saludo,
Jos=E9 F. Gim=E9nez
http://www.xailer.com
------=_NextPart_001_0069_01C6E09B.49DDC060
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-comoffice"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Xevi,</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV><FONT face=3DArial size=3D2>Aqu=ED teneis un ejemplo =
queÂmuestra lo que=20
comentoÂsobre imprimir una imagen que ocupa toda la p=E1gina de =
un=20
A4.</FONT></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Gracias por el =
ejemplo.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>Â</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV><FONT face=3DArial size=3D2>Ejecutamos la aplicaci=F3n y mandamos =
a imprimir=20
una p=E1gina... funciona perfectamente.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Si mandamos a imprimir 5 p=E1ginas, =
igual...=20
funciona perfectamente.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ahora le mandamos a imprimir 8... y =
de momento=20
funciona perfecto.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Pero... mand=E9mosle a imprimir 10... =
cuando el=20
ProgresBar llega a 6 o 7... se me "congela" TODO el sistema, y las =
=FAltimas 3 o=20
cuatro p=E1ginas se hacen muy "pesadas".</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>No digamos si le mando a imprimir =
50!!! las=20
primeras 6 o 8 bien, pero las restantes se hacen ETERNAS!!! cada =
p=E1gina tarda=20
mas!!!</FONT></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Efect=EDvamente, se est=E1 =
desbordando la=20
memoria f=EDsica, y windows tiene que ir quitando memoria a todos los =
procesos=20
para darsela al programa. Al quitarle memoria a los dem=E1s procesos, =
windows=20
tiene que salvar a disco toda esa memoria, y eso es lo que lo hace tan =
tan=20
leeeeento.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>Â</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV><FONT face=3DArial size=3D2>Si abro el Administrador de Tareas =
para hacer el=20
seguimiento de objetos GDI y Uso de Memoria, se aprecia como el uso de =
memoria=20
se vuelve "loco" al procesar la p=E1gina 6 o 8 en =
adelante.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>Â</DIV>
<DIV><FONT face=3DArial size=3D2>Cuando arranca la aplicaci=F3n, 37 =
GDI y=20
5456k.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>al imprimir 1 p=E1gina 88 GDIs y =
59456k, cerramos=20
el preview y se quedan 68 GDIs y 33824k.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>al imprimirÂ5 p=E1gina 118 GDIs =
y 291460k,=20
cerramos el preview y se quedanÂ90 GDIs y=20
163644k.</FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>al imprimir 10 p=E1ginaÂ150 GDIs =
y 678604k,=20
cerramos el preview y se quedanÂ112 GDIs y=20
423128k.</FONT></DIV></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>al imprimir 15 por lo visto al llegar =
a la=20
impresion de 5, 6 o 8 empieza a trabajar el recolector de basura y =
hace=20
vaciado de memoria, y es ah=ED donde se hace "pesada" la aplicaci=F3n" =
termina el=20
proceso con 187 GDIs y 45004k, cerramos el preview y se quedan 139 =
GDIs y=20
9388k.</FONT></DIV>
<DIV></FONT>Â</DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Por lo visto, los GDIs siempre =
aumentan... y el=20
uso de la memoria se hace "pesada" cuando el proceso es=20
"grandote"</FONT></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Bueno, el tema de los objetos =
GDI no veo=20
que sea ning=FAn problema. Se est=E1n consumiendo los que se usan=20
realmente.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>Â</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV><FONT face=3DArial size=3D2>Ah, y me ha "ralentizado" TODO mi =
Windows...=20
tengo que volver a reiniciar el sistema!!!</FONT></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>En realidad no necesitas =
reiniciar; s=F3lo=20
tienes que dejarle tiempo para recuperarse.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>Â</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV><FONT face=3DArial size=3D2>=BFHago algo =
mal??</FONT></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Hay varias cosas que no =
est=E1n bien o que=20
ser=EDa mejor hacerlas de otra forma:</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>Â</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>1) Est=E1s cargando una copia =
de la imagen=20
por cada p=E1gina, que adem=E1s no liberas. Lo correcto es cargar una =
sola copia de=20
la imagen y destruirla al final. En el proyecto adjunto lo puedes=20
ver.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>Â</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>2) El formato jpeg no es =
prec=EDsamente el=20
m=E1s adecuado para lo que est=E1s haciendo. De hecho, si lo conviertes =
a gif y lo=20
pruebas ver=E1s que va mejor, aunque sigue siendo un formato poco =
adecuado. Piensa=20
que aunque tu veas que el fichero .jpg ocupa s=F3lo 345KB, al pintarlo =
en el=20
canvas se convierte en bitmap, que a ese tama=F1o ocupa casi 25MB. =
Vamos, que en=20
cada p=E1gina estas cargando 345KB + <FONT face=3DArial =
size=3D2></FONT>25MB al=20
descomprimir la imagen en memoria + otros 25MB al pegarla en el canvas =
(en=20
formato emf). En el caso de usar un gif, el tama=F1o de la imagen =
descomprimida es=20
de unos 8MB, debido a que s=F3lo almacena 1 byte por pixel (256 colores) =
frente a=20
los 4 bytes por pixel (16,8 millones de colores) del jpeg.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>Â</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>3) El formato ideal para la =
plantilla es=20
emf, que puedes hacerlo con corel, freehand, ilustratorÂo alg=FAn =
otro=20
programa de dibujo vectorial similar. Yo he hecho la plantilla de tu =
ejemplo en=20
emf (no est=E1 perfecta porque la he hecho r=E1pido como ejemplo) y =
ver=E1s que ocupa=20
unos 10KB. Pero lo mejor es que despu=E9s, en memoria, sigue ocupando =
esos 10KB.=20
Prueba el ejemplo y ver=E1s que puedes imprimir 99 p=E1ginas sin =
problema y con un=20
consumo de memoria muy reducido. Adem=E1s, al ser emf un formato =
vectorial, puedes=20
ampliarlo todo lo que quieras sin perder nada de calidad (prueba a hacer =
zoom en=20
ambos casos y ver=E1s lo que digo).</FONT></DIV><FONT face=3DArial =
size=3D2>
<DIV dir=3Dltr><BR>-- <BR>Un saludo,</DIV>
<DIV>Â</DIV>
<DIV dir=3Dltr>Jos=E9 F. Gim=E9nez<BR><A=20
href=3D"http://www.xailer.com">http://www.xailer.com</A></FONT></DIV></BO=
DY></HTML>
------=_NextPart_001_0069_01C6E09B.49DDC060--
------=_NextPart_000_0068_01C6E09B.49DDC060
Content-Type: application/octet-stream;
name="Prova.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="Prova.zip"
UEsDBBQAAAAIAAZVOTU7J/IJ+AUAAJQoAAALAAAARmFjdHVyYS5lbWbtWm1M HEUYfvd2ubtSuNCz
VVKJRaRCa0BMiVSoEbiDWCOUIjSNkVp6QGnkSzg8alD4UROkNumP/tBgGhKN kaLRH7Wp0R82ramm
NoRoTapNS9Smxo9wpvSPWvGZ3dmP2729nghJOZjkuZl33pnZd2afeefjViCi QdLDWpEoIOnycBXR
eDtRZkVVJZFAR3KJLqFSEnTJQJtSTM7IRN1S6L4gU/hBotJUkXzUSd3UjDoV VEWVsmoVkAK4eXtp
hmoruCwwxKFPMelXmvR3sDI8fT+QIacjQ3bOBlpvKFfCbbtba1sZn4e5vFa0 yAiqrIdHeTtbeFwK
pFvHXXu2C68lNw5712fdE9PedUCBoNuzTbDKyUzWyjPZxl5Nr7azMPZuF3V7 nKJVLjHZW2Jnr6ZX
25l/e4scRGMG+yTRKu9kslaeyTb2anrezgLYW4j234sYT6tcL8t6+Xo7ezU9 byeGvbVAl6Ckb8zO
zhptPszy5TqOrDJ4iH3UCB+xOMIe50OU6eoguuClf4YnQ0QdFEb/VN0riDdD NzY0GdqC+OZHk6G8
E5Mh6Fifa1i5tHAbrYauZsoLyUtHpG9CBSgzi8DKnvtggjzOZOq/7EV7Svj+ xITcfh/qnUT+ceBN
oOkF+fXoHNDTTDGYw9+bw8AXrTzP9xrqprM0L3cnS/O8VWqZ/+jDb+Wjszlg 6mNyxNP9Nzz+7Eee
9jP76oBRxkUIu8C51xA/hxiRJXiAJ015szy0Il0OrvVgTcoE69qpCytUD3L2 gH/Ncn+cBogMvE8u
PV/X8z7cB2Sa+6CnrX00paV5GEev+j61dygH9R3q75w/PNq8dRjKpCI/0Th1 dtrjd296VuNUF+dU
N/OBiAdsOOWMwamdSG+lfNoBlAEqZ1w8dic4RxQ/r+TPLKifD4ofdgXFqdag vOO6uebeDcZx/7+h
7VsvpQAsHPjydTrQ/gaNea8EWF7fscEAG71jLIy/XWqs17U5o4wnVf1nRv2A Z8ChrNkvB1g7NfDf
dUDL++HQ3/5TDvaOCtxZJPC4Fbqjn4RDabyPbAQHL1j9vMNmToo2c1K8Tefk 52c8/oyiFnVOyvwo
gXAIBu9GPGIzJ5NizUm5rW1AmVzGpfrwBJyPomk+Jho/Lp/e5F+z46TPyI8J CM2oNIO4R1jmx1Lm
x7pLkn/k4nGNH02Ak+0TUSkTcZuJH9f5GiXF4Adrp0a+ueiVbZc4NwT+jD42 fmwPys7DiPebnjGN
NlJZnRjPeAbpeurAmhikRrY2snFS6kTsIaRlPi4qPj5f+JPvq691Ph4GxgWF j1cFKx9/5HxcGYMr
jNPbwcVG8CXIGRMEGzqNZxOdO5Y9qGTg7hDwrqBw95pg5e4U525yDHt2I11N f+L8lA8rHue3fD2y
LU5eV1KereSpc2iZy4uKyxfzm32f5ulrbz9wBmhi98FAt4k7VziX3bfwez6s vdX4rYCXrcMv74Mc
r+Cxe5kvi44vZ68dKhdP675vCNhIiu8LkI3vi8PX1MK7tADd9DM8YEA+R+p+ RY9dBl/oMPm8HFJ8
3l6au8/rBAv9+A1QL3xfM/PG2rPdJj+czNJLgMPq+V9c8Hte6/k/2vuYa4h1 /g9ftT//v/jUxlPR
zv+pUc7/aCfy/F839/O/aOMzJBufId2mPqO3+KXy8K/DPuOd3AOsvqD8h5Bu mqu/gWPx3MnJ+xPZ
Z3Qq97rqnEzAPbVkmpOJxpH+J/4qz80+GHHG6+YceTUKR2biPOP55X10o+K7 E/A+P9F50XC+3ecv
PBixP/2O88IhRPEdce9PHwTaaB9fU9zKmGmxQ13rl/myqPiyv+iob+at4Qg/ UsC/h6gE7pqjH6mh
KdqLs7A7Qfd8ic6L+nO/+96ZHtF40QecR4U84Beg2MSLPxgv4rjfqwYntgKV QDHvg2S4n0laAnsR
9bsVKcZ3K5LNd0H7BeN3Kla5wfRdUIPdd0GaXm/Hzva52jsqRH63dD2KvMtg 7yiT7ezV9Go7828v
+46n1mDfxxaZj69WPsb4anreTgx7PcBqbmMaT/8LUEsDBBQAAgAIAO6dODXV NOXuZgEAAEYCAAAJ
AAAAUHJvdmEueHBqVVLLboMwELwj8Q/9AtT0bqltSFSqEBCgtlLUg4ENcWNs a21Hyd93DUmVcmFn
dtjXsCur4n21bL7jqLkYYHCGOErBdiiME1qxOCq8M96xEvWJJ1N+qUcjJCA7 v3Fstcc4yrlQue69
BLbWOC4SgwOxXjphJGTKOq46sCxpkjj6KnOuxB6sm3HWTY1KjnwEB2hD11XO kjUlPwiHQRbJYxxV
IIFbYA+3h7hXL2T/jwnzcXVhz7XeuwDNpRLDwVHZBnkPOcdj6EG6EZQLYRzt 0qyiQxRVtqrpGjWt
1UEqkM0RTak66fuJuoZhHvunu8U0e/sTCHpR2aJssmIbSr54p0fuRJfDeOKY Qidp4+nK06YptH7I
1F7PsPbGIFi7EQq2fmwBQw7Huy9ukvqg0XXeOaGGOfPJUSlCGziBZAuyQiMU k6Vh3ZybNTk4a5fE
aQlk35UIWup6JD1pd+tsM51kcf0HJmuf7n3+BVBLAwQUAAIACACgVjk1shTS sD0CAACkBQAAEAAA
AFNvdXJjZS9Gb3JtMS5wcme1VG2L2kAQ/i74Hwb7ReVqopSWW7hCjLHmMCZN 0nK0lGMvWXVp3JXN
xvMo/dX9A91NYn3vp3YJYXhm5pl5Zicxus0GdCEQ/IUkkiNtbXCJjWmyJEJB Yy5W/d5aLEp4RPJE
0HVCfzFUAlYhuajMMUmWGMHgjWHeGgPTfKtRo9loNl5RlmRFSqD1gGlGRC9Z tjRuT60ogrgsAePQ
9ypbuwDA9r3AnzmzGPiwkJKz/inspFSegVP8RLIzVClbCJLnQyz6Nb/nxBN/ BLYgWBJdt905xOua
dkaT723gEWEpEdDRyc5sVLZ+rK2a1Ha+KrUZxut/ejTn3zuDw3HWGqe+bU2B Hdh8zFnKAd1BHNBE
FoK0O2jKcdpWCrAGcI+s5q1KqUpz54BQNWr0GWcFgfdglh51rPVadYEl5Qxl wyJ/0cS9uLfzB4Iy
SQTKAkE2lDz/cXcv+z2e4uwKB6tjoiXXcUSH5SvPenA994tzIVoZHwucUVl2 NfJCJ3qcuB8mp6HJ
PX+KqcxKxtbXegrfWmeUvqCEyVJtxeiHrtqux8AP49By49OESGIhRzypF+vA w23MNjhHzMPrnZbV
auKqGw5dO6pHr44a/eHq6oStDj6+kl20unpg6K4Pkl+JuMJaXaziZceBR0oC vCB7KZcFjQR+3u0V
/ADzRj+Dvqnft+9M+Hmz28ArRA5Lj+vMyFbu53EQdjTYy4s4Pluieof2iddH YdZVVSl3XlpV50j9
BKX6ZbbLLyR04k/hDGY0+z9f/W9QSwMEFAACAAgAoFY5NWMFKFWAAQAAmQMA ABAAAABTb3VyY2Uv
Rm9ybTEueGZtlZNNb4JAEIbvJv6HCSdMOAB+VEh6EMRi41eE1vNWV9wIi1mW 1L/bf9LdhRZMTIyX
zezM5J3nnYVlEIfrKfgMI45nOcv0HviLSRRBLG9Wt9PtAEBUXjBz210q7boR 5l5e0kOhg22bBljq
GPfF4Zjw17WP8ZWD+wqaEtXqdD7LqUrHMtB79QAdtGUEEaIFRJiRo2bA2ACh OzAbSeqnBFO+Iwd+
khLWy/C2EmKSnJS6NRzVpVq/V7vazeMQ1t574MeSxis5z6mlgKpYIK3wty4w 0mM9Weq0TI8FmTMy
4GVgQN9s9TSW59mFkYww7b+2loj7s6rWQ1Wi6WhAxS1YTe8DBwfCK9wlKs7y 9hh4KGAtUyzTFoHd
JqaTlCQ0w9WTcLSdv4VxU12i6wLTpNq23fjckD0vGVZmHKex8InSUmWtJ10t 0BdOK1sqfOzJsqUn
+QKOCAZ3X2HzkxCKimdXvGF5wnBReIhVSK3EYzD5L/TlwuXncQN2b/o2iD+2 KyXX7fwCUEsDBBQA
AgAIACSeODVWz4OYxQAAABoBAAAQAAAAU291cmNlL1Byb3ZhLnByZ12OwYrC QAyG74W+Q6iX1oPt
yrLggAdBvCmiHrwOabCBcabEGcXn9gXszCqIlxC+JN+fepxnMIatuDuhdyp2 V53YirEjeaNJL6eE
l3RB4R75YRWsH20wDloCsl50q0GDGUpvGHVcSSeL4J2ofylhpxVMf+tmVk+b 5i/SOs/ybMQWTRhM
xVGzIZlgV0Q+pCO1QQjWmm1ZRQYAiz5leHZW4YG9IVBzKIo0PKycnH/KSm3o Vn6uQqX2nbtFy5dj
F17uHfkgw99PUEsBAhQAFAAAAAgABlU5NTsn8gn4BQAAlCgAAAsAAAAAAAAA AAAgIAAAAAAAAEZh
Y3R1cmEuZW1mUEsBAhQAFAACAAgA7p04NdU05e5mAQAARgIAAAkAAAAAAAAA AAAgALSBIQYAAFBy
b3ZhLnhwalBLAQIUABQAAgAIAKBWOTWyFNKwPQIAAKQFAAAQAAAAAAAAAAAA IAC0ga4HAABTb3Vy
Y2UvRm9ybTEucHJnUEsBAhQAFAACAAgAoFY5NWMFKFWAAQAAmQMAABAAAAAA AAAAAAAgALSBGQoA
AFNvdXJjZS9Gb3JtMS54Zm1QSwECFAAUAAIACAAknjg1Vs+DmMUAAAAaAQAA EAAAAAAAAAAAACAA
tIHHCwAAU291cmNlL1Byb3ZhLnByZ1BLBQYAAAAABQAFACoBAAC6DAAAAAA=
------=_NextPart_000_0068_01C6E09B.49DDC060--

Attached files Prova.zip (3.5 KB)Â

Saludos:
Después de los dos ejemplos puestos por José F. creo que me va a tocar
mirar toda la aplicación ya que puede ser que yo tenga en uso varias
cosas de esas por la aplicación sobre todo el tema de arrays que los uso
mucho para cargar los ComboBox, creo que hay otra forma de hacerlo en
Xailer y tengo que mirarlo, además empleo mucho las imágenes JPG para
los anagramas de la empresa en lugar de usar por lo menos GIF
Así­ que a modificar toca.
Ya que estamos en estas cuestiones me gustarí­a que me sacarais de dudas
con respecto a la declaración de variables locales y su influencia de
hacerlo de una forma o de otra ya que por costumbre de mi anterior
lenguaje empleo lo siguiente:
LOCAL cVariable AS STRING // Variable tipo caracter
En lugar de poner:
LOCAL cVariable // solamente
En el caso de que fuera correcto lo primero y supusiera un
comportamiento mejor de Xailer con respecto a la definición de las
variables, ¿Como deberí­a definir otros tipos?, entero, Float, etc.,
o simplemente da igual.
José Ramón Castro.
Jose F. Gimenez escribió:
> Xevi,
>
> Aquí­ teneis un ejemplo que muestra lo que comento sobre imprimir una
> imagen que ocupa toda la página de un A4.
>
> Gracias por el ejemplo.
>
>
> Ejecutamos la aplicación y mandamos a imprimir una página...
> funciona perfectamente.
> Si mandamos a imprimir 5 páginas, igual... funciona perfectamente.
> Ahora le mandamos a imprimir 8... y de momento funciona perfecto.
> Pero... mandémosle a imprimir 10... cuando el ProgresBar llega a 6 o
> 7... se me "congela" TODO el sistema, y las últimas 3 o cuatro
> páginas se hacen muy "pesadas".
> No digamos si le mando a imprimir 50!!! las primeras 6 o 8 bien,
> pero las restantes se hacen ETERNAS!!! cada página tarda mas!!!
>
> Efectí­vamente, se está desbordando la memoria fí­sica, y windows tiene
> que ir quitando memoria a todos los procesos para darsela al programa.
> Al quitarle memoria a los demás procesos, windows tiene que salvar a
> disco toda esa memoria, y eso es lo que lo hace tan tan leeeeento.
>
>
> Si abro el Administrador de Tareas para hacer el seguimiento de
> objetos GDI y Uso de Memoria, se aprecia como el uso de memoria se
> vuelve "loco" al procesar la página 6 o 8 en adelante.
>
> Cuando arranca la aplicación, 37 GDI y 5456k.
> al imprimir 1 página 88 GDIs y 59456k, cerramos el preview y se
> quedan 68 GDIs y 33824k.
> al imprimir 5 página 118 GDIs y 291460k, cerramos el preview y se
> quedan 90 GDIs y 163644k.
> al imprimir 10 página 150 GDIs y 678604k, cerramos el preview y se
> quedan 112 GDIs y 423128k.
> al imprimir 15 por lo visto al llegar a la impresion de 5, 6 o 8
> empieza a trabajar el recolector de basura y hace vaciado de
> memoria, y es ahí­ donde se hace "pesada" la aplicación" termina el
> proceso con 187 GDIs y 45004k, cerramos el preview y se quedan 139
> GDIs y 9388k.
>
> Por lo visto, los GDIs siempre aumentan... y el uso de la memoria se
> hace "pesada" cuando el proceso es "grandote"
>
> Bueno, el tema de los objetos GDI no veo que sea ningún problema. Se
> están consumiendo los que se usan realmente.
>
>
> Ah, y me ha "ralentizado" TODO mi Windows... tengo que volver a
> reiniciar el sistema!!!
>
> En realidad no necesitas reiniciar; sólo tienes que dejarle tiempo para
> recuperarse.
>
>
> ¿Hago algo mal??
>
> Hay varias cosas que no están bien o que serí­a mejor hacerlas de otra forma:
>
> 1) Estás cargando una copia de la imagen por cada página, que además no
> liberas. Lo correcto es cargar una sola copia de la imagen y destruirla
> al final. En el proyecto adjunto lo puedes ver.
>
> 2) El formato jpeg no es precí­samente el más adecuado para lo que estás
> haciendo. De hecho, si lo conviertes a gif y lo pruebas verás que va
> mejor, aunque sigue siendo un formato poco adecuado. Piensa que aunque
> tu veas que el fichero .jpg ocupa sólo 345KB, al pintarlo en el canvas
> se convierte en bitmap, que a ese tamaño ocupa casi 25MB. Vamos, que en
> cada página estas cargando 345KB + 25MB al descomprimir la imagen en
> memoria + otros 25MB al pegarla en el canvas (en formato emf). En el
> caso de usar un gif, el tamaño de la imagen descomprimida es de unos
> 8MB, debido a que sólo almacena 1 byte por pixel (256 colores) frente a
> los 4 bytes por pixel (16,8 millones de colores) del jpeg.
>
> 3) El formato ideal para la plantilla es emf, que puedes hacerlo con
> corel, freehand, ilustrator o algún otro programa de dibujo vectorial
> similar. Yo he hecho la plantilla de tu ejemplo en emf (no está perfecta
> porque la he hecho rápido como ejemplo) y verás que ocupa unos 10KB.
> Pero lo mejor es que después, en memoria, sigue ocupando esos 10KB.
> Prueba el ejemplo y verás que puedes imprimir 99 páginas sin problema y
> con un consumo de memoria muy reducido. Además, al ser emf un formato
> vectorial, puedes ampliarlo todo lo que quieras sin perder nada de
> calidad (prueba a hacer zoom en ambos casos y verás lo que digo).
>
> --
> Un saludo,
>
> José F. Giménez
> http://www.xailer.com

José Ramón,
> Ya que estamos en estas cuestiones me gustaría que me sacarais de dudas
> con respecto a la declaración de variables locales y su influencia de
> hacerlo de una forma o de otra ya que por costumbre de mi anterior
> lenguaje empleo lo siguiente:
>
> LOCAL cVariable AS STRING // Variable tipo caracter
>
> En lugar de poner:
>
> LOCAL cVariable // solamente
>
> En el caso de que fuera correcto lo primero y supusiera un comportamiento
> mejor de Xailer con respecto a la definición de las variables, ¿Como
> debería definir otros tipos?, entero, Float, etc.,
> o simplemente da igual.
Por ahora, las clausulas AS ... en la declaración de las variables son
totalmente ignoradas por el compilador. Me temo que el compilador todavía no
entiende de tipos, y en runtime se puede asignar cualquier valor a las
variables, sin que se produzca ningún error, aunque las hayas declarado con
otro tipo.
En el futuro es posible que sí añadan esa funcionalidad al lenguaje, así que
mi consejo es que no las declares con tipo, ya que en el futuro podría darte
errores un código que tuvieras funcionando actualmente y que por alguna
razón estés asignando un valor distinto a alguna variable.
--
Un saludo,
José F. Giménez
http://www.xailer.com

José,
Una pregunta (que a lo peor ya ha sido preguntada anteriormente) :
¿Hay alguna forma de saber los objectos GDI no liberados? Hago la pregunta de otra manera:
StartInfoGDI( @aInfoGdi )
oForm := tMiFormulario():New( Self ):ShowModal()
EndInfoGdi()
For Nx := 1 TO LEN( aInfoGdi)
LogDebug("Objeto "+ aInfoGdi[nX]+ "no liberado")
Next
Obviamente, me he inventado todo esto.... ¿Pero hay algo por el estilo?. ¿Algo que nos ayude a nosotros a ver donde no hacemos bien las cosas ?
Saludos y gracias,
José Luis Capel
PD: No he mirado el windows API... no sabrí­a por donde empezar.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> escribió en el mensaje news:[email=4517aac3@news.xailer.com...]4517aac3@news.xailer.com...[/email]
Xevi,
Aquí­ teneis un ejemplo que muestra lo que comento sobre imprimir una imagen que ocupa toda la página de un A4.
Gracias por el ejemplo.
Ejecutamos la aplicación y mandamos a imprimir una página... funciona perfectamente.
Si mandamos a imprimir 5 páginas, igual... funciona perfectamente.
Ahora le mandamos a imprimir 8... y de momento funciona perfecto.
Pero... mandémosle a imprimir 10... cuando el ProgresBar llega a 6 o 7... se me "congela" TODO el sistema, y las últimas 3 o cuatro páginas se hacen muy "pesadas".
No digamos si le mando a imprimir 50!!! las primeras 6 o 8 bien, pero las restantes se hacen ETERNAS!!! cada página tarda mas!!!
Efectí­vamente, se está desbordando la memoria fí­sica, y windows tiene que ir quitando memoria a todos los procesos para darsela al programa. Al quitarle memoria a los demás procesos, windows tiene que salvar a disco toda esa memoria, y eso es lo que lo hace tan tan leeeeento.
Si abro el Administrador de Tareas para hacer el seguimiento de objetos GDI y Uso de Memoria, se aprecia como el uso de memoria se vuelve "loco" al procesar la página 6 o 8 en adelante.
Cuando arranca la aplicación, 37 GDI y 5456k.
al imprimir 1 página 88 GDIs y 59456k, cerramos el preview y se quedan 68 GDIs y 33824k.
al imprimir 5 página 118 GDIs y 291460k, cerramos el preview y se quedan 90 GDIs y 163644k.
al imprimir 10 página 150 GDIs y 678604k, cerramos el preview y se quedan 112 GDIs y 423128k.
al imprimir 15 por lo visto al llegar a la impresion de 5, 6 o 8 empieza a trabajar el recolector de basura y hace vaciado de memoria, y es ahí­ donde se hace "pesada" la aplicación" termina el proceso con 187 GDIs y 45004k, cerramos el preview y se quedan 139 GDIs y 9388k.
Por lo visto, los GDIs siempre aumentan... y el uso de la memoria se hace "pesada" cuando el proceso es "grandote"
Bueno, el tema de los objetos GDI no veo que sea ningún problema. Se están consumiendo los que se usan realmente.
Ah, y me ha "ralentizado" TODO mi Windows... tengo que volver a reiniciar el sistema!!!
En realidad no necesitas reiniciar; sólo tienes que dejarle tiempo para recuperarse.
¿Hago algo mal??
Hay varias cosas que no están bien o que serí­a mejor hacerlas de otra forma:
1) Estás cargando una copia de la imagen por cada página, que además no liberas. Lo correcto es cargar una sola copia de la imagen y destruirla al final. En el proyecto adjunto lo puedes ver.
2) El formato jpeg no es precí­samente el más adecuado para lo que estás haciendo. De hecho, si lo conviertes a gif y lo pruebas verás que va mejor, aunque sigue siendo un formato poco adecuado. Piensa que aunque tu veas que el fichero .jpg ocupa sólo 345KB, al pintarlo en el canvas se convierte en bitmap, que a ese tamaño ocupa casi 25MB. Vamos, que en cada página estas cargando 345KB + 25MB al descomprimir la imagen en memoria + otros 25MB al pegarla en el canvas (en formato emf). En el caso de usar un gif, el tamaño de la imagen descomprimida es de unos 8MB, debido a que sólo almacena 1 byte por pixel (256 colores) frente a los 4 bytes por pixel (16,8 millones de colores) del jpeg.
3) El formato ideal para la plantilla es emf, que puedes hacerlo con corel, freehand, ilustrator o algún otro programa de dibujo vectorial similar. Yo he hecho la plantilla de tu ejemplo en emf (no está perfecta porque la he hecho rápido como ejemplo) y verás que ocupa unos 10KB. Pero lo mejor es que después, en memoria, sigue ocupando esos 10KB. Prueba el ejemplo y verás que puedes imprimir 99 páginas sin problema y con un consumo de memoria muy reducido. Además, al ser emf un formato vectorial, puedes ampliarlo todo lo que quieras sin perder nada de calidad (prueba a hacer zoom en ambos casos y verás lo que digo).
--
Un saludo,
José F. Giménez
http://www.xailer.com
--

José Luis,
Una pregunta (que a lo peor ya ha sido preguntada anteriormente) :
¿Hay alguna forma de saber los objectos GDI no liberados? Hago la pregunta de otra manera:
StartInfoGDI( @aInfoGdi )
oForm := tMiFormulario():New( Self ):ShowModal()
EndInfoGdi()
For Nx := 1 TO LEN( aInfoGdi)
LogDebug("Objeto "+ aInfoGdi[nX]+ "no liberado")
Next
Obviamente, me he inventado todo esto.... ¿Pero hay algo por el estilo?. ¿Algo que nos ayude a nosotros a ver donde no hacemos bien las cosas ?
Estamos estudiándolo y seguramente se podrá dentro de poco.
--
Un saludo,
José F. Giménez
http://www.xailer.com
--

Jose,
Rediseñaré mi modo de operar al imprimir mis Facturas.
Como bien dices, he visto que con un fichero emf la impresión "vuela" !!!
Sólo que el texto en formato emf no queda espaciado correctamente, e igual junta que separa unas letras mas que otras.
Sin embargo, el poder imprimir JPFs grandotas, creo que serí­a un tema a tener en cuenta para posteriores "arreglos" de desbordamiento de la memoria de Windows.
Por cierto, llegado el punto de ese desbordamiento de memoria, por mas que espere que reaccione mi Windows (he esperado hasta 20min.) para que todo vuelva a funcionar perfectamente como antes, debo de reiniciar el sistema.
Gracias por vuestro tiempo.
Un Saludo,
Xevi.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> ha escrit al missatge del grup de discussió: [email=4517aac3@news.xailer.com...]4517aac3@news.xailer.com...[/email]
Xevi,
Aquí­ teneis un ejemplo que muestra lo que comento sobre imprimir una imagen que ocupa toda la página de un A4.
Gracias por el ejemplo.
Ejecutamos la aplicación y mandamos a imprimir una página... funciona perfectamente.
Si mandamos a imprimir 5 páginas, igual... funciona perfectamente.
Ahora le mandamos a imprimir 8... y de momento funciona perfecto.
Pero... mandémosle a imprimir 10... cuando el ProgresBar llega a 6 o 7... se me "congela" TODO el sistema, y las últimas 3 o cuatro páginas se hacen muy "pesadas".
No digamos si le mando a imprimir 50!!! las primeras 6 o 8 bien, pero las restantes se hacen ETERNAS!!! cada página tarda mas!!!
Efectí­vamente, se está desbordando la memoria fí­sica, y windows tiene que ir quitando memoria a todos los procesos para darsela al programa. Al quitarle memoria a los demás procesos, windows tiene que salvar a disco toda esa memoria, y eso es lo que lo hace tan tan leeeeento.
Si abro el Administrador de Tareas para hacer el seguimiento de objetos GDI y Uso de Memoria, se aprecia como el uso de memoria se vuelve "loco" al procesar la página 6 o 8 en adelante.
Cuando arranca la aplicación, 37 GDI y 5456k.
al imprimir 1 página 88 GDIs y 59456k, cerramos el preview y se quedan 68 GDIs y 33824k.
al imprimir 5 página 118 GDIs y 291460k, cerramos el preview y se quedan 90 GDIs y 163644k.
al imprimir 10 página 150 GDIs y 678604k, cerramos el preview y se quedan 112 GDIs y 423128k.
al imprimir 15 por lo visto al llegar a la impresion de 5, 6 o 8 empieza a trabajar el recolector de basura y hace vaciado de memoria, y es ahí­ donde se hace "pesada" la aplicación" termina el proceso con 187 GDIs y 45004k, cerramos el preview y se quedan 139 GDIs y 9388k.
Por lo visto, los GDIs siempre aumentan... y el uso de la memoria se hace "pesada" cuando el proceso es "grandote"
Bueno, el tema de los objetos GDI no veo que sea ningún problema. Se están consumiendo los que se usan realmente.
Ah, y me ha "ralentizado" TODO mi Windows... tengo que volver a reiniciar el sistema!!!
En realidad no necesitas reiniciar; sólo tienes que dejarle tiempo para recuperarse.
¿Hago algo mal??
Hay varias cosas que no están bien o que serí­a mejor hacerlas de otra forma:
1) Estás cargando una copia de la imagen por cada página, que además no liberas. Lo correcto es cargar una sola copia de la imagen y destruirla al final. En el proyecto adjunto lo puedes ver.
2) El formato jpeg no es precí­samente el más adecuado para lo que estás haciendo. De hecho, si lo conviertes a gif y lo pruebas verás que va mejor, aunque sigue siendo un formato poco adecuado. Piensa que aunque tu veas que el fichero .jpg ocupa sólo 345KB, al pintarlo en el canvas se convierte en bitmap, que a ese tamaño ocupa casi 25MB. Vamos, que en cada página estas cargando 345KB + 25MB al descomprimir la imagen en memoria + otros 25MB al pegarla en el canvas (en formato emf). En el caso de usar un gif, el tamaño de la imagen descomprimida es de unos 8MB, debido a que sólo almacena 1 byte por pixel (256 colores) frente a los 4 bytes por pixel (16,8 millones de colores) del jpeg.
3) El formato ideal para la plantilla es emf, que puedes hacerlo con corel, freehand, ilustrator o algún otro programa de dibujo vectorial similar. Yo he hecho la plantilla de tu ejemplo en emf (no está perfecta porque la he hecho rápido como ejemplo) y verás que ocupa unos 10KB. Pero lo mejor es que después, en memoria, sigue ocupando esos 10KB. Prueba el ejemplo y verás que puedes imprimir 99 páginas sin problema y con un consumo de memoria muy reducido. Además, al ser emf un formato vectorial, puedes ampliarlo todo lo que quieras sin perder nada de calidad (prueba a hacer zoom en ambos casos y verás lo que digo).
--
Un saludo,
José F. Giménez
http://www.xailer.com
--

Xevi,
Rediseñaré mi modo de operar al imprimir mis Facturas.
Como bien dices, he visto que con un fichero emf la impresión "vuela" !!!
Sólo que el texto en formato emf no queda espaciado correctamente, e igual junta que separa unas letras mas que otras.
No deberí­a ser así­. Con los antiguos WMF sí­ pasaba, porque no contení­an ninguna información sobre la métrica utilizada al crearlos. Pero con los EMF tiene que funcionar bien. A no ser que estés usando alguna fuente de tipo bitmap; entonces sí­ es posible que al escalar el EMF se distorsione. Yo te aconsejo que siempre uses fuentes 'true type'. Incluso si necesitas emular la impresión de algún programa antiguo de MS-DOS puedes usar la fuente 'Courier New'.
Sin embargo, el poder imprimir JPFs grandotas, creo que serí­a un tema a tener en cuenta para posteriores "arreglos" de desbordamiento de la memoria de Windows.
Poder se puede. Lo que pasa es que por cuestiones de rendimiento estamos guardando los EMF (uno por cada página) en un array en memoria, y claro, cuando llevas muchas páginas pues se llena la memoria. Otros GUIs guardan cada página en un fichero temporal, de forma que en memoria sólo hay 1 página. Pero después tienen otros inconvenientes. En cualquier caso, si alguien necesita previsualizar muchas páginas con imágenes pesadas, podrá más adelante modificar directamente el preview.
Por cierto, llegado el punto de ese desbordamiento de memoria, por mas que espere que reaccione mi Windows (he esperado hasta 20min.) para que todo vuelva a funcionar perfectamente como antes, debo de reiniciar el sistema.
Es raro. Yo he hecho varias pruebas desbordando la memoria y después se ha recuperado bien. Eso sí­, a cada programa que le habí­a quitado memoria para dársela al test le costaba volver a funcionar. Pero una vez que lo manejas un poco vuelve a la normalidad.
--
Un saludo,
José F. Giménez
http://www.xailer.com
--

Xevi,
>>Sólo que el texto en formato emf no queda espaciado correctamente, e igual junta que separa unas letras mas que otras.
Eso no tiene mucho sentido. ¿Me estas diciendo que cada vez que lo imprime no lo hace en el mismo sitio?
>>Sin embargo, el poder imprimir JPFs grandotas, creo que serí­a un tema a tener en cuenta
>>para posteriores "arreglos" de desbordamiento de la memoria de Windows.
Entonces, me temo que deberás poner más memoria en los equipos. Como ya te ha comentado José, un archivo JPG de 350 kb en memoria ocupa 25 megas, por lo tanto, si mandas por PREVIEW un documento de 10 hojas en las que todas tienen dicho arcihvo de fondo, estarás consumiendo 250 Mg. Pero esto no es sólo con Xailer, es con cualquier entorno de programación ya que es Windows el que trata internamente todas las imagenes en formato bitmap sin compresión de ningún tipo.
Soluciones para tu problema:
1) No mostralo en PREVIEW, ya que cada EMF de cada página guarda una copia de la imagen hasta que se destruye.
2) Hacer trabajos de impresión de una sola hoja. El programa Padre de Hacienda tiene esa opción, por cierto, y eso que usa EMFs.
3) No usar JPGs tan tremendamente grandes. Si no te gustan los EMF dibujalo tu directamente, fijate en el ejemplo DataControslDbfData6 y verás que no es tan dificil
>>Por cierto, llegado el punto de ese desbordamiento de memoria, por mas que espere que reaccione
>>mi Windows (he esperado hasta 20min.) para que todo vuelva a funcionar perfectamente como antes,
>>debo de reiniciar el sistema.
En cualquier caso, es un problema del propio Windows. Se supone que cuando una tarea o aplicación se termina, del la forma que sea, todos sus recursos son liberados.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Xevi" <xevicomas@gmail.com> escribió en el mensaje news:[email=4517e597@news.xailer.com...]4517e597@news.xailer.com...[/email]
Jose,
Rediseñaré mi modo de operar al imprimir mis Facturas.
Como bien dices, he visto que con un fichero emf la impresión "vuela" !!!
Sólo que el texto en formato emf no queda espaciado correctamente, e igual junta que separa unas letras mas que otras.
Sin embargo, el poder imprimir JPFs grandotas, creo que serí­a un tema a tener en cuenta para posteriores "arreglos" de desbordamiento de la memoria de Windows.
Por cierto, llegado el punto de ese desbordamiento de memoria, por mas que espere que reaccione mi Windows (he esperado hasta 20min.) para que todo vuelva a funcionar perfectamente como antes, debo de reiniciar el sistema.
Gracias por vuestro tiempo.
Un Saludo,
Xevi.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> ha escrit al missatge del grup de discussió: [email=4517aac3@news.xailer.com...]4517aac3@news.xailer.com...[/email]
Xevi,
Aquí­ teneis un ejemplo que muestra lo que comento sobre imprimir una imagen que ocupa toda la página de un A4.
Gracias por el ejemplo.
Ejecutamos la aplicación y mandamos a imprimir una página... funciona perfectamente.
Si mandamos a imprimir 5 páginas, igual... funciona perfectamente.
Ahora le mandamos a imprimir 8... y de momento funciona perfecto.
Pero... mandémosle a imprimir 10... cuando el ProgresBar llega a 6 o 7... se me "congela" TODO el sistema, y las últimas 3 o cuatro páginas se hacen muy "pesadas".
No digamos si le mando a imprimir 50!!! las primeras 6 o 8 bien, pero las restantes se hacen ETERNAS!!! cada página tarda mas!!!
Efectí­vamente, se está desbordando la memoria fí­sica, y windows tiene que ir quitando memoria a todos los procesos para darsela al programa. Al quitarle memoria a los demás procesos, windows tiene que salvar a disco toda esa memoria, y eso es lo que lo hace tan tan leeeeento.
Si abro el Administrador de Tareas para hacer el seguimiento de objetos GDI y Uso de Memoria, se aprecia como el uso de memoria se vuelve "loco" al procesar la página 6 o 8 en adelante.
Cuando arranca la aplicación, 37 GDI y 5456k.
al imprimir 1 página 88 GDIs y 59456k, cerramos el preview y se quedan 68 GDIs y 33824k.
al imprimir 5 página 118 GDIs y 291460k, cerramos el preview y se quedan 90 GDIs y 163644k.
al imprimir 10 página 150 GDIs y 678604k, cerramos el preview y se quedan 112 GDIs y 423128k.
al imprimir 15 por lo visto al llegar a la impresion de 5, 6 o 8 empieza a trabajar el recolector de basura y hace vaciado de memoria, y es ahí­ donde se hace "pesada" la aplicación" termina el proceso con 187 GDIs y 45004k, cerramos el preview y se quedan 139 GDIs y 9388k.
Por lo visto, los GDIs siempre aumentan... y el uso de la memoria se hace "pesada" cuando el proceso es "grandote"
Bueno, el tema de los objetos GDI no veo que sea ningún problema. Se están consumiendo los que se usan realmente.
Ah, y me ha "ralentizado" TODO mi Windows... tengo que volver a reiniciar el sistema!!!
En realidad no necesitas reiniciar; sólo tienes que dejarle tiempo para recuperarse.
¿Hago algo mal??
Hay varias cosas que no están bien o que serí­a mejor hacerlas de otra forma:
1) Estás cargando una copia de la imagen por cada página, que además no liberas. Lo correcto es cargar una sola copia de la imagen y destruirla al final. En el proyecto adjunto lo puedes ver.
2) El formato jpeg no es precí­samente el más adecuado para lo que estás haciendo. De hecho, si lo conviertes a gif y lo pruebas verás que va mejor, aunque sigue siendo un formato poco adecuado. Piensa que aunque tu veas que el fichero .jpg ocupa sólo 345KB, al pintarlo en el canvas se convierte en bitmap, que a ese tamaño ocupa casi 25MB. Vamos, que en cada página estas cargando 345KB + 25MB al descomprimir la imagen en memoria + otros 25MB al pegarla en el canvas (en formato emf). En el caso de usar un gif, el tamaño de la imagen descomprimida es de unos 8MB, debido a que sólo almacena 1 byte por pixel (256 colores) frente a los 4 bytes por pixel (16,8 millones de colores) del jpeg.
3) El formato ideal para la plantilla es emf, que puedes hacerlo con corel, freehand, ilustrator o algún otro programa de dibujo vectorial similar. Yo he hecho la plantilla de tu ejemplo en emf (no está perfecta porque la he hecho rápido como ejemplo) y verás que ocupa unos 10KB. Pero lo mejor es que después, en memoria, sigue ocupando esos 10KB. Prueba el ejemplo y verás que puedes imprimir 99 páginas sin problema y con un consumo de memoria muy reducido. Además, al ser emf un formato vectorial, puedes ampliarlo todo lo que quieras sin perder nada de calidad (prueba a hacer zoom en ambos casos y verás lo que digo).
--
Un saludo,
José F. Giménez
http://www.xailer.com
--

Jose e Ignacio,
Gracias otra vez por vuestras respuestas.
Intentaré lo dicho,... amoldarme a la utilización de los ficheros EMF y a los tipos de letras que sean correctos.
Un Saludo,
Xevi.
"Xevi" <xevicomas@gmail.com> ha escrit al missatge del grup de discussió: [email=4517e597@news.xailer.com...]4517e597@news.xailer.com...[/email]
Jose,
Rediseñaré mi modo de operar al imprimir mis Facturas.
Como bien dices, he visto que con un fichero emf la impresión "vuela" !!!
Sólo que el texto en formato emf no queda espaciado correctamente, e igual junta que separa unas letras mas que otras.
Sin embargo, el poder imprimir JPFs grandotas, creo que serí­a un tema a tener en cuenta para posteriores "arreglos" de desbordamiento de la memoria de Windows.
Por cierto, llegado el punto de ese desbordamiento de memoria, por mas que espere que reaccione mi Windows (he esperado hasta 20min.) para que todo vuelva a funcionar perfectamente como antes, debo de reiniciar el sistema.
Gracias por vuestro tiempo.
Un Saludo,
Xevi.
"Jose F. Gimenez" <jfgimenez@wanadoo.es> ha escrit al missatge del grup de discussió: [email=4517aac3@news.xailer.com...]4517aac3@news.xailer.com...[/email]
Xevi,
Aquí­ teneis un ejemplo que muestra lo que comento sobre imprimir una imagen que ocupa toda la página de un A4.
Gracias por el ejemplo.
Ejecutamos la aplicación y mandamos a imprimir una página... funciona perfectamente.
Si mandamos a imprimir 5 páginas, igual... funciona perfectamente.
Ahora le mandamos a imprimir 8... y de momento funciona perfecto.
Pero... mandémosle a imprimir 10... cuando el ProgresBar llega a 6 o 7... se me "congela" TODO el sistema, y las últimas 3 o cuatro páginas se hacen muy "pesadas".
No digamos si le mando a imprimir 50!!! las primeras 6 o 8 bien, pero las restantes se hacen ETERNAS!!! cada página tarda mas!!!
Efectí­vamente, se está desbordando la memoria fí­sica, y windows tiene que ir quitando memoria a todos los procesos para darsela al programa. Al quitarle memoria a los demás procesos, windows tiene que salvar a disco toda esa memoria, y eso es lo que lo hace tan tan leeeeento.
Si abro el Administrador de Tareas para hacer el seguimiento de objetos GDI y Uso de Memoria, se aprecia como el uso de memoria se vuelve "loco" al procesar la página 6 o 8 en adelante.
Cuando arranca la aplicación, 37 GDI y 5456k.
al imprimir 1 página 88 GDIs y 59456k, cerramos el preview y se quedan 68 GDIs y 33824k.
al imprimir 5 página 118 GDIs y 291460k, cerramos el preview y se quedan 90 GDIs y 163644k.
al imprimir 10 página 150 GDIs y 678604k, cerramos el preview y se quedan 112 GDIs y 423128k.
al imprimir 15 por lo visto al llegar a la impresion de 5, 6 o 8 empieza a trabajar el recolector de basura y hace vaciado de memoria, y es ahí­ donde se hace "pesada" la aplicación" termina el proceso con 187 GDIs y 45004k, cerramos el preview y se quedan 139 GDIs y 9388k.
Por lo visto, los GDIs siempre aumentan... y el uso de la memoria se hace "pesada" cuando el proceso es "grandote"
Bueno, el tema de los objetos GDI no veo que sea ningún problema. Se están consumiendo los que se usan realmente.
Ah, y me ha "ralentizado" TODO mi Windows... tengo que volver a reiniciar el sistema!!!
En realidad no necesitas reiniciar; sólo tienes que dejarle tiempo para recuperarse.
¿Hago algo mal??
Hay varias cosas que no están bien o que serí­a mejor hacerlas de otra forma:
1) Estás cargando una copia de la imagen por cada página, que además no liberas. Lo correcto es cargar una sola copia de la imagen y destruirla al final. En el proyecto adjunto lo puedes ver.
2) El formato jpeg no es precí­samente el más adecuado para lo que estás haciendo. De hecho, si lo conviertes a gif y lo pruebas verás que va mejor, aunque sigue siendo un formato poco adecuado. Piensa que aunque tu veas que el fichero .jpg ocupa sólo 345KB, al pintarlo en el canvas se convierte en bitmap, que a ese tamaño ocupa casi 25MB. Vamos, que en cada página estas cargando 345KB + 25MB al descomprimir la imagen en memoria + otros 25MB al pegarla en el canvas (en formato emf). En el caso de usar un gif, el tamaño de la imagen descomprimida es de unos 8MB, debido a que sólo almacena 1 byte por pixel (256 colores) frente a los 4 bytes por pixel (16,8 millones de colores) del jpeg.
3) El formato ideal para la plantilla es emf, que puedes hacerlo con corel, freehand, ilustrator o algún otro programa de dibujo vectorial similar. Yo he hecho la plantilla de tu ejemplo en emf (no está perfecta porque la he hecho rápido como ejemplo) y verás que ocupa unos 10KB. Pero lo mejor es que después, en memoria, sigue ocupando esos 10KB. Prueba el ejemplo y verás que puedes imprimir 99 páginas sin problema y con un consumo de memoria muy reducido. Además, al ser emf un formato vectorial, puedes ampliarlo todo lo que quieras sin perder nada de calidad (prueba a hacer zoom en ambos casos y verás lo que digo).
--
Un saludo,
José F. Giménez
http://www.xailer.com
--