SoloCodigo

Si no recuerdo mal los procedimientos están limitados a un tamaño de 64 kb (que se cargan en memoria de una sola vez)... tus 1600 líneas pueden ser aproximadamente 120 kb (depende del tamaño de las líneas)... sin embargo eso no significa que no se pueda ejecutar, todo lo que tienes que hacer es repartir el código en varios procedimientos... Es bastante posible que estés produciendo 'código espagueti'...

Es buen seguro que mucho código que tienes en ese procedimiento estaría mejor ubicado en su propio procedimiento...

Espón 30 ó 40 líneas y te muestro in situ como repartirlo (ya sería mala suerte que justo fueras a exponer un conjunto de líneas que precisamente deban ir juntas y seguidas)... básicamente un procedimiento de más de 200 líneas es seguro que parte de elló puede moverse a otro procedimiento.

Este códiigo vale perfectamente... aunque mejor si lo hubieras metido  entre dos etiquetas de 'code', para que quedara convenientemente indentado y fuera cómodo de leer...

De entrada, tal que lo que dices el objeto ApExcel lo tienes definido a nivel de procedimiento y en tu caso conviene definirlo a nivel de formulario, supongamos que tu procedimiento se llamara TrabajarExcel ....


Ahora ya estando declarado el objeto a nivel de formulario lo podrás usar desde el resto de procedimientos que son llamados desde el que crea el objeto....
Fíjate, ahora de entrada ya vamos a meter en u´n procedimiento el formateo de las casillas


No es necesario que me extienda más... debe quedarte claro como se procede....

Simplemente se trata de cumplir el lema romano: 'Divide y  vencerás'.  
Toma líneas de código que realicen una labor concreta y crea un procedimiento que con el nombre que define esa labor, mueve esas líneas a dicho procedimiento. Como has creado código espagueti, tendrás un montón de variables en el procedimiento, las variables que refieren objetos de excel declaralos a nivel de formulario  y las variables que se usan en muchos procedimientos también (por ejemplo la variable Adodc6), en cambio las variables que sólo se usen en un procedimiento las declaras locales (por ejemplo en el procedimiento 'CodigoMateriales', la variable 'cor' se refiere al bucle se declara y muere en el procedimiento la variable)  también podemos pasar variables declaradas en un procedimiento a otro mediante parámetros (por ejemplo, si te fijas la variable 'Varo' está declarada en el procedimiento original y se la hemos pasado como parámetro al procedimiento 'CodigoMateriales')

Eso, si declara todas y cada una de las variables en el tipo que son, o de otro modo se asume que son variant y las variables variant consumen mucho más recursos y son más lentas
Naturalmente cada escisión del procedimiento debe ser suplantado por la llamada al correspondiente procedimiento que contiene las líneas que hemos movido...

La idea no es que tengas 8 procedimientos de 200 líneas sino tal vez 15 unos con 40 líneas y otros con 120 líneas... conviene que los separes de acuerdo a labores concretas, si las siguientes 80 líneas dan formato, pués creas un procedimiento llamado DarformatoA... y metes ahí el código que realiza esa labor, si luego tienes 30 líneas que leen datos de un archivo pues creas otro procedimiento llamado TomarDatosFicheroTemporal, mueves ahí elcódigo que realiza esa tarea y donde estaban colocas la llamada a dicho procedimiento y así sucesivamente. Si las líneas no las separas reunidas por tareas tendrás muchas variables compartidas entre diferentes procedimientos lo que te forzará a declararlas a nivel de formulario. en principio no hay nada malo en tener variables declaradas a nivel de formulario, simplemente que las variables declaradas a nivel de formulario utilizan memoria hasta que se destruye elformulario, las variables de un procedimiento (declaradas dentro de él) se descargan de memoria cuando se sale del procedimiento....

Si tienes dudas, ahora ya puedes hacer preguntas concretas...

Vamos por partes...
- CreateObject y new son equivalentes... se utilizan para crear objetos activex (variables de tipo objeto).
- Entiendes los de seccionar en procedimientos, luego no daremos más vueltas a ello salvo que se te quede alguna duda en el tintero.
- Como dices que tomaste el ejemplo de una macro, evidentemente lo has copiado tal cual lo sacaste (lo entiendo así), como es tan largo que te da problemas, te ves obligado a repartirlo. Si lo haces sin más, sucedería que los valores se las variables se perderían, como dices que eres novato en VB6 (e intuyo que en programación), conviene que entiendas la 'vida de las variables', sobre ello hablamos un poco ahora...

Una variable cobra vida normalmente cuando se declara, cobrar vida significa que se añade a una 'tabla' el nombre de la misma, el tipo y la dirección de memoria donde se alojará, deesto se encarga el entorno de programación... sin embargo esta  tabla es un poco más  compleja, un modo de definirla sería imaginarse varias tablas, (o sólo 1 con con el campo alcance) con las indicaciones siguientes...
Cuando necesitemos que una variable esté disponible para todo el proyecto y durante toda la vida del mismo, la declaramos como global (o public) en un módulo (archivo .bas). Si en cambio queremos que una variable sólo esté disponible en un formulario y no en todo el proyecto la declaramos dentro del formulario (archivo .frm) si la declaramos public, implica que desde otro lugar que pueda acceder al formulario podrá accederse a ella, por ejmplo, tengo un formulario llamado FormExcel y tengo otro formulario llamado FormEjecuta dentro del primero tengo una variable declarada así: ' public Valor as long' entonces implica que desde formEjecuta podrá acceder a esa variable así
Si en cambio la variable valor la hubiera declarado así: ' Private Valor as long (private y dim es lo mismo aplicado a las variables), entonces en este caso  no puedo acceder a la variable valor desde fuera del formulario de forma directa...

Los procedimientos es como si fueran 'mini módulos', todas las variables declaradas dentro de un procedimiento sólo son accesibles desde dentro de ese procedimiento, por tanto obligadamente son privadas pero puesto que no admiten ser públicas, sólo pueden declararse  con dim no con private.
El acceso de una variable se suele llamar 'alcance' y está directamente relacionado con la vida de una variable... me extiendo.
Cuando se arranca un proyecto lo primero que se hace (de forma transparente al programador) es mirar si  hay módulos y toma todas las variables (globales y públicas) y procedimientos públicos y los añade a una tabla, todas estas variables se crean las primeras y duran todo lo que dura el proyecto, es decir ocupan memoria todo el tiempo que el proyecto. Luego mira si hay formularios, todas las variables y procedmientos públicos 'nacen' cuando se crea el formulario y su vida se agota cuando se cierra el formulario 'call Unload( me)' ojo, no si se oculta 'Me.Hide' .
Luego están las variables declaradas dentro de los procedimientos, realmente también están en una tabla, pero sólo se les asigna memoria cuando se accede al procedimiento y cuando salen del procedimiento  se 'tiran', se libera la memoria que ocupan (hay una tabla que diríamos master que contiene un identificador por cada formulario, módulo, clase, diseñador, usercontrol, etc... y esa misma tabla tiene todos los identificadores de acceso global en el proyecto, luego si cargamos un formulario se añaden a esa tabla o a una específica (esos son detalles del compilador de vb6, que no se especifican en ninguna parte) todos los identificadores del formulario, pero sólo se asigna memoria a  aquellos que son accesibles desde todo el formulario, luego si se entra en un prooocedimiento automáticamente a todos sus identiificadores se les asigna memoria.

Cuando se sale de un procedmiento, toda la memoria donde está contenida el dato, de cada identificador declarado dentro del procedimiento se libera, cuando se descarga el formulario 'unload me', se libera toda la memoria donde está contenido el dato de cada identificador publico y privado (variables métodos y funciones) , pero invocar cualquiera de sus identificadores públicos carga el formulario nuevamente, es decir siguen constando en una tabla pero no tiene memoria asignada al dato que representa, y como sucede con el procedimiento al cargarse (después de descargarse), todos sus identificadores tienes valores por defecto (ya sabes, un long vale 0, un byte vale 0 un string vale "" y una constante el valor consignado, cuando se cierra el proyecto se descarga todo...

Ahora vamos a hablar someramente de las 'cosas raras'... de entrada mencionamos las variables declaradas Static. En un procedimiento a veces puedes querer que una variable conseve su valor y al mismo tiempo que sea inaccesible desde fuera,  es decir que sólo pueda modificarse desde el procedimiento pero que su valor no se pierda al salir del mismo... ese es el caso de las variables static, una variable static de un procedimiento tiene el alcance del procedimiento pero la vida de su contenedor (si es un formulario, la de éste, si es un módulo hasta que se cierre el proyecto, si es una clase mientras esta exista, etc... Para que entiendasesto te pongo un ejemplo... práctico..

abre un nuevo proyecto, coloca un botón y pega el siguiente código y ejecútalo.... después que veas el resultado, para el proyecto, cambia  Static Total as long'  por  Dim Total as long'  y ejecútalo nuevamente.... verás la diferencia... en un caso y otro...

A un formulario no se le puede hacer el harakiri, por ejemplo ahora tenemos  2 formulario paraeste nuevo proyecto, el 1 tiene 3 botones llamados: Abrir, Eliminar y Listar en el otro tenemos uno llamado Cerrar... Copia y ejecuta elcódigo: fíjate que el último código de botón serefiere al del formulario 2

 Si le damos al botón abrir 5 veces seguidas, verás que sólo se abre una vez, pulsasobre él en el botón cerrar, repite, sólo se abre una vez... pero ahora lo eliminamos 'set form1= nothing', pulsandoen botón eliminar, ahora pulsa en el botón abrir, verás que se ha abierto '''otro''' form2, vuelve a pulsar eliminar y vuelve a pulsar abrir, aparecerá otronuevo formulario copia siempre del primero... si pulsas varias veces seguidas en abrir, verás que no se abren más, sólo cuando es eliminado... Qué ha pasado ? ...  un formulario no se aniquila desde el exterior, sino es descargado previamente, sin embargo al eliminar, lo que sucede es que lo elimina de alguna tabla, el  identificador desaparece, está fuera de proceso y no se ejecutan los eventos Terminate, ni Unload, pero sigue constando una referencia en la colección Forms del proyecto, al solicitar de nuevo abrir, como el no encuentra el identificador form2, carga una instancia de form2 (una instancia es una copia), sin siquiera haber declarado una nueva variable... esto se debe a que el proyecto siempre mantiene una referencia de cada formulario, ya que si se destruyera real y totalmente en un momento dado form2 no existiría y y en consecuencia, nunca más podríamos volverlo a abrir estando el proyecto en marcha, porque no sabría ni que objetos tiene ni cual es su código, etc... De hecho para comprobar que todo es correcto puedes pulsar (con varias copias de form2) en el botón listar del form1. En teoría la  única manera de crear instancias de form2 sería el siguiente código:
De hecho este código funciona exactamente igual que el anterior, en cambio si hubiéramos puesto 'set f= new form2' cada vez que pulsemos se creará una NUEVA instancia distinta de la anterior... antes all listar form2 siempre se pintaba de rojo, ahora no hay form2 abierto son instancias (con NEW),  por eso todos son amarillos.
Ahora lo bueno, si hemos dicho que todas las variables creadas en un procedimiento se destryen al salir del mismo porqué no se cierra y elimina el formulario al salir del mismo... la respuesta es que sólo sucede con las variables intrínsecas del entorno, los objetos se almacenan en la Tabla de Objetos en Ejecución, estos deben específicamente ser eliminados con Nothing y aún así los formulario deben previamente ser descargados para que éste libere sus referencias y el  proyecto lo retire de la colección forms. Un objeto sólo se descarga definitivamente cuando no quedan referencias al mismo.

Es posible llamar a un objeto de diferentes maneras, a esto se llama referencia. Imagina una persona que se llama Juan, algunos amigos le pueden llamar 'El bruto' y quizás sus padres le llamen 'Juanillo' en todos casos es la misma persona... un código de ejemplo:

Bueno, es bastante para este mensaje... ya tienes algunos conceptos más que espero te sirvan...
Si tienes más dudas, esponlas, pero mejor siconcretas ya que sino resulta una respuesta muy dispersa....

Sobre lo del manual ya en otro momento te respondo...

Te aclaro....

Cuando declaras la variable Varo a nivel de formulario, de entrada tiene el valor 0, hasta que le asignes un valor distinto. Varo está disponible sólo para el formulario, es decir si ese procedimiento está en un módulo o en otro formulario 'aquí' (en el formulario que lo utilizas) no se vé, nadie lo  conoce... Esto significa que puedes tener diferentes variables llamadas varo, una en un formulario, otra en un módulo e incluso  una dentro de un procedimiento dentro del mismo formulario... Puedes preguntarte, cómo especifico la que quiero usar, y cómo sabe VB6 cuál uso...?, te lo explico con ejemplos comentados in situ...


Igualmente, si tuviera un 2º formulario, con el código del ejemplo 1º...

Sobre los manuales que me preguntaste el otro día... supongo que tienes instalado además el MSDN de VB6, bién auqnue la gente, no lo suele utilizar (desconozco por qué), lo cierto es que trae algo más de 200 libros para manejar   en formato CHM, los hay específicos sobre temas muy concretos por ejemplo hay uno específico sobre el control Winsock.... los nombres no son muy aparentes ya que están abreviados, te indico los que interesan para empezar....
Se encuentran en la ruta equivalente en tu ordenador a: C:Archivos de programaMicrosoft Visual StudioMSDN9898VS3082

- VB98.CHM : Referencia de controles estándar de VB, los controles que por defecto te aparecen en la barra de herramientas....
- VBENLR98.CHM :  Referencia del lenguaje de Visual Basic , contantes, tipos de datos, funciones, instrucciones, objetos... del lenguaje
- VBREF98.CHM : Referencia de los controles de Visual Basic, éste es  referencia del lenguaje por orden alfabético, de controles, de asistentes, errores y proyectos de ejemplo completos... éste manual invoca a los anteriores y a otros más, por ello es más completo, pero en los otros aparecen detalles no reflejados en éste... por esta razón de referencias cruzadas entre archivos no conviene cambiarles el nombre.
- VBDEF98.CHM : Definiciones del lenguaje, por ejemplo que es un 'argumento con nombre', un 'procedimiento de evento', la 'negociación de interfaz de usuario', etc.... definiciones que podrán aparecer en cualquier manual y no sabes exactamente a que se refiere... para novatos es bueno tener esto al alcance.

y el más importante para ti de momento es éste:
- VBCON98.CHM : Manual del Programador... en los libros que trae, el último pone 'Usar Visual Basic', despliega ese y el primero es 'Manual del Programador'....



Importante: Si copias alguno de dichos manuales y lo pegas a otra carpeta, tienes también que copiar el archivo del mismo nombre que tiene por extensión CHI, lo mismo sucede si le cambias el nombre cuando lo pegues en otra carpeta, ambos deben tener el mismo nombre.

Ojo: no cambies los nombres ni muevas de sitio los manuales de VB, sino al  invocar la ayuda (pulsando F1 ) no lo encontraría (una base de datos mantiene las referencias por los nombres asociados a los temas, etc...  El archivo Chi, contiene los temas y el índice de donde localizar los temas en el archivo CHM, que el visor de CHM utiliza (en la TOC, Tabla de Contenidos).

Todavía: los mnauales que copies aparte si les cambias el nombre, al tener referencias cruzadas entre archivos puede no encontrar el tema solicitado, lo mismo sucederá si el archivo al que se llama no se localiza en la misma carpeta. A pesar de ello siempre es buena idea tener algunos donde uno pueda consultarlos en cualquier parte en cualquier momento... todos los libros de ayuda son unos 600 MB. por lo que hoy día tener una copia en una memoria USB, no supone el mismo problema que hace 10 años...

Para barbatusaf: Si tienes un codigo muy largo podrias poner algo asi, te reemplaza la comprobacion individual por una en un bucle for        ChDir "c:\TURNO DE NOCHE\Partes de servicio\"
        Workbooks.Open Filename:="c:\TURNO DE NOCHE\Partes de servicio\agosto.xls"
        Sheets("dia 1").Select
        for i = 1 to 25
            If ActiveSheet.Range("b" & i).Value = "" Then
            ActiveSheet.Range("b" & i).Value = 3
        next isiento tardar en responder, pero apenas vi tu mensaje