Tareas repetitvas en tiempo de diseño
 

Hola, aqui seguimos con mas detalles insignificantes.:)

En primer lugar no sabía como titular el post:(. Perdon.

En segundo lugar, a ver como me explico. En una aplicación en la que tengo un form con campos del tipo dbtext en los que inicialmente los tengo con la propiedad readonly en true para que no se puedan modificar, luego tengo un boton de añadir registro, otro de cancelacion y otro de aceptar, respectivamente, insert, cancel , y post (este ultimo con un commretaining).

Me gustaria saber si hay alguna forma de evitar escribir codigo para no tener que escribir una procedure en la que, si quiero añadir registro, me ponga readonly en false en cada uno de los campos por ejemplo.

Otra procedure para volver a ponerlos en readonly en true.
Se que es una pregunta de vago, pero tengo muchos campos de diferentes tablas y es un engorro.

Perdon por la preguntita.

gracias

Que yo sepa, no se puede. La forma más cómoda que conozco es crear un método "ActualizaEstados", el cual lo que hace es revisar unas variables (o parámetros pasados a dicho método) y desactivar/activar o mostrar/ocultar los componentes adecuados, y llamar a este método desde los eventos adecuados.

Gracias por contestar,
Digamos que casi es lo mismo que meter todos los datos en una procedure o function, pero tratado de forma diferente, pero aun asi hay que escribir uno por dbcampo.

Por supuesto que se puede

Creas un descendiente de TForm, este sera tu ancestro comun para todos los form que mantengan una serie de DBEdits

Luego, hay 2 formas de manejar la coleccion de DBEdits:

1) A lo Poor man's: Recorres el arreglo de controles del form, preguntas si es un TDBEdit, si lo es, realizas un cast y modificas su propiedad ReadOnly

2) Mas elaborado: En tu ancestro TForm, declaras una lista de DBEdits; esta lista va a contener la coleccion de DBEdits que te interesa que se cambie su propiedad ReadOnly; luego, en el constructor, invocas a un método abstracto que se encargue de llenar dicha lista.

Luego es cuestion de proveer un metodo que recorra esa lista y cambie el valor de ReadOnly en cada iteracion

Hola,
puedes recorrerte los componentes de formulario o del panel y hacer lo que necesites.

formulario.ComponentCount


hay un montón de ejemplos por ahí.

Saludos

A mi no me queda claro qué es lo que quieres hacer. Da la impresión de que quieres poder insertar registros nuevos pero no editarlos. Si fuera en estos términos generales, bastaría con programar el evento OnBeforeEdit de cada DataSet:

Código Delphi [-]
procedure TForm1.AlgunDataSet1BeforeEdit(DataSet: TDataSet);
begin
  Abort;
end;

y con ello evitarías que los datos se editen sin tener que lidiar con cada campo o DBEdit. Incluso puedes asignar el mismo manejador de evento a los DataSet que te interesen.

Pero, si en cada caso son sólo unos campos los que deben ser ReadOnly y otros no, entonces no veo manera de hacerlo genérico y lo más cercano sería lo que te comenta Agustín (segundo método) en el que tu llenas la lista de los DBEdit que no quieresque editen.

LineComment Saludos

Gracias a todos por contestar.

Lo que pretendia hacer un form, digamos estandard, donde pudiera ver un registro de una tabla sin poder modificarla, o poder insertar uno nuevo, o borrarlo o modificarlo, todo eso a base de botones. Direis que lo mas facil seria usar un dbnavigator, pero queria aplicarlo con campos dbtext. Poer un boton para insertar, otro para editar por ejemplo.
Vamos son tareas repetitivas para cada registro de cada tabla de una base de datos. Cuando tienes muchas tablas y muchos campos por tabla, se hace tedioso escribir cada campo en una procedure y habilitar o no determinadas opciones por campo.

La pregunta es como lo haceis vosotros que llevais mucho tiempo en esto ;).

Gracias

Pues insisto en el evento OnBeforeEdit. Puedes hacer que tus botones controlen una variable booleana, digamos CanEdit y modificas el evento así:

Código Delphi [-]
procedure TForm1.AlgunDataSet1BeforeEdit(DataSet: TDataSet);
begin
  if not CanEdit then
    Abort;
end;

LineComment Saludos

gracias por el aporte,
perdon pero soy un poco burro, se que debe ser facil entenderlo pero no lo veo claro.

Lo que te dice AgustinOrtu es basicamente lo que se hace.

Lo que quieres es hacer algo con el minimo esfuerzo? Pues eso es lo que hacen los controles DataAware junto al DataSet (que tiene exactamente eso que quieres).

Si no quieres usarlo? Pues te toca hacer lo que te dice AgustinOrtu. Hay formas mas o menos elegantes de lograr esto, pero todas seran variaciones de esos dos tipos.

Si si, gracias, lo que digo es que no entiendo como se implementa de esa forma, con los controles dataware en lazarus, que no se por donde estan o como se usan. :(

Es que eso de recorrer la lista de componentes... Nunca ha terminado de gustarme lo del RTTI. Que sí, que será muy útil, pero no termino de verlo.

¿Quién dijo RTTI?

LineComment Saludos

Lo de recorrer la lista de componentes de un formulario, ¿no necesita RTTI para que funcione? Pregunto.

No. Lo que trae Delphi de fabrica es similar a crear mi propio arreglo (matriz) de componentes y exponer una propiedad para poder evaluarlo.

Basicamente, al poner un control se hace algo como: Formulario.ObjetoPadre.Add(ObjetoHijo). Y eso a donde va? a un arreglo.

RTTI tiene que ver con "Introspección", que es la habilidad de poder evaluar las características del entorno/runtime/código desde dentro del mismo runtime. Si es un poco "deficiente" en Delphi, es que eso es un problema universal en los lenguajes con compilador Y tipos estáticos y sin un soporte de runtime potente, que es casi todos. Y es muy facil y natural en lenguajes con tipos dinámicos (como python), interprete (que es un introspector!) o con compiladores dinámicos (JIT). Por eso en .NET/Java es ligeramente mas potente la introspección (aunque sigue siendo engorroso en contraste con el codigo normal). En donde introspección/código normal es casi que lo mismo es en lenguajes homoiconicos como LISP, FORTH y demás.

Tal como dice Mario. Aunque por un momento me ha entrado la duda de si el operador is -que casi seguro sería necesario en este contexto- no cae en el terreno de RTTI.

LineComment Saludos

Si no estoy equivocado, el operador is esta implementado mediante RTTI, lo cual lo hace "seguro" y "completo"; tambien devolveria True en los casos en que los objetos, pudiendo ser de distintas clases, son de asignacion compatible; esto tambien aplicaría a interfaces (siempre y cuando se declaren con GUID)

Por otro lado por eso sigo pensando que la opcion 2 es mas segura en este caso, pudiendo usar colecciones con tipos genericos, o si se trata de las versiones mas antiguas de Delphi, un array of TDBxxx

Es posible que esté implementado como dices. Pero, por otro lado, la funcionalidad de is es la que esperaría tener en cualquier lenguaje orientado a objetos, siendo la herencia una de las premisas fundamentales en OOP. Por ello no sé qué tanto pueda calificar como RTTI.

Esto no lo entiendo. En la versión en la que me quedé (la 7), A is C significa A es de la clase C o desciende de ella. Nada más. No sé que signifique "asignación compatible". Y en el caso de interfaces, al menos en la versión 7, el operador is no sirve. Es el operador as el que puede o no usarse según declares el GUID o no.

Je, je. Pues yo sigo pensando que lo más fácil es mi opción pues no hay más que asignar un evento y asignar alguna variable :)

LineComment Saludos

Veo que la duda que tenía es bastante común (si "IS" necesita RTTI o no). Si no recuerdo mal, Delphi 6 (que es donde me quedé yo) necesita que se compile con RTTI para que IS funcione. No sé si en versiones posteriores han optimizado algo y ya no es necesario.

Creo que no. is funciona aún con {$M-}. Compilar con RTTI ({$M+}) en Delphi 6/7 lo que permite es la existencia de propiedades published.

LineComment Saludos