mlara, me alegro que hayas descubierto el misterio.
Algo me dice que tras muchas horas de estar peliandote con este problema vas a poder dormir más tranquilo.

Quisiera aprovechar, si no te es molestia, darte algunos consejos. Y es algo que ya te han estado aconsejando.
Por empezar ¿6000 líneas de código?:eek: Disculpa que lo diga pero es demencial. Si con 1000 ya son muchas, 6000 rebasa lo esperado y pensado.
¿Todo en una unidad?

¿A que se debe tan extraña necesidad?
Se que tras obtener 6000 líneas ponerse a modularizar y estructurar mejor va a ser un dolor de cabeza, pero a la larga te beneficiará. Conseguirás módulos más o menos independiente, por lo que el mantenimiento al código se hace más llevadero y además, mantiene un valor de cohesión posiblemente más elevado que tu diseño original.

Como te han sugerido, emplea frames. Si buscas frames en el buscador obtendrás hilos que tratan el tema.
Y aprovecha la herencia visual (de hecho, los frames se basan en ella). Un ejemplo, a modo de práctica, de como se consigue es esto:
1. Crear un form, añade unos controles y guardalo con el proyecto.
2. Ve a File -> New -> Other -> Proyect1 (o el nombre del proyecto).
3. Seleccionas el Form.
4. Selecciona la opción Inherit.
5. Presiona OK

Si has seguido los pasos, deberás obtener un nuevo Form, con la apariencia visual del Form elegido. Si te fijas en el código obtendras algo como esto:

Código Delphi [-]
form3 = class(Form2)
private
...

En mi caso, Form2, es el "padre". Del cual deriva el Form3.
Cualquier cambio que realices en Form2, se propagará a sus hijos, asi que cuando lleves a la práctica esta técnica debes asegurarte de que y como será el form base o padre sobre el que se heredará.

¿Y que pasa con el código?¿Que sucede si el form base tiene código?
El form que hereda de él hereda también el comportamiento de dicho código. He dicho comportamiento ya que no ves el código asociado al padre.
Supongamos que tienes un botón en la fdrma padre. Digamos que el código es este:

Código Delphi [-]
procedure TForm2.Button1Click(Sender: TObject);
begin
  ShowMessage('Estoy en form2');
end;

¿Que sucede si pulsamos doble click sobre el de la forma heredada?
Obtendrás una "extraño" palabra:

Código Delphi [-]
procedure TForm3.Button1Click(Sender: TObject);
begin
  inherited;
  
end;

¿Que signfica esto?
Pues simplemente que heredará el comportamiento y todo lo que haga en form2.
Modificamos el código, por algo como este:

Código Delphi [-]
procedure TForm3.Button1Click(Sender: TObject);
begin
  inherited;
  ShowMessage('He pulsado al botón de form3');
end;

Guarda y ejecuta.
Cuando se pulse el botón de Form3 recibirás dos avisos. Primero el de "Estoy en form2" y luego "He pulsado al botón de form3".

¿Y si le borramos la cláusula inherithed?

Código Delphi [-]
procedure TForm3.Button1Click(Sender: TObject);
begin
  ShowMessage('He pulsado al botón de form3');
end;

Simplemente se ignora el código del padre y obtendrás un flamante "He pulsado al botón de form3".

Creo que esto da una introducción (Tal vez demasiado rápida) al tema de herencia visual.

Espero que te haya sido de ayuda. Por el tema de frames, mejor no digo ya que se ha tratado, ya ha sido mucho sobre el tema.

Saludos,

Muchas gracias Delphius. Como decía más arriba en este hilo, quizá haya usado la herencia visual, aunque sea de forma intuitiva. Bueno, no sabía a qué exactamente se hacía referencia en ese momento, pero ahora que das el ejemplo, pues te cuento que en mis proyectos sí la he usado, y lo he intentado hacer de la mejor manera.

Bueno, la verdad es que no sé si pudiera usar la herencia visual en este proyecto específicamente para esta ventana. Te voy a contar por qué.

Se trata de una ventana de configuración. Como las que ya conocemos, tipo ventana de opciones de Firefox o la misma ventana Editor Properties del IDE de Delphi. Tenemos varias secciones de configuración. Cada una de estas hace referencia a una parte específica de nuestro sistema, exactamente a 35 secciones. Cada sección a la que se puede acceder a través de un TreeView tiene componentes como ComboBox, CheckBox, Edit, una que otra grilla, botones, imágenes, pestañas, etc. Las secciones se parecen muy poco unas con otras, y la ventana dentro del sistema es única.

Como puedes imaginar, en primera instancia no creo que pueda usarse la herencia visual, aunque sí estoy de acuerdo en que se puede optimizar el funcionamiento de dicha ventana. para dar una idea más exacta de lo que es, he decidido poner algunos "WindowShots" en este link.

Claro, como siempre, se aceptan sugerencias :), ya que entre otras cosas ya se me hace necesario optimizar esta ventanita.

Hola mlara,
A como veo, yo diría que en este caso lo más útil es emplear frames.
Los frames son como forms bajo la herencia visual, pero ha diferencia de éstos, se pueden crear/detruir a demanda y se incorporan a un form. es decir que un form puedes colocar más de um frame. Cada frame puede contener su código, y no necesitaría alterarlo.
Burdamente se podría decir que son forms dentro de forms.

¿Y parte del código puede reducirse?:confused:

Saludos,

mmm, pues no sé. En esto debo trabajar. Lo curioso de esta ventana es que a través de ella no se hacen procesos complejos ni nada que se le parezca, ya que simplemente se leen y guardan los valores de configuración, salvo en un par de secciones en donde se usan algunos componentes de base de datos. Para dar una idea del código, transcribo un fragmento del mismo aquí:

...y así continúa. Solamente este procedimiento tiene 398 líneas. Hay forma de reducir este código? Ya trabajaré en ello, pero inicialmente no lo veo sencillo, a no ser de que cada componente lea y guarde automáticamente el valor. Se me ocurre por ejemplo que podría usar un CheckBox extendido al que se le pueda especificar a traves de sus parámetros el lugar de lectura y escritura del valor. Aunque por ahora estudiamos cuáles de estos valores deberían almacenarse en el cliente, y cuáles en el servidor (en la base de datos).

La verdad es que la tienes dificil:(
En fin, quedará en ti analizar si es viable a estas alturas estructurar el código.

Lo único que se me ocurre es separar la configuración en varias partes, lo más independientemente posible, en formas separadas y tratar de conseguir un procedimiento al estilo:

procedure SaveConfiguratiosFromForm(TForm: TCustomForm);

Y buscar la manera de centralizar en un sólo punto los elementos comunes.
O algo por el estilo.

E incluso, se podría conseguir con los Frames.
Yo al menos soy de la idea de que si hay mucho que configurar, separo el trabajo en diversas configuraciones.

No se que más decirte por el momento, se me acabaron las ideas por hoy... Se me está apgando el cerebro:(:o.

Por el momento, lo que si puedo darte es ánimos. No dejes que esas KLDC te dominen.

Saludos,

jajajajajjj... muchas gracias Delphius.

y bueno, yo por hoy me voy a dormir, después de las horas buscando la razón del error, como dijiste, puedo dormir más tranquilo.

Saludos.

¡Que bueno que llegamos a una conclusión mlara! :)

Sería interesante ver si en Delphi 2007 ocurre lo mismo o si ya había sido tomada en cuenta la sugerencia de aceptar LFs solos.

Esa es una de las razones por las que hace tres o cuatro años buscaba un componente conjunto de datos (data set) tipo TIniDataSet o algo por el estilo que me permitiera capturar valores de un archivo .ini en controles data aware, pero aquella búsqueda resultó infructífera.

Desde mi punto de vista, ninguna rutina debe tener más de unas cuantas decenas de líneas. He llegado a crear algunas de hasta 50 o 70 líneas, pero por lo general no las escribo con más de un pequeño puñado de sentencias. El código atomizado es más fácil de depurar y mantener y goza de mayor aprovechamiento.

Se empieza por buscar patrones de código consistentes, susceptibles a ser optimizados.
Aquí vemos que se hacen varias llamadas al mismo método (IniFile.WriteBool), guardando en la misma sección (LogrosAsistencia) del archivo INI, el estado que presentan diversos cuadros de verificación, los cuales llevan el mismo nombre que la llave que les corresponde, con excepción de las tres primeras letras (ckbOrganizarEstudiantesAuto -> OrganizarEstudiantesAuto).

Se me ocurre que puede escribirse un procedimiento que pueda ser llamado de esta forma:

Código Delphi [-]
  GuardarChecks ('LogrosAsistencia', ['OrganizarEstudiantesAuto', 'ConservarCodigoLogro', 'ConservarValoracionLogro', ...]);

Incluso podría reducirse más, lo anterior es solo una aproximación. ;)

Me alegro por haber ayudado a resolver el misterio.

Un abrazo con retorno y sin fin.

Al González. :)

Ejem, ahora estoy trabajando con una unidad que tiene 30.000 líneas de código, no lo he creado yo, es algo comercial, digamos... "un componente".

Como en todo, se dice el pecado pero no el pecador, así que hasta aquí puedo leer.

Lo que sí es cierto es que Delphi 7 + GExpert + cnpacks se comporta de forma excelente manejando esos archivos.

Saludos

Bueno, antes que nada gracias nuevamente a Delphius y a Al por sus sugerencias. La última sugerencia de Al es muy buena. La tendré muy en cuenta. Por otra parte, y con relación al número de líneas de código, no quise discutirlo antes, pero pienso que no es bueno limitarse tanto, aunque siempre pensando en que el código debe estar bien estructurado, y que cuando sea necesario hay que usar POO. Yo particularmente he escrito algunos procedimientos en SQL y también otros en Delphi que tienen algunos cientos de líneas, luego de haberlos depurado "al máximo" (aunque claro, siempre se puede un poco más).

Yo en ningún momento lo hice con desprecio, sino más bien de asombro. Yo he llegado a escribir un poco más de un KLDC en algunas unit. Pero llegar a esos valores no.

Disculpa que lo diga, pero el haber dicho "se dice el pecado pero no el pecador" no me agradó demasiado. Como si yo hubiera cometido una ofensa.

Lepe te pido disculpas si te has sentido ofendido.
No pretendo decir que está mal tener miles de líneas, pero es que cifras tan altas llaman a revisión y examen.
No se cuales son los motivos por los cuales te ves envuelto en esas 30000 lineas, pero Dios quiera que no te sea dificil entenderlas. Será que me cuesta creer que en la idea de más de 2 KLDC.

Pero, yo en ningún momento he machacado a alguien por escribir x lineas en vez de y. Simplemente he dado una opinión.

Será que tengo demasiado (tal vez, en extremo) impregnado en mi el sentido de reducir el código. No me creo un genio en programación y respeto tus grandes dotes de programación, pero no hace falta ser un genio para saber que donde hay miles de lineas, el encontrar una posible fuente de error (en caso de que exista) es un dolor de cabeza. Y posiblemente el esfuerzo en solucionarlo sea más que el de sólo hallarlo.

Lo siento si alguien se molesta el que diga esto. Pero lo cierto es cierto: la magnitud e impacto de un error es proporcional a la cantidad de líneas.
No es lo mismo detectar y solucionar un error en 1000 lineas, que detectarlo en 100000.
Tal vez se puede haber una excepción a la regla. Pero mientras tanto, yo prefiero someterme a un valor bajo de LDC/Unidad.

Y repito. Sólo es mi opinión.
Saludos,

No, perdona, el ser escueto trae estas consecuencias. No es lo que piensas ni mucho menos.

Lo normal es tener en una unidad, como máximo, 1.000- 2.000 LDC, si se necesita más, empieza a cuestionar el diseño, tienes toda la razón.

En mi caso concreto, estoy trabajando para una empresa, compró los fuentes de "un componente comercial" y éste tiene varias unidades, la media, 30.000 LDC cada archivo. Puesto que no he comprado yo los fuentes, no me parece correcto decir el nombre de "ese componente", de ahí la frase "se dice el pecado pero no el pecador",. Como ves esa frase no iba hacia tu persona, sino al propio componente y a sus creadores .

Te pido disculpas por dejar tanto margen a malinterpretaciones.


En estos momentos hasta Dios se está riendo de mí :D :D
Mi comentario iba más en ese sentido, existir... existe componentes comerciales que superan los dos kilos.

Y estoy totalmente de acuerdo con tu opinión.

OK. Entendido, y disculpame por haberme ofuscado. No quería enojarme, pero es que me había sentido un tanto tocado.
Disculpame por no haber sabido manejar la situación.

Saludos,