FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Posicionamiento en Grillas
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 !!! |
#2
|
||||
|
||||
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: Código:
type TUPGrid = class(TCustomGrid); Código:
TUPGrid(DBGrid1).Row := 5; TUPGrid(DBGrid1).Col := 3; |
#3
|
|||
|
|||
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 |
#4
|
||||
|
||||
¡¡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 |
#5
|
|||
|
|||
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ó: Código:
type TUPGrid = class(TCustomGrid); 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: Código:
type TUPGrid = class(TCustomGrid) public property Col; property Row; end; ¿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 |
#6
|
||||
|
||||
Bueno pues, ya si nos vamos a estos extremos, la forma verdaderamente correcta es:
Código:
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. 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 |
#7
|
|||
|
|||
Hola:
Roman ecribió: Cita:
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 |
#8
|
|||
|
|||
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 |
|
|
|