Posicionamiento en Grillas

[jfontane]

Hola a todos, queria saber como es posible posicionarme en una celda (cell) especifica en un dbgrid. En todo caso que se pueda, esta manera seria tambien es valida para el StringGrid?.



Saludos !!!

[roman]

En el caso del StringGrid puedes utilizar las propiedades Row y Col para colocarte en la celda que desees.

Para el DBGrid estas propiedades no están publicadas aunque si existen. Verás, tanto el DBGrid como el StringGrid descienden de TCustomGrid que define estas propiedades como protegidas y sólo StringGrid las publica.

Esto es así porque con un DBGrid la idea es moverse usando los métodos apropiados del DataSet (Table o Query) asociado.

Aún así puede hacerse con este pequeño truco:

Declaras una clase que descienda de TCustomGrid:

type
  TUPGrid = class(TCustomGrid);

Y haces el "casting":

TUPGrid(DBGrid1).Row := 5;
TUPGrid(DBGrid1).Col := 3;

// Saludos

[andres1569]

Hola:

El código que te ofrece Roman (componente TUPGrid) es apropiado SIEMPRE Y CUANDO lo implementes tú personalmente. No te fíes de un componente de terceros, no sea cosa que lo haya implementado Mr. B. Orlando (ya sabes, el lobo feroz ...).

Para los que esto os suene a chino:

http://www.clubdelphi.com/foros/show...=&threadid=706

Saludos

[roman]

¡¡Lo sabía!!



Ya presentía yo que esto iba a venir a colación. Pero que conste que el código que ofrezco es el correcto eh?

// Saludos

[andres1569]

Hola:

Voy a alargar un poco el tema de los "castings" (¡a ver si alguna estrella del espectáculo se mete a debatir aquí!),

Roman escribió:

type
  TUPGrid = class(TCustomGrid);

Este truco demuestra que estamos jugando con el compilador, porque ¿dónde están definidas en este código las propiedades Row y Col como public? Nos estamos valiendo sencillamente de la particular forma que tiene Delphi de definir el ámbito de las variables protegidas y privadas.

Si la sentencia de arriba la declaramos en una unit aparte, el cast sólo será válido dentro de esa unit, no en otras que quieran hacer uso de dicho truco, por mucho que la incluyamos en el Uses de esas otras.

La solución ideal (con permiso de Mr. B. Orlando) sería esta:

type
  TUPGrid = class(TCustomGrid)
  public
    property Col;
    property Row;
  end;

Ahora sí que el truco nos sirve para todo el proyecto.

¿No os ha llamado nunca la atención que Delphi permita acceder a variables privadas y protegidas de otros objetos siempre y cuando estén definidas en la misma unit, sin que sean necesariamente descendientes unos de otros? En un principio me pareció una flagrante violación de la regla de la encapsulación, aunque ahora doy fe de que esto es de una gran ayuda cuando se están declarando clases "hermanas", que necesitan acceder a las intimidades de otras (esto se ve claramente en las clases TDataset y TDataSource) sin que por ello se tenga que correr el riesgo de declarar ciertas propiedades o métodos como public.

Bueno, si alguien quiere aportar su opinión

[roman]

Bueno pues, ya si nos vamos a estos extremos, la forma verdaderamente correcta es:

unit UPGrid;

interface

uses
  Classes, DBGrids;

type
  TUPGrid = class(TDBGrid)
  public
    property Col;
    property Row;
  end;

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('BDE', [TUPGrid]);
end;

end.

Y ya con la nueva componente en la paleta utilizar ésta en lugar de la original DBGrid.

El hecho de que en una misma unidad puedan accederse a las propiedades privadas y protegidas de otra clase (lo que habilita el truco) se debe a la forma en que Delphi implementa las clases amigas que tienen otros lenguajes como C++.

En el truco original le estamos diciendo al compilador que TUPGrid es una clase amiga de TCustomGrid y después le hacemos creer que DBGrid es de dicha clase amiga.

Pero este truco es completamente válido como lo demuestra el hecho de que podamos derivar un componente e instalarlo en la paleta.

Aquí la disyunción sería la siguiente:

Si vamos a utilizar estas propiedades protegidas (Row y Col) una sóla vez entonces lo más adecuado es el truco; pero si vamos a estar utilizándolas regularmente lo mejor es derivar la componente e instalarla.

// Saludos

[andres1569]

Hola:

Roman ecribió:

Si vamos a utilizar estas propiedades protegidas (Row y Col) una sóla vez entonces lo más adecuado es el truco; pero si vamos a estar utilizándolas regularmente lo mejor es derivar la componente e instalarla.

Esto sí es llegar a un extremo. No pongo en duda la validez de tu truco, pero ¿qué ocurre si tenemos en un proyecto 20 forms con sus respectivos DBGrids, con todas sus propiedades Columns asignadas y deseamos acceder a su propiedad Col o Row? No creo que sea conveniente tener que colocar otro componente en la paleta sólo para cubrir esa necesidad, a parte del trabajo extra que supondría en este caso concreto volver a insertar los TUPDBGrid (por cierto no estaría mal que Delphi permitiera promover Controles a otros de su misma jerarquía, parecido a como hace MS Access para cambiar un control Edit a un Combo, copiando las propiedadees comunes).

El detalle en que quise incidir en mi mensaje anterior es en la particularidad de poder saltarnos a la torera la encapsulación para acceder a variables privadas cuando nos encontramos en la misma unit donde se declara la clase. Como dije, en un principio me sorprendió, incluso lo veía ilícito desde el punto de vista de la OOP, sigo creyendo que se salta las reglas, aunque luego he ido viendo sus ventajas. Me refiero a clases que no tienen un ancestro común (salvo TObject o TComponent claro está) y que sin embargo necesitan establecer una comunicación que sólo se les permite por el hecho de estar definidas en la misma unit. Quizás por ello haya units hinchaditas de tamaño, porque no hay forma de separar la implementación de ciertas clases.


Un saludo

[jfontane]

Hola de nuevo a todos.
Yo a lo que me referia con el posicionamiento es a lo siguiente:
La persona a la que le hago el sistema usa mucho el ENTER (muy a lo DOS) entonces me pide que dentro de un StringGrid que estoy usando para representar una Factura con respecto a la entrada de datos, el usuario pueda poner cantidad y, apretando Enter, pasar (mandar el foco por llamarlo de alguna manera) a una celda especifica del mismo Stringrid.
Lo que yo ya sabia era de Col y Row que ya lo estaba usando.
Ahora si es posible el tema del foco dentro de un stringrid tendria que ver si se podria sobre un DBgrid asociado a un dataset especifico ya que seguro lo voy a tener que hacer con esto tambien.
Muchas Gracias