Consejos para configuración de las Rejillas

[elrayo76]

Hola a todos, hoy los molesto por lo siguiente y creo que a muchos les va a servir si se puede resolver de alguna forma genérica. Lo que necesito mas que como hacerlo es una sugerencia.

Estoy diseñando unas clases bastante genéricas para configurar las grillas y me gustaria saber determinadas cosas como las puedo realizar.

1) Quisiera que me dijeran como se puede hacer para apuntar a una grilla desde la clase sin que sea solamente para un determinado componente. Digamos si hoy alguien usa las DBGrid de Delphi que funcione, pero si mañana alguien quiere usar otras como es mi caso (las SMDBGrid) estas librerías deben seguir funcionando sin tener que tocar nada en el código.

2) Teniendo en algun almacenamiento, que puede ser base de datos, XML, INI, etc como puedo hacer de forma genérica para pasar los datos de configuración de cada columna de la grilla a la clase. Con esos datos se recorre la grilla y se configura cada una de las columnas (configurar por ejemplo, alineación, ancho, si es visible, si totaliza, etc).

Espero que se entienda lo que quiero hacer. Cualquier cosa me dicen y aclaro un poco mas.

Saludos,
El Rayo

[Casimiro Notevi]

Para lo segundo, el dbgrid de las RX tiene un método para guardar todas las configuraciones y luego cargarlos.
Imagino que las SM también lo tendrá, porque creo, solamente creo, que provienen también de las RX.

[elrayo76]

Me parece que no se entendió lo que pretendo con el segundo punto.

Lo que quiero es ver que forma es la mejor para pasar los datos que tengo en un almacenamiento (de cualquier tipo sea) a la clase. Sería algo como hacer esto:

1) Fuera de la clase leo los datos que estan en un almacenamiento.
2) Esos datos son pasados a la clase para que luego se recorran y se configure toda la grilla.

Lo que no quiero es tener almacenados en memoria dos veces los datos leidos del almacenamiento, uno fuera de la clase y el otro dentro de la clase. Además la clase como la quiero genérica no debe importarle de donde provienen los datos que se utilizan en la misma.

Saludos,
El Rayo

[[movorack]]

¿Estas revolviendo peras con manzanas? ¿Datos y configuración del DBGrid?

- Datos : Generico TDataSet
- Configuración del DBGrid: Cada componente puede tener variaciones así que la que te espera es grande para soportar todo. Pero hay cosas genéricas

La cuestión de mezclar las dos cosas en tu TWonderMagicClassDatasetGridClass es de ingenio pero cada Dataset podría ser tan diferente que de verdad creo que estás tratando de enrollarte tu mismo en un lío que no necesitas.

[OFFTOPIC]
GRILLA!!!!! Por jebús!!!
¿que es eso? La grilla es la esposa del grillo. "grilla" se usa para referirse (mal-referirse) a la conducta de algunas mujeres.
Se dice Grid, DBGrid, o en castellano "Rejilla"
[/OFFTOPIC]

[[AgustinOrtu]]

Para el tema de los datos, ir recorriendo el dataset y luego ir imprimiendo cada campo casteandolo con AsString deberia servirte
Lo de guardar/leer informacion, deberias implementar los metodos SaveToFile y LoadFromFile.
Usando la RTL se pueden ir recorriendo las propiedades de los objetos que te interesen (en tu caso la lista de TColumn) y guardarlas en un archivo (seria como los .dfm que genera el propio delphi)

Hay un articulo bastante interesante que me ayudo a hacer algo similar:
http://delphi.about.com/od/windowssh...der-writer.htm

[elrayo76]

No es que sea indispensable soportar todo, solo fue una consulta por si se podía hacer de alguna forma genérica. Iigulamente voy a hacerlo para los componentes que utilizo yo y luego veré en caso de necesitar otros.

El tema de tener guardada la configuración de las columnas es que si alguien quiere otra alineación para alguna de las columnas u ordenar por alguna que no esta definida, se podrá hacer sin necesidad de tocar el ejecutable. Además para cada cliente se le podrá indicar que columnas son visibles y que otras no lo son.

Es por eso que se guardan los datos de antemano en algun almacenamiento. Si esto se hiciera como indican con un método de la grilla la configuración habría que hacerla antes por código, cosa que es lo que se quiere evitar.

Saludos,
El Rayo

[[fjcg02]]

Hola,
respecto a guardar la configuración de los dbgrid, es una mezcla entre configuración de los campos en el dataset y en el dbgrid.

Por ejemplo, valores máximos y mínimos de un campo, si no puede ser nulo, etc se implementa en el dataset. Sin embargo, la lista de valores que se pueden elegir en un campo ( picklist), se implementa en el dbgrid, lo mismo que si quieres pintar un campo de un color u otro en base a un valor o rango de valores.

En su día hice algo parecido, pero es bastante costoso, y no llegué a implementarlo del todo.

Para ello hice un "diccionario" de datos, donde definía los campos, y todo aquello que podía para no tener que hacerlo en la carga de cada formulario.

Si estás interesado, lo busco por ahí para ver si puedes aprovecharlo.

Por otro lado, si no recuerdo mal, las quantum grid te permiten guardar la configuración en un stream y luego recuperarla.

Un saludo

[Casimiro Notevi]

Empezado por fjcg02

Por otro lado, si no recuerdo mal, las quantum grid te permiten guardar la configuración en un stream y luego recuperarla.

Y las RX con su RXDBgrid

[[fjcg02]]

Empezado por Casimiro Notevi

Y las RX con su RXDBgrid

No las conozco, pero ya lo habías comentado en el segundo mensaje.

Saludos

[Casimiro Notevi]

El alzheimer

[elrayo76]

Primero que nada me gustaría si puedo ver algo de lo que dice fjcg02 que tiene a ver si me ayuda.

Igualmente lo que pretendo hacer es mas simple de lo que dices que tienes. Solo quiero configurar la grid para mostrar datos no tengo intensión de que se pueda editar sobre esta.

Solo es decirle a la grid si los datos de las columnas van alineados a la derecha, izquierda, centrados. Si esa columna tiene totales y hacer que se muestre y funcione. Si se puede ordenar por la columna a la cual se le indica. Que columna es visible cuando se muestra la pantalla y cuales pueden ser seleccionadas para mostrar posteriormente.

Simplemente cosas asi son las que quiero hacer. Por eso es que lo quiero hacer guardando los datos de lo campos a mostrar en la grid en un almacenamiento. Este almacenamiento no puede salir de lo que tiene la grid porque al iniciar la pantalla no habría configuración alguna a mi entender.

Yo solamente quiero el DataSet para pasar a la clase los datos de configuración de la grid, no para configurar cosas en el mismo. Por eso es que esos datos del DataSet son recorridos y usados para las propiedades de la grid.

En un momento lo que pregunte fue alguna forma de pasar estos datos sin importar donde los tenga almacenados, ya que esta clase puede que se use en varias aplicaciones y el almacenamiento sea distinto (XML, INI, base de datos).

Espero que no empiecen a elucurar cosas que no digo y que tampoco pretendo hacer.

Saludos,
El Rayo

[mamcx]

Lo que estas persiguiendo es el elusivo sueño de la multi-plataforma universal, completa, funcional, eficiente y bonita.

Spoiler?

Eso NO EXISTE.

Es la fantasia mas grande, costosa y quita-tiempo-dinero-recursos de la computación.

Aun cuando pienses que es mucho mas simple ("son solo grillas, todo en windows") es el mismo problema, pero a una escala menor. Puedes resistirte a la idea que te presento, argumentando que debería ser muy facil... pero es algo que décadas de experiencia en computación han probado ser cierto.


---

El problema de que esta ilusión y fantasia sea tan creíble es que puede ser aparentemente facil de lograr. Es como un linea que va de facil a imposible, y dependiendo, puede que sea facil o imposible.

Como se llega a una posible solución?

Se crea una sub-mini-plataforma (o: especificación o: runtime o similar) y se reconstruye sobre ella todo desde cero, apuntando a N-clientes/plataformas/targets/etc. Entiende en adelante con "plataforma" cualquier cosa que trata de unificar multiples cosas en un concepto, estilo, diseño unificado.

Esto es otra forma de decir que la multiplataforma persigue el principio de la mediocridad y genera una nueva plataforma que es una version inferior y/o diferente de cualquiera sobre la que se construya:

http://xkcd.com/927/

Lo que quiero decir y es importante entender es que "multiplataforma" no es " app en N plataformas" sino "app en una sub-mini-plataforma que emula a N-plataformas" por eso siempre hay una(s) plataformas que sufren mas que otras (ej: Java corre mejor en Unix que Windows, HTML en Firefox (o Safari, o Chrome, eso cambia todo el tiempo) que en IE, OpenGL en *nix, etc)

Mientras mas cerca a la maquina, mas posible. Mientras mas cerca al usuario, menos posible.

Si lees sobre MVC (modelo-vista-controlador) veras que la parte de modelo es muy viable hacerla generica, el controlador casi pero la vista *no*.

-----

Lo que quieres hacer se hace así:

Creas una especificación de lo que es una grilla a nivel generico. Lo que dices: Columna1 = Texto Just. Izq, Tipo= Numerico, Etc. (el modelo). Es irrelevante si lo metes en JSON, archivos .ini o lo que sea. Eso no es el problema.

Luego creas un adaptador (el controlador) que conecta a cada tipo especifico de grilla (la vista) y traduce de GrillaX a tu modelo y viceversa.

Osea:

MiEspecificacion.Alineacion = Izquierda | Centro | Derecha | Justificado

Dentro de MiTraductorDeEspecificacion

SubClase: ParaGrillaX

--GrillaX.Column1.TextAlign = ConvertirAGrillaX (MiEspecificacion.Alineacion)

ParaGrillaY

--GrillaY['col1'].Format.Text.Align = ConvertirAGrillaY (MiEspecificacion.Alineacion)

Lo simple sera relativamente simple, y lo demás quien sabe. El problema es que eventualmente te encontraras conque GrillaX hace trivial hacer tal cosa pero GrillaY no.

-----

Consejo? No hagas esto, o no hagas algo mas complejo de usar la funcionalidad que ya tiene la grilla de manejarse a si misma.

En vez de seguir la TEORICA VENTAJA (e ilusoria, falsa, quita tiempo, etc) de la solucion generica, usa la MEJOR opcion que tengas en la plataforma que tengas que resuelva de la mejor forma posible la tarea que tengas que resolver. Reducir las capacidades de tu solucion al nivel de la mediocridad no vale el esfuerzo.

P.D: Es MUY deseable crear soluciones genericas y todo eso. Siempre y cuando sepas y entiendas que a nivel de modelo/controlador es donde es factible y correcto eso esta bien. Pero tarde o temprano hay que saltar de lo generico a lo concreto y en el momento que se llega a lo concreto lo generico, por pura logica, deja de existir.

Ademas, y esto es algo difícil de entender, la OO + Estado es ENEMIGA de la generalización. Solo las funciones puras permite generalizar de forma global.

Osea: En el momento que entras a configurar sub-clases, se pierde la habilidad de aplicar soluciones genericas. Osea: Mientras mas cerca estas de resolver la tarea, menos generico puedes ser. Osea: Lo concreto es enemigo de lo generico. Osea: Si haces la forma como le sirve al usuario, has llegado al fin.

Las interfaces de usuario es algo concreto. Es por eso que se resisten a cualquier intento de hacerla supergenericas. Es por eso que es perdida de tiempo multi-plataformalizarlas.

[ecfisa]

Hola.

Sobre la generalización no tengo mas para agregar, mamcx lo expuso muy cláramente.

En referencia al tema del guardado y recuperación del formato, es muy sencillo de implementar en un TDBGrid:

Código Delphi [-]
unit DBGridExt;

interface

uses SysUtils, Classes, DBGrids;

type
  TDBGrid = class(DBGrids.TDBGrid)
  public
    procedure SaveToFile(const aFileName: TFileName);
    procedure LoadFromFile(const aFileName: TFileName);
  end;

implementation

procedure TDBGrid.LoadFromFile(const aFileName: TFileName);
begin
  if not FileExists(aFileName) then
    raise Exception.Create('No se encuentra el archivo');
  with TFileStream.Create(aFileName, fmOpenRead) do
  try
    ReadComponent(Self);
  finally
    Free;
  end;
end;

procedure TDBGrid.SaveToFile(const aFileName: TFileName);
begin
  with TFileStream.Create(aFileName, fmCreate) do
  try
    WriteComponent(Self);
  finally
    Free;
  end;
end;
end.

Luego basta con agregar DBGridExt al final de la cláusula uses de la sección interface de la unidad donde reside el DBGrid y ya estan disponibles estos nuevos métodos.

Saludos

[elrayo76]

Lo que pone ecfisa no lo conosco pero no es lo que necesito.

Lo que quiero es poder pasar de una base de datos todo lo que tengo guardado para configurar como se deben mostrar los datos en la grid (todo esto ya fue explicado en otro post).

Lo que quiero hacer es levantar desde la clase los datos que se le pasan mediente alguna propiedad, pero sin que la clase sepa ni haga uso de la base de datos. Tampoco quiero tener que levantar todos los datos en un ClienteDataSet, DataSet o similar fuera de la clase y luego pasarlos a la misma ya que estaría duplicando los datos en memoria y no tiene ningun sentido hacer esto.

Si nadie puede dar una respuesta a lo que pido, igualmente gracias por intentar ayudarme.

Saludos,
El Rayo

[[AgustinOrtu]]

Te lo explicó ecfisa perfectamente.

La idea es generar un archivo, reitero, similar a los .dfm donde estableces el formato de cada campo

En un grid campo es sinónimo de columna, lo que se traduce en TColumn

El objetivo es mandarle a tu grid una estructura, por ejemplo una lista, un array, el que más te guste, con el contenido del archivo. Recorres esa estructura, preguntando si el campo es igual al campo que referencia cada columna de tu grid, si es igual entonces asignas las propiedades.

Como leer el archivo debería ser responsabilidad de otro método por ejemplo el citado LoadFromFile, el cual se implementa fácilmente con la RTL. También podes hacerlo a mano usando un .ini, un .xml, un .txt, o un archivo binario.

Lo importante es que ese método provea de la información necesaria a otro método que se encarga de decirle a cada columna el formato que tiene que adoptar, asi como tamaño, fuente, ancho, si esta visible o no, título de cabecera, etc

[Casimiro Notevi]

Empezado por elrayo76

Si nadie puede dar una respuesta a lo que pido, igualmente gracias por intentar ayudarme.

Pero si ya te han respondido con distintas alternativas

[mamcx]

Empezado por elrayo76

Lo que quiero es poder pasar de una base de datos todo lo que tengo guardado para configurar como se deben mostrar los datos en la grid (todo esto ya fue explicado en otro post).

Entonces???? Guarda eso en la BD y se lo pasas a la clase

Empezado por elrayo76

Lo que quiero hacer es levantar desde la clase los datos que se le pasan mediente alguna propiedad, pero sin que la clase sepa ni haga uso de la base de datos. Tampoco quiero tener que levantar todos los datos en un ClienteDataSet, DataSet o similar fuera de la clase y luego pasarlos a la misma ya que estaría duplicando los datos en memoria y no tiene ningun sentido hacer esto.

????????

Y si no usas nada para pasar la info de un lado a otro... como pretendes que suceda??

[Neftali [Germán.Estévez]]

Empezado por elrayo76

Estoy diseñando unas clases bastante genéricas para configurar las grillas y me gustaria saber determinadas cosas como las puedo realizar.

1) Quisiera que me dijeran como se puede hacer para apuntar a una grilla desde la clase sin que sea solamente para un determinado componente. Digamos si hoy alguien usa las DBGrid de Delphi que funcione, pero si mañana alguien quiere usar otras como es mi caso (las SMDBGrid) estas librerías deben seguir funcionando sin tener que tocar nada en el código.

2) Teniendo en algun almacenamiento, que puede ser base de datos, XML, INI, etc como puedo hacer de forma genérica para pasar los datos de configuración de cada columna de la grilla a la clase. Con esos datos se recorre la grilla y se configura cada una de las columnas (configurar por ejemplo, alineación, ancho, si es visible, si totaliza, etc).

No se si te he entendido bien, porque lo que quieres es confuso, o al menos la explicación.

Yo en este caso lo que haría sería una clase de configuración. Por un lado debería tener una propiedad que apunte al DBGrid, en este caso a un TCustomDbGrid o incluso a un TCustomGrid. Dependerá de las configuraciones que quiereas modificar. Esto te permitirá, utilizando RTTI, que pueda funcionar con cualquier "DBGrid" que derive de los estandard (en otro caso, milagros no se pueden hacer - o son más complicados-). Es decir, si el SMDBGrid que comentas, por ejemplo, deriva del estandard podrá funcionar con este componente, pues la propiedad Columns (Columns: TDBGridColumns) será compatible con la del estandard. Si tienes otro tipo de DBGrid, como por ejemplo el de las DevExpress, que no derivan del estandard y no comparten propiedades, en ese caso es imposible que funcione, a no ser que hagas código especial para él (aquí tendrás que usar RTTI seguro).

La segunda propiedad sería a que tendría la configuración del Grid y tendrás que rellenarla (desde cualquier fuente de datos) con la configuración necesaria. En esta segunda propiedad tendrás que almacenar los datos que quieres modificar del grid. Seguramente deberá tener una estructura basada en una lista (o en una colección) para almacenar las diferentes columnas, y dentro de cada uno de estos elementos, lo necesario para almacenar alineación, formato,... (todo lo que necesites).

Algo así:

Código Delphi [-]
  //: configuración de cada una de las columnas
  TGConfigItem = class(TCollectionItem)
  private
    FWitdh: Integer;
    FAlignment: TAlignment;
  public
    property Alignment:TAlignment read FAlignment write FAlignment;
    property Witdh:Integer read FWitdh write FWitdh;
    property ...
  end;

  //: Lista de columnas a configurar
  TGConfig = class(TCollection)
    ...
  end;

  TGridConfig = class(TObject)
  private
    FGrid: TCustomDBGrid;
  public
    //: Configuración del grid
    property GConfig:TGConfig read FGConfig write FGConfig;
  published
    //: Grid al que apuntar y modificar
    property Grid:TCustomDBGrid read FGrid write FGrid;
  end;

A ver si van por ahí los tiros...

[[fjcg02]]

Esto es la leche, aver si entre todos entendemos lo que necesita.

Bajo mi punto de vista, lo que necesita es lo siguiente:
definición de campos, Diccionario:
dni -> blabla, nº de caracteres, mascara de entrada, centrado, ...
importe -> numerico, mascara de entrada, maximo y minimo, rojo si negativo, ...
dirección -> nº de caracteres, ..
altura -> mascara de entrada, si altura > 1m azul, si menos que un metro rojo, maximo y minimo.

Luego, mi programita necesita poner la info en un grid.

Le digo de alguna forma qué definición tiene cada campo, y lo configuro en tiempo de ejecución como yo lo haya definido.

En definitiva, defino el aspecto una sola vez, y lo utilizo en todos lados.

Ahora bien, casi todos los valores a ajustar, se definen en el dataset.

He estado mirando código que tengo por ahí y la verdad no es mu potable, pero básicamente hace eso.
Simplemente tengo que ver qué datos quiero ajustar, y hacerlo al cargar el dataset.

Es así ?


Saludos