Expected ':' but an identifier found.

[[mlara]]

Acabo de compilar el programa con el compilador de línea de comandos. No hubo inconveniente, así que es definitivo, el problema es con el IDE y específicamente con el analizador sintáctico. Y ahora? Voy a buscar en el dfm, después de cada object debemos encontrar el nombre del componente seguido de dos puntos y luego del nombre de la clase. Espero tener suerte, ya que encontré 676 objetos.

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

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