Expected ':' but an identifier found.
 

No se cómo sucedió, es la verdad. Trabajaba un día sobre una ventana que tiene muchos componentes y mucho código. El dfm tiene 354 KB y el pas 174 KB. Bueno, lo menciono por si acaso.

Creo que eliminaba algunos componentes cuando de repente salió el mensaje al intentar compilar el programa. Después de tratar volver atrás, la única forma en que pude compilar el programa fue adicionando una línea de comentario :confused:. Y aunque me pareció absurdo, no tuve más tiempo para probar, así que esta ventana se quedó así.

Luego, mes y medio más tarde debo realizar modificaciones a la dichosa ventana y claro... nuevamente no me deja hacer nada. No me deja eliminar componentes, no me deja poner nuevos componentes, y es más, cuando intento algo así, nuevamente no puedo compilar y debo mover la línea de comentario a otro lugar. En todos los casos siempre sale el mismo mensaje:

Expected ':' but an identifier found.

¿Qué $·%#"|\\**)/$ significa esto?

El código está bien, no uso componentes extraños, y traté de revisar un poco a vuelo de pájaro el dfm, y la verdad lo veo bien.

Alguien tiene idea de por qué sucede esto. Le ha pasado algo así?

De no solucionar esto, me quedo varado sin poner hacer cambios a la ventana. Como es tanto código y la ventana tiene tantos componentes, no es fácil reconstruirla... me tomaría muchíííííísimo tiempo, que no tengo.

Como comprenderás sin ver el código es practicamente imposible darte una solución con sentido.

Lo único que se me ocurre es que tengas alguna palabra, nombre, variable,... que se confunda con algun elementos reservado de la sintaxis de Delphi.
Pero vamos, que la propbabilidad de acertar con los datos que das, debe ser aproximadamente de 1 entre 25 millones. :o

Normalmente el error te dice en qué línea es.
Envía el trozo de código que contiene el error.

Se me ocurre también que el error sea justo después de compilar, cuando ejecuta la aplicación. En este caso el error saldrá en una ventana pequeña en el centro de la pantalla.

Puede ser que al ejecutar el programa se abran tablas de una base de datos.
Los parámetros, suele ponerse como ":NOMBRE_PARAMETRO".
- Puede ser que alguna tabla tenga el sql mal hecho.
- Si se genera el sql en tiempo de ejecución, puede que se olvide de algún parámetro.

Con esto ya puedes verificar 1 de las 25 millones de posibilidades de error. :D

Concuerdo con los mensajes aneriores, y añado algo más:
Esos tipos de errores me suenan a incongruencias entre el .dfm y el .pas, incluso en cosas aparente absurdas como eliminar líneas vacías o de longitud desmesurada con espacios.

También puede ocurrir que el error mostrado no tenga nada que ver con el que realmente cause el problema. Este tipo de cosas son muy muy raras :D


Saludos y Suerte

Quien acerta más es Lepe seguido de Neftali. Quiero decir que el problema no es con parámetros en consultas SQL, ni tengo problemas de sintaxis. Voy a tratar más despacio de encontrar el problema... si llego a un grado tal que pueda volverme loco o algo por el estilo, sin solucionar el problema... vuelvo por aquí, que es lo más seguro.

PD. Urgente: El sistema no está enviando los correos para avisar que un hilo tiene un nuevo post (Notificación instantánea por correo electrónico). Si alguien puede verificar...

OFF-TOPIC:
Quise enviarte un privado para comentarte sobre esto, ya que no quería desvirtuar el hilo, pero tienes la casilla llena.
Pues me parece raro ya que yo lo estoy recibiendo sin problemas.
¿No será que por error? te desuscribiste?
Cuando uno recibe el mensaje, hay varios links, entre ellos está la opción de desusbrirse del/los hilo/s. Tal vez por error diste clic sobre ese enlace.

Saludos,

Muéstranos la parte del código donde el compilador encuentra ese error.

Es probable que hayas borrado por accidente los dos puntos que le siguen al identificador (y quizá algo más) en la declaración de uno de los componentes dentro de la clase formulario.

Déjanos ver la parte del código donde el compilador te señala el error, eso es básico para poder auxiliarte.

Esperamos tu retroalimentación.

Saludos.

Al González. :)

En este preciso instante estoy suscrito a 6 o 7 hilos, y tengo que estar buscando para saber si alguien ha contestado. No es por error. Algo sucede.

No me había dado cuenta que habías contestado... Espero que me sigan llegando las notificaciones automáticas, porque si no... :mad:. Je je, bueno, si alguien de paso puede verificar lo que está sucediendo les agradezco mucho.

Bueno, en este link puse unas imágenes que muestran lo que sucede.

Muchas gracias Al y a los demás por su colaboración.

:mad::mad::mad: ... la culpa era mía, pero les aseguro que no sé a qué hora sucedió. La dirección del foro estaba bloqueada en mi correo. :mad::mad::mad:.

:D, mis disculpas.

No sé yo, pero si esa es la línea 602 del código fuente y todavía estamos declarando variables privadas, miedo me da el resto.

mlara, lo raro es que funcione algo :eek::eek:

Creo es hora de crear frames y que se creen en tiempo de ejecución, sólo aquellos que se necesiten. Aunque mejor me callo porque será inviable....:cool:

Saludos

El error no es arrojado por el compilador (los errores, advertencias y mensajes de compilación son enlistados en una ventana especial), sino por el analizador sintáctico ("parser") del IDE. La prueba de ello sería mostrar el formulario e intentar ir al código DFM presionando Alt+F12. Al hacer esta operación deberá mostrarte el mismo mensaje de error.

Esto descartaría al compilador como el responsable del extraño error, incluso puede que la compilación sea perfectamente viable desde la línea de comandos. El problema aquí es algo en el IDE.

¿Cuántas líneas de código tiene en total tu unidad .pas? Probablemente exista un "bug" relacionado con la capacidad de líneas que puede manejar el editor.

Mi otra pregunta sería: ¿tienes instalado algún accesorio (experto / wizard) en el IDE que pudiera interferir con la manera en que el entorno maneja el código fuente?

Por otro lado, considera que tal vez sí hacen falta los dos puntos en alguna línea de la declaración de la clase, pero por alguna razón el analizador sintáctico lo señala en la 602. En ese caso el compilador de línea de comandos también te señalará el error, pero, con algo de suerte, en la línea que realmente omite los dos puntos. ¿Qué te parece si haces esta prueba? ;)

No dejes de mencionar qué versión de Delphi es la que tienes con ese problema.

Independientemente de todo lo anterior, considera seriamente el uso de herencia visual y técnicas similares para una eficiente estructuración de tu proyecto. Pero primero lleguemos al fondo de esto.

Esperamos nuevamente tu retroalimentación a este interesante caso.

Al González. :)

Al... estoy en línea (almorzando). En un momento regreso y te cuento.

Provecho, yo haré lo mismo en un rato con lo que quedó del Pollo Feliz de ayer. :p

1. Efectivamente al estar en el form y presionar Alt+F12 se muestra el mensaje de error.
2. Líneas de código: 4506 hasta el end.
3. No tengo instalado ningún experto / wizard del IDE.
4. "Estoy seguro" de que no hacen falta dos puntos en cualquier línea de declaración de la clase del form. Si así fuera, incluso poniendo el comentario no dejaría compilar el programa.
5. Uso Delphi 7.
6. "herencia visual" <- No he usado alguna vez esta técnica. Si lo he hecho, quizá intuitivamente.

Además aún no uso el compilador de línea de comandos, pero me dispongo a hacerlo. Sigo en línea.

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.

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?

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.

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 :D.

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 :D.

Gracias a todos.

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.

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,