Contrastando mi forma de trabajar con el tuto de Caral

[roman]

Unas precisiones a la estupenda explicación de Lepe en cuanto a la forma de acceder a los campos:

En la primera forma -los campos persistentes- si bien pueden usarse las propiedades AsXXXX, de hecho puede directamente usarse la propiedad Value. En otros casos, Value no sería recomendable porque a nivel de TField, se trata de un tipo genérico Variant, cuyo acceso no es óptimo; pero en el caso de campos persistentes, cada campo se crea del tipo adecuado: TIntegerField, TStringField, TBooleanField, etc.

En la tercera forma:

Tabla.Fields['NombreCampo'].Asxxxx

más bien sería

Tabla['NombreCampo'].Asxxxx

o

Tabla.FieldValues['NombreCampo'].Asxxxx

// Saludos

[Kenobi]

Despues de ver este interesante hilo, me doy cuenta que yo estoy haciendo las cosas distinto a la mayoria (sera por mi pasado foxPro .. no se)a lo cual pregunto ...

yo accedo a los campos asi .

edit.text:=TablaCampo.value;

digo es rapido de escribir menos codigo que ...

edit.text:=TablaCampo.AsTipo


Jajaja es una letra menos ....

no en serio que tiene de malo mi forma para cambiarla ya ....

Gracias ....

[[egostar]]

Empezado por Kenobi

yo accedo a los campos asi .

edit.text:=TablaCampo.value;

digo es rapido de escribir menos codigo que ...

edit.text:=TablaCampo.AsTipo

Hola,

Genéricamente te puedo comentar que un Tedit solo almacenará datos de tipo texto, por tal motivo si tu campo es un entero y asignas con .Value te saltará una hermosa carita de error , en cambio si asignas al Tedit el valor como .AsString, aunque tu campo sea entero esta forma lo 'pasa' a texto.

Salud OS

[Kenobi]

Claro tienes razon egostar, por supuesto que en caso de un numero pues

edit1.text:=InttoStr(TablaCampo.value);

por supuesto que si no lo hago asi pues bummm

ahora entiendo que con .AsXXX no lo haria pues a probar ...

Gracias ...

[Softweb]

Empezado por Kenobi

Claro tienes razon egostar, por supuesto que en caso de un numero pues

edit1.text:=InttoStr(TablaCampo.value);

por supuesto que si no lo hago asi pues bummm

ahora entiendo que con .AsXXX no lo haria pues a probar ...

Gracias ...

Hola voy a dar mi opinion ya que e usados todas las formas que nombrais en el hilo de manejar un campo.

No estoy de acuerdo de que sean buenas las formas:
Campo[1]
Campo[nombre]
Campo.value

ya que con esto el peligro es que trabajamos con campos variant los cuales no se comprueban en el copilado si no en ejecucion con lo cual nos podemos encontrar con mas de un problema.

Código Delphi [-]var1: integer; var2: string; CampoEntero1[nombre] := var1; //CampoEntero1 contiene nil CampoEntero1.asinteger := var1; //CampoEntero1 contiene 0 CampoEntero1[nombre] := var2; //Con esto revienta la aplicación CampoEntero1.asinteger := var2; //Con esto no copila la aplicacion

Ademas no es lo mismo escribir

Código Delphi [-]'La fecha es '+DateTimeToStr( CampoFecha[nombre] );


Lo cual ademas si no tiene un valor el campo revienta la aplicacion.

que

Código Delphi [-]'La fecha es '+CampoFecha.AsString;



Espero sea util, Saludos.

[[Lepe]]

A veces, es preferible que la aplicación reviente.

Imagina que el usuario no ha escrito la fecha para un registro. Si usas fecha.AsString, nos devolverá un valor 31/12/1900 y el programa sigue corriendo con "total alegría", si hacemos cálculos con esa fecha, nos dará un error en nuestro código, pero muy alejado del origen (quizás al imprimir el registro, al abrir una consulta que hasta ahora funcionaba correctamente, etc), tendrás que buscar durante mucho tiempo esa "avería".

Si el programa revienta en la linea "DateTimeToStr( CampoFecha[nombre]" inmediatamente le dices al usuario: "ah!!, es que tienes que poner una fecha válida." y no te da dolores de cabeza.

Por cierto, una precisión: Si una variable Variant no tiene asignado un valor, su valor es precisamente "unassigned" que no tiene nada que ver con "nil".

Como siempre, todo depende de qué resultado quieras tener.

Saludos