Módulos .bas: tamaño máximo ó límite cantidad variables Visual Basic

[alesuare]

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

[Alex Rodríguez]

Hola, desde mi punto de vista el tamaño máximo o límite de un .bas (en líneas de código o en cantidad de variables, pila de llamadas) es el límite de recursos disponibles (memoria principalmente) que tenga el sistema. Tendría que ser algo muy grande para que llegaras a alcanzar ese límite.

Por la descripción del problema que haces no creo que sea posible decir directamente qué es lo que puede estar pasando. A mí la primera impresión que me da es que puedes tener un conflicto de nombres: que estés usando el mismo nombre de variable en dos ámbitos distintos, o que en algún punto del programa tenga lugar un cambio del valor de la variable global. Yo empezaría a buscar por ahí, por un posible conflicto de nombres.

¿Qué versión de visual basic estás usando?

[alesuare]

Hola Alex, gracias por responder.
El programa fue hecho en VB5, y no fue actualizado a versiones más nuevas, porque quiero hacerlo completamente en .Net, desde cero, pero le sigo dando mantenimiento.
Preguntaba sobre si había un límite para el módulo bas, porque me parecía que hace mucho tiempo atrás vi algo al respecto, y que debería agregar otro módulo, pero no logré encontrar información sobre eso.
Ya revisé el formulario nuevo, pero lo voy a volver a revisar buscando específicamente lo que me decís del posible conflicto de nombres. Por lo demás, no me parece que sea, porque la variable global es cargada al comienzo del pgm, y luego sólo es consultada a la hora de imprimir, pero no le cambio en ningún momento su valor, pero, como decís vos, pudiera haber algo que le estuviera cambiando de valor.
Pero lo que me tiene más intrigado es que es ALEATORIO, no lo hace siempre, para todas las facturas, sino que puede pasar un rato largo sin hacerlo, como también puede hacerlo repetidas veces.
Ahora, agregué un segundo módulo y pasé todo lo que había agregado desde la versión anterior al nuevo módulo. También estoy tratando de mejorar un poco el código, revisando las variables que me quedaron sin declaración de tipo (desde hace mucho tiempo atrás), y que VB les asigna Variant, y asignándole el tipo adecuado, para ver si con eso logro solucionarlo. Lo peor es que, en mis pruebas, no logro reproducir esa situación, entonces lo único que puedo hacer es compilarlo e instalarlo en un cliente, para que, con el uso real del programa, pueda determinar si funciona ó no lo que voy probando.
Muchas gracias por tu interés en ayudarme. Saludos desde Uruguay.

[Alex Rodríguez]

Los comportamientos aparentemente aleatorios son como dices bastante molestos porque esquivan la posibilidad de repetir el error y hacer pruebas. Pero en el 99,99% de los casos son sólo aparentemente aleatorios, es decir, en el fondo hay algo que ocurre que justifica que ocurra así. Por ejemplo hay páginas web que a veces se comportan de una manera y a veces de otra, de forma aparentemente aleatoria. Sin embargo, lo que ocurre es que javascript no carga bien y esto es debido al servidor o a una baja velocidad de conexión a internet, parece aleatorio pero es explicable, aunque a veces sea difícil dar con esa explicación.

¿Por qué no declaras ese valor como una constante en vez de como una variable? Saludos

[alesuare]

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.

[alesuare]

Hola Alex, ¿qué tal?
Bueno, te cuento que probé asignarle directamente el tamaño 9 al objeto Printer.FontSize, justo antes de la orden de imprimir, y tampoco anduvo.
No creo 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, pero no encuentro nada.
Ahora estoy probando las indicaciones de la ayuda referente al ERROR 28: No hay espacio suficiente de pila.
Estoy tratando de "achicar" la carga en memoria, cambiando las variables de tipo Variant (tipo por defecto en VB, que ocupan 16bits) por otros tipos más adecuados.
¿NO SE TE OCURRE NADA PARA AYUDARME? La verdad, ya no me doy cuenta qué más puedo probar, a no ser quitar del todo el formulario que agregué en la nueva versión (tipo pop-up) para seleccionar las formas de pago, y que supuestamente, es el "culpable", y ver de qué otra forma puedo implementarlo.
Gracias y saludos desde Uruguay.

[Alex Rodríguez]

¿Qué tal? El asunto es que tú conoces el programa, conoces el código y yo opino "a ciegas" con lo cual es muy difícil atinar con qué puede ser lo que esté causando el problema. Una cosa que se me ocurre y con la que he tenido problemas en algunas ocasiones es que visual basic 5 y visual basic 6 tienen algunos problemas de incompatibilidad con sistemas de 64 bits. Ahora mismo los pcs que se están vendiendo en los últimos meses y años ya están viniendo todos con sistemas operativos de 64 bits. La verdad es que como te digo es una opinión a ciegas porque sin código y sin poder testear el problema... son poco más que especulaciones

[alesuare]

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.

[Alex Rodríguez]

Voy a echarle un vistazo a ver si veo algo y ya te comento...

[alesuare]

Gracias Alex, espero ansioso tus comentarios.
De mi parte, sigo revisando y tratando de mejorar mi código.
Saludos

[Alex Rodríguez]

Hola Alejandro, he estado mirando el código e imágenes y desde luego resulta complicado... Te voy a comentar algunas cuestiones y hacerte algunas 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?

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?

c) ¿La aplicación tiene otros problemas destacables además del problema de impresión?


Ahora comentarios respecto a algunas cuestiones del código:


1) Sobre uso de variables

Formulario MOV_PAGOS

Public FPAGO_POR_DEFECTO As String
Public FLAG_ERROR As String
Public strDOCUMENTO As String
Public codMONEDA As String                'es el Código de la moneda seleccionada
Public strFECHA As String
Public codFPAGO As String


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.


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?


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:

'--------------------------------------------------
Public Function CloseAllRecordsets() As Integer
'--------------------------------------------------
on error resume next
'Asegurar el cierre y liberación de memoria


'A ubicar en respuesta a cierre de menús o ventanas según proceda

Dim wsCurr As Workspace
Dim dbCurr As Database
Dim Rs As Recordset
Dim Frm As Form

For Each wsCurr In Workspaces
   For Each dbCurr In wsCurr.Databases
      For Each Rs In dbCurr.Recordsets
         MsgBox "El recordset " & vbCrLf & Rs.Name & vbCrLf & _
Rs.RecordCount & " registros abiertos, se procede a su cierre.", vbCritical, "Validation"
         Rs.Close
         Set Rs = Nothing
      Next

      dbCurr.Close
      Set dbCurr = Nothing
    Next

    wsCurr.Close
    Set wsCurr = Nothing
Next

End Function

[alesuare]

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.

[Alex Rodríguez]

Creo que tienes el problema bastante acotado, si no tienes un indicio claro tendrías que hacer la depuración comprobando elemento a elemento qué es lo que genera el fallo; podrías ir comentando el código por fragmentos, cambiando nombres de variables para comprobar que no existe un conflicto de nombres, etc. El problema principal es que si el fallo no es reproducible tampoco puede existir una estrategia de depuración clara. Para mí lo primero sería tratar de hacer el fallo reproducible, investigar en qué circunstancias es en las que se produce el fallo. Podrías tratar de introducir un "control de estado" que se muestre por pantalla cada vez que se imprime, donde te informe de cuáles son los formularios activos, el contenido de las variables en ese momento, conexiones abiertas, etc. y comparar el estado cuando hay fallo y cuando no hay fallo. De cualquier manera es algo que resultaría costoso y tampoco te aseguraría que alcanzaras una solución porque como indicas podría tratarse de un bug o de un conflicto con el software de impresora ó sistema operativo y en ese caso no sacarías nada en claro con el control de estados...

[alesuare]

Hola Alex, ¿qué tal?
Al código de ese formulario y del que lo llama (la propia factura) ya lo he revisado, linea por linea, poniéndole interrupciones, verificando los valores de las variables, etc., y no he podido encontrar el fallo ó la causa, y mucho menos reproducirlo.
De lo que estoy seguro es que el "culpable" es ese formulario nuevo, pero no puedo quitarlo del pgm porque lo necesito, representa un 90-95% de la funcionalidad nueva que quiero implementar.

Este formulario (formas de pago) es mostrado sólo para las facturas CONTADO. En las facturas CREDITO no se muestra, pero sí se muestra otro formulario, bastante parecido, para la Venta en Cuotas, donde se muestra una grilla con el detalle de todas las cuotas generadas (nro. de cuota, detalle, importe y vencimiento). Como ambos formularios son más ó menos parecidos, aunque hagan tareas diferentes, y de diferente forma, LOS COMPARÉ ENTRE ELLOS, principalmente los principales procedimientos (load, unload, aceptar, cancelar, etc), y tampoco encontré nada raro ni diferente, salvo lo que correspondía. Este formulario ya hace tiempo que está funcionando, sin problemas, aunque no a full, ya que sólo un cliente tiene venta en cuotas, pero nunca reportó problemas como éste de ahora.

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.

Me gustó tu sugerencia del "control de estado". ¿Tendrías alguna rutina que realice esa tarea automáticamente? ¿ó tendría que crear una yo mismo? pregunto porque si tengo que hacerlo manualmente, una por una, son muchísimas posibilidades, y si justo me "como" alguna, es casi lo mismo que nada, ó por lo menos, sería parecido a lo que he estado revisando manualmente. Estaría muy bueno, si se puede obtener esa instantánea del estado del pc y de la memoria en un momento dado, por ejemplo, antes y después de la orden de imprimir, y que se grabara todo en un archivo txt, por ejemplo.

¡Qué triste la vida del programador! ja ja. Un abrazo.

[Alex Rodríguez]

Hola, veo que has hecho una revisión completa y detenida, y para mí el problema principal sigue estando en torno a que si un error no es reproducible se convierte en difícil su corrección. Lo del control de estado no he usado nunca una rutina que haga esa tarea de forma automática. Más bien lo suelo preparar manualmente con impresiones por pantalla, o bien usando "breakpoints" para detener la ejecución y comprobar el valor de variables con el debugger. Esto es útil, pero sobre todo cuando se sabe lo que se busca, en tu caso como bien dices si no sabes exactamente dónde buscar tendrías tantas posibilidades y posibles combinaciones que difícilmente vas a poder llegar a conclusiones.

Se me han ocurrido un par de cuestiones que no sé si has probado: la primera, la posibilidad de que sea otra propiedad de printer la que se esté desconfigurando, por ejemplo PaperSize. Habría que revisar o configurar todas las propiedades que pudieran estar influyendo. La segunda, mostrar un cuadro de diálogo de impresión del tipo que se indica en esta url: http://msdn.microsoft.com/en-us/library/aa227613%28v=vs.60%29.aspx quizás lograra evitar problemas

[alesuare]

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

[Alex Rodríguez]

Espero que hayas tenido suerte y que comentes los resultados de esas pruebas a ver si efectivamente logras así resolver el problema. "A veces el programador trabaja como si de un detective se tratara" y "Siempre quedan crímenes sin resolver" (en sentido metafórico).

[alesuare]

ja ja, sí, es muy cierto lo que decís.

Las primeras pruebas "reales" que hicimos fueron satisfactorias, todas salieron bien impresas, aunque en total fueron pocas facturas, va "pintando" bien, pero no quiero cantar victoria todavía, je je.

Voy a esperar una semana más de pruebas, para ver qué tal, y también voy a ver si pruebo en alguno de los otros clientes, para aumentar la cantidad de pruebas. Y de puro porfiado nomás, dentro de unos días, si todo sale bien, voy a volver a usar el exe anterior (el que tiene el error), para confirmar que no sea casualidad que se haya resuelto el problema.

En cuanto tenga más novedades, te comento. Un abrazo

[alesuare]

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

[Alex Rodríguez]

Hola, me alegro de que al final pudieras resolver el problema "contorneándolo" como tú dices. Al final la gente, los clientes, los usuarios... no te preguntan si has construido un algoritmo eficiente o si haces un uso adecuado de los recursos del computador. Simplemente te preguntan si funciona, y si funciona "todo el mundo tan contento". Es un poco paradójico que normalmente no se valoren otras cosas que el que funcione, pero también tenemos que tener presente que ese es un objetivo principal y si lo alcanzas "contorneando" pues perfecto. Creo que la mayoría de los que programamos hacemos muchas veces cosas que no son del todo correctas sabiéndolo, por motivos diversos.
Y yo también agradezco poder conversar con gente de todo el mundo, en este caso de España a Uruguay y conocer opiniones y formas de trabajar, que es enriquecedor. Seguimos en contacto, yo suelo estar por aquí ya que soy administrador en el foro