Expected ':' but an identifier found.

[[mlara]]

El archivo dfm tiene 9192 líneas. Hice un pequeño programa para ayudarme, y encontró lo siguiente:

1. Los 676 objetos tienen sus respectivos dos puntos después del identificador o nombre del objeto.
2. El identificador de nombre más largo tiene 41 caracteres. Luego le siguen algunos de estas longitudes: 1 de 37, 1 de 36, 1 de 35, 1 de 34, 2 de 33, 4 de 32, y de ahí hacia abajo los demás.

Estaba pensando que podía ser el identificador de longitud más larga.

Cuál es el número máximo de caracteres que puede tener un identificador?
Además, de acuerdo a la sintaxis del dfm, cuándo se espera que aparezcan los dos puntos además de después del identificador y antes del nombre de la clase?

[[mlara]]

Tengo dos versiones de mi programa. Las dos trabajan con versiones muy similares de Configuracion, hasta el momento "prácticamente iguales" (en realidad sobre la que tabajo actualmente ya tiene varios cambios), y con el otro programa no tengo problema. Eso quiere dedir que no tiene nada que ver el tamaño de los archivos ni su número de líneas, y tampoco la longitud de los identificadores.

[[mlara]]

Jajajaj... esto la verdad no me lo imaginaba.

Aunque la verdad no me parece muy gracioso pues he perdido muchas horas revisando línea por línea. Les voy a contar que sucedía, y eso por no dejarlos con la duda .

Pues resulta que uso el Notepad++ para editar mis archivos de texto, ya sean scripts .sql, código .pas o .c, formas .dfm, archivos por lotes .bat, de configuración .ini, archivos planos .txt o .csv, etc.

El por qué los .pas, es sencillo. El Notepad++ ofrece herramientas que el editor de Delphi no tiene. Necesité realizar muchas modificaciones clave de una versión a otra y por eso usé esta aplicación, con muy buenos resultados.

Quizá, y como me ha sucedido últimamente por no haber dormido muy bien, le cambié el formato al archivo .pas de DOS\Windows a UNIX. Claro, el final de línea en Windows se representa con un CRLF, mientras que en UNIX es un LF.

Esto hacía que el IDE de Delphi fallara mostrando mensajes sin sentido como este:

"Expected ':' but an identifier found"

, en prácticamente cualquier línea. Lo que me sorprende es que haciendo algo tan absurdo como poner un comentario antes de la línea lograra "engañar" al analizador sintáctico.

Tiene lógica que el compilador no fallara, porque supongo que para este el final de línea puede ser tanto CRLF como LF.

Estaba a punto de volverme loco .

Gracias a todos.

[[mlara]]

Podríamos sugerir a CodeGear que en sus próximos analizadores sintácticos incluyera la posibilidad de trabajar con archivos en formato UNIX / Linux, o que detectara el formato de los archivos. Ahí va entonces para Andreano esta sugerencia. A cualquiera podría sucederle luego, cierto? Más si trabajan con CLX para compilar sus programas en Delphi o en Linux.

[[Delphius]]

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? 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,

[[mlara]]

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.

[[Delphius]]

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?

Saludos,

[[mlara]]

Empezado por Delphius

...
¿Y parte del código puede reducirse?

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í:

procedure TfConfiguracion.bGuardarCambiosClick(Sender: TObject);
var
  IniFile: TIniFile;
  CI, TextLine, ModoVista: string;
  I: Short;
begin
  CI := IntToStr(fMaestro.CurrentInstitution);
  IniFile := TIniFile.Create(fMaestro.IniFileName);
  // + Estudiantes - Datos adicionales
  with sgDatosAdicionalesEstudiantes1 do begin
    IniFile.WriteString('Estudiantes', CI+'-Dato1_Nombre', Cells[4, 1]);
    IniFile.WriteString('Estudiantes', CI+'-Dato2_Nombre', Cells[4, 2]);
    ...
    if Cells[3, 1] = 'SI' then
      IniFile.WriteBool('Estudiantes', CI+'-Dato1_Habilitado', True)
    else
      IniFile.WriteBool('Estudiantes', CI+'-Dato1_Habilitado', False);
    ...
  end;  
  // + Indicadores
  IniFile.WriteBool('Logros', 'AutoInc', ckbAutoIncCodigoLogro.Checked);
  IniFile.WriteInteger('Logros', 'LogrosConsulta.Rejilla', rgRejilla.ItemIndex);
  if rbDistribucionVertical.Checked then
    IniFile.WriteInteger('Ventanas', 'LogrosConsulta.DBGLogros.Style', 2)
  else
    IniFile.WriteInteger('Ventanas', 'LogrosConsulta.DBGLogros.Style', 1);
  // + Evaluaciones y asistencia (Estilo de visualización)
  IniFile.WriteInteger('LogrosAsistencia', 'Estilo', rgEstiloEvaluacionesAsistencia.ItemIndex);
  // + Evaluaciones y asistencia (Estilo de visualización por estudiante)
  IniFile.WriteInteger('LogrosAsistencia', 'EstudiantesVisibles', rbEstudiantesVisibles.ItemIndex);
  IniFile.WriteBool('LogrosAsistencia', 'OrganizarEstudiantesAuto', ckbOrganizarEstudiantesAuto.Checked);
  IniFile.WriteBool('LogrosAsistencia', 'ConservarCodigoLogro', ckbConservarCodigo.Checked);
  IniFile.WriteBool('LogrosAsistencia', 'ConservarValoracionLogro', ckbConservarValoracion.Checked);
  IniFile.WriteBool('LogrosAsistencia', 'AutoDesplazamiento', ckbAutoDesplazamiento.Checked);
  IniFile.WriteBool('LogrosAsistencia', 'FaltasTotalesPeriodo', ckbPermitirFaltasTotalesPeriodo.Checked);
  IniFile.WriteBool('LogrosAsistencia', 'ForzarAreaMateria', ckbPermitirForzarAreaMateria.Checked);
  IniFile.WriteBool('LogrosAsistencia', 'NoActualizarEval', ckbNoActualizarEval.Checked);
  IniFile.WriteBool('LogrosAsistencia', 'SolicitarDocumentoRec', ckbSolicitarDocumentoRespaldoRec.Checked);
  // + Evaluaciones y asistencia (Estilo de visualización por materia)
  IniFile.WriteInteger('LogrosAsistencia2', 'NombresApellidos', rgListaEstudiantes.ItemIndex);
  IniFile.WriteInteger('LogrosAsistencia2', 'DireccionEvaluacion', rgDireccionEvaluacion.ItemIndex);
  IniFile.WriteInteger('LogrosAsistencia2', 'TipoSonido', cbSonidos.ItemIndex);
  ...

...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).

[[Lepe]]

Empezado por Delphius

Por empezar ¿6000 líneas de código? Disculpa que lo diga pero es demencial. Si con 1000 ya son muchas, 6000 rebasa lo esperado y pensado.
¿Todo en una unidad?

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

[[mlara]]

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).

[[Delphius]]

Empezado por Lepe

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

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,