Consejos para configuración de las Rejillas

[[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 Noteví]

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 Noteví]

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