Foros aprenderaprogramar.com
Didáctica y divulgación de la programación

Hola Alex, ¿cómo estás?
Disculpame la falta de noticias, pero es que tomé otro trabajo que me tiene absorvido casi totalmente.
Bueno, te cuento que todas las pruebas fueron satisfactorias con la última modificación: poner la llamada a ese formulario "problemático" después de la orden de imprimir, y resultó bien.
No encontré la causa del error, pero sí una forma de contornearlo. Sé que no es lo ideal, pero a veces no se puede, no? Por lo menos me deja más tranquilo de que puedo continuar usando ese formulario con las nuevas funcionalidades que quería agregarle a mi software.
TE AGRADEZCO MUCHÍSIMO TU TIEMPO Y ATENCIÓN. Valoro mucho lo que hacen gente como vos en los foros, DESINTERESADAMENTE, quitando tiempo a sus otras actividades. A veces, sin la ayuda de uds, se torna muy difícil encontrar solución a nuestros problemas de programación. Te reitero nuevamente mi agradecimiento, y espero seguir usando este foro, y/ó solamente mantener contacto. Te dejo mi mail particular: alesuare@hotmail.com.
Un abrazo grande desde Uruguay, y muchas gracias por todo.

Alejandro Suárez

Hola Alex, ¿qué tal?
Esta semana fue muy complicada para mi, por otros temas, y recién hoy puedo dedicarme nuevamente a este problema.
Como te contaba en mi respuesta anterior:
"Ahora estoy trabajando en revisar y probar si puedo "mover" la rutina que llama a ese formulario PARA EL FINAL, luego de la orden de imprimir, y ver qué implicaciones tiene en el funcionamiento del pgm y cómo queda operativamente."
Terminé de revisar y corregir eso, volví a compilar, y ahora estoy esperando que me den el retorno de las pruebas realizadas.

Referente al "control de estado", al ser manual como tú dices, es prácticamente lo mismo que he estado haciendo desde el principio, lo cual hace que sea difícil para este problema específico, por no saber dónde buscar.

Sobre tu nueva sugerencia, ya uso en mi pgm el cuadro de diálogo Impresoras, pero para crear un "perfil de impresión", personalizado para cada cliente, según la impresora que tenga, que permite cambiar la impresora, papel, fuente, tamaño, negrita, y "correr" la impresión de la factura (izquierda/derecha y arriba/abajo), aumentando ó disminuyendo la cantidad de filas y columnas, para que coincida con el diseño del documento pre-impreso donde se imprimen las facturas. De esta manera, después que configuré el perfil la primera vez, mi cliente no tiene que cambiar más nada, y el pgm imprime directamente a la impresora predeterminada, con esas propiedades ya configuradas (Printer.FontSize, Printer.PaperSize, Printer.FontBold, etc). También ya he revisado todas las propiedades y no he encontrado nada.

Bueno, sigo esperando que me retornen el resultado de las pruebas con estas modificaciones ("mover" la rutina que llama a ese formulario PARA EL FINAL, luego de la orden de imprimir). Tengo esperanzas de que funcione, porque si imprime primero, para luego llamar al formulario "culpable", a esa altura el documento ya tendria que estar impreso, no? Te aviso si tengo novedades.

Muchas gracias, un abrazo

Hola Alex, ¿qué tal? muchas gracias por tus comentarios. Entiendo que es muy difícil entender el código y/ó pgm de otra persona, y te agradezco mucho tu ayuda, Y SOBRE TODO, TU TIEMPO.
Paso a responder tus comentarios y preguntas:

a) Cuando has hablado del error 28 y de que estás tratando de investigar en torno a este error ¿por qué es que estás investigando sobre este error? ¿porque ocasionalmente se te detiene el programa trabajando con él y te informa de este error? ¿tienes alguna evidencia que relacione este error con el problema de impresión o no hay seguridad de la relación entre ambos problemas?
Respuesta: Lo del Error 28 es una hipótesis mía, de acuerdo a mi anterior experiencia. Mi pgm no se ha trancado ni informado de este error. Solamente me acordé de este error, porque hace mucho tiempo, pasé mucho trabajo con él y el CrystalReport, e investigué mucho en ese momento, y me acordaba que eran muchas las posibles causas de este error, entre ellas la sobrecarga de memoria, y pensando ahora, en la alietoriedad del problema de impresión, me planteé esto como una hipótesis mía, pero no tengo ninguna evidencia de que estén relacionados.

b) Cuando has hablado del problema con la impresión y el tamaño de fuente y el que piensas que puede estar relacionado con saturación de memoria, pila de llamadas, tamaño del módulo bas, etc. ¿tienes alguna evidencia de que puede haber alguna relación entre estas cuestiones y el problema de impresión?
Respuesta: Lo mismo de la pregunta anterior: son hipótesis que me planteé de acuerdo a mi experiencia anterior, pero sin evidencias (ahora, para este problema) que lo sustente. Lo del tamaño del módulo también me lo planteé, porque hace mucho, en mis investigaciones de ese momento, recuerdo haber encontrado y leído algo al respecto, y recomendaban agregar un segundo módulo. Lamentablemente, no recuerdo dónde lo leí (foros, ayudas, etc), ni tampoco logré encontrar, ahora, nada al respecto. Capaz que lo leí en algún sitio web que ya no está más, pero estoy seguro que lo leí en algún lugar, no estoy loco, je je.

c) ¿La aplicación tiene otros problemas destacables además del problema de impresión?
Respuesta: NO, mi pgm funciona bien, desde hace muchos años, en varios clientes, con uno ó varios pcs, con XP y Seven 32-64, con impresoras de diferentes marcas, y hasta la versión anterior no presentaba este problema. Una de las pruebas que hice, fue volver a usar esa versión anterior y no tuvieron el problema de impresión.
En esta nueva versión, hay un parámetro de configuración, para que cada cliente elija si quiere utilizar ó no esta nueva funcionalidad. Si elijen SI, se muestra el formulario que te envié el código. Si elijen NO, no se muestra el formulario, y el pgm guarda automatica-mente un registro por defecto, con el total de la factura, como Efectivo.
También probé configurarles como NO, y han trabajado e impreso normalmente, pero si vuelvo a configurarles como SI, vuelve el problema aleatorio de impresión.
Por todo esto es que SUPONGO QUE HAY ALGO EN ESTE FORMULARIO, que está provocando algún tipo de conflicto, ó desconfigura la impresora (en mis pruebas, no he logrado nunca, ver que la variable Tamaño haya perdido su valor), ó sobrecarga la memoria, ó capaz que es un bug de VB.

Ahora, respondiendo tus comentarios:

1) Sobre uso de variables.
Aquí veo cosas que me llaman la atención porque a priori yo no las plantearía así, no digo que estén bien o que estén mal, sino que me llaman la atención. ¿Por qué declarar todo como String pudiendo usar otro tipo de variables que son más eficientes tanto a la hora de procesarse como de consumo de memoria? Por ejemplo FPAGO_POR_DEFECTO supongo que es una forma de pago, y quizás hay 5, 10 ó 20 formas de pago. ¿Por qué usar un String cuando puedes usar un Integer que es mucho más eficiente simplemente estableciendo una equivalencia? Esto no sé qué importancia puede tener en el global del programa. Desde luego que si afecta a 20, 40 ó 50 variables no tendrá importancia pero si afecta a un gran número de variables habría que verlo.
Respuesta: Esas variables son string realmente, porque no contienen un ID (por ejemplo), sino que contienen información (cadenas de texto) recopilada durante la realización de la factura y que son utilizadas para la impresión, de forma tal que, al clicar sobre el botón Imprimir, no tenga que volver a buscar esa info, sino que ya la tiene en variables de memoria, y con eso el proceso de la impresión sería más rápido. No sé si es lo ideal, pero fue la manera que lo hice.

2) Sobre control de múltiples llamadas a procedimientos que ya están en ejecución. Una fuente de problemas puede ser que si el usuario hace click en un botón, por ejemplo el botón "Imprimir", se produce el evento click sobre este botón y si el usuario ve que tarda un segundo en cargar es posible que vuelva a hacer doble click sobre el botón pensando que no responde. Esto lo que ocasiona es que se dispare de nuevo el evento y que esta llamada y los recursos que consume se acumulen en la pila del programa (lo que puede llevar a una sobrecarga). Frente a esto hay formas de controlar si se está ejecutando el código de respuesta a un evento para impedir que un nuevo click vuelva a disparar el evento ¿Tienes algún tipo de control para evitar esta situación?
Respuesta: SI, eso está controlado. No le bloqueo el botón, por ejemplo, pero le muestro un mensaje pidiendo confirmación, antes de comenzar el proceso de impresión (que es bastante rápido, incluso por la red). No creo que pueda ser esto, pero podría ser, lo voy a chequear.

3) Tampoco estoy seguro de si puede estar afectando, pero una recomendación que se suele hacer es no confiar en que las variables u objetos de tipo recordset, database, workspace, etc. se destruyan automáticamente cuando se cierran ventanas o procedimientos locales. Por ejemplo con el evento unload proceder a realizar algo como llamar a una función para cerrar todo.
Respuesta: Lo que uso para controlar estos temas, es salir de cada formulario usando "Unload Me", para descargar todo lo que sea local, pero no la bd ó tablas que, eventual-mente, puedan estar en uso por otro formulario.
Además, utilizo "DBEngine.Idle dbFreeLocks", según las recomendaciones del MSDN:
http://support.microsoft.com/kb/550617/es

Utilización de dbFreeLocks en entorno multiusuario.
Según la ayuda de Visual Basic, el método Idle "suspende el procesamiento de datos, permitiendo al motor de base de datos Microsoft Jet completar las tareas que tenga pendientes, como la optimización de la memoria o los tiempos de espera de página."
Con el método Idle puede dar al motor de base de datos ocasión de realizar tareas de segundo plano que pueden no encontrarse actualizadas a causa de un procesamiento de datos intenso. Esta situación se produce a menudo en entornos multiusuario y multitarea en los que no hay suficiente tiempo de procesamiento en segundo plano
para mantener actualizados todos los registros de un conjunto de registros.
La utilización periódica del método Idle concede tiempo al motor de base de datos para liberar los bloqueos de lectura innecesarios. Si especifica la constante dbFreeLocks como argumento, el procesamiento se retrasará hasta que se hayan liberado todos los bloqueos de lectura.

Hola Alex, ¿qué tal?
Sí, ya he tenido algunos problemitas de compatibilidad con Seven, 32 y 64, pero le he encontrado solución. Pero en este caso, me parece que no sería eso, ya que me da lo mismo en pcs con XP Profesional 32, como con Seven Ultimate 32 y 64. Además, en esos mismos pcs, mi versión anterior funciona perfectamente, pero la versión nueva es la que me da problema. Es como si el formulario que le agregué (u otra cosa de las nuevas) sea la que está causando el error, ya sea porque supera algún límite máximo ó algo así, pero no veo qué puede ser.
Te adjunto un archivo rar con el código del formulario nuevo que agregué, además de las imágenes de los formularios, y el texto del error 28 (no hay suficiente espacio de pila). Espero que esto te pueda servir de ayuda. Muchas gracias.

Hola Alex, qué tal?
Estoy totalmente de acuerdo contigo en que lo de "aleatorio" es relativo: en el fondo, debe haber una explicación, porque un programa no debería hacer nada para lo cual no fue programado. Lo difícil es que el ambiente de depuración se traslada al de producción, en el cliente, y es muy poco lo que puedo controlar allí.
La variable que cambia de valor, si es que eso lo que está ocurriendo, se refiere al tamaño de la fuente según el perfil de impresión personalizado por cada cliente, y según la impresora que tenga cada uno. En general, el predeterminado es 9, y ya probé asignar ese valor directamente al objeto Printer.FontSize, sin cargarlo en una variable y luego leerlo en el momento de imprimir, pero no resultó. Es como si, por algún motivo, la impresora se des-configurara momentáneamente, porque casi siempre, la siguiente impresión sale bien, salvo algunas veces en que salieron impresiones malas 2-3-4 veces seguidas. También probé ponerle al final del código, justo antes de la orden de imprimir, un IF para verificar el valor de Printer.FontSize y de la variable, y forzarlos a que utilizaran el tamaño 9, pero tampoco funcionó. Por eso es que tengo dudas de que el problema sea con esa variable, sino más bien con otra cosa menos "controlable", como la configuración de la impresora, carga ó saturación de la memoria, pila de llamadas, el tamaño del módulo bas, etc.
Aclaro que lo mismo me ocurre en diferentes clientes, con pcs variados, más y menos potentes, con Windows XP y Seven, y con diferentes marcas y modelos de impresoras láser. Por ahora, lo que hice temporalmente, es dejar a mis clientes trabajando con la versión anterior de l programa.
Saludos.

Hola a todos:
Mi consulta es SI EXISTE, y cuál es en ese caso, UN TAMAÑO MÁXIMO Ó LÍMITE, ó la cantidad máxima de variables, que puede tener un MÓDULO .BAS en Visual Basic. Y también, para la PILA DE LLAMADAS, la cantidad de variables permitidas, etc.
Mi consulta se debe a que tengo un software de facturación funcionando desde hace mucho tiempo en varios clientes, y en la última actualización que hice, empezó a tener un comportamiento extraño, y ALEATORIO: me imprime la factura y/ó recibo, aleatoriamente, en un tamaño super chiquito, como si la fuente estuviera definida en tamaño 1 (uno), siendo que está definida como un parámetro global en tamaño 9. Como lo hace al AZAR, es decir, a veces imprime varias bien y de pronto alguna mal, sin seguir un patrón determinado ó una causa puntual, me hace pensar que, por algún motivo, esa variable de tamaño pierde el valor, pero no hay nada en el formulario que haga eso.
Con la versión anterior de mi programa no me pasaba esto. Lo que hice en esta versión nueva fue agregar que aparezca un formulario (tipo pop-up) para seleccionar las formas de pago, y para implementar esta funcionalidad, tuve que agregar tablas a la bd, que las declaré en el único módulo .bas existente, junto con nuevas variables globales. Por eso lo de mi consulta, por si de pronto alcancé algún límite del módulo, etc. Ya revisé exaustivamente ese formulario nuevo, está hecho similar a otros que ya tenía funcionando, y no le encontré nada "raro".
Aclaro que me está pasando eso en varios clientes, con Windows XP y Seven, con diferentes modelos de impresoras.
¿ALGUNA SUGERENCIA DE POR DÓNDE BUSCAR? Muchas gracias por su ayuda.
Alejandro Suárez - Uruguay