Newsgroup: it.comp.lang.delphi
Titolo: Riferimento a DBGrid

Ho un MainForm con un DBGrid. Richiamo un secondo form che deve fare 
riferimento al DBGrid del primo form. Come faccio conoscere il DBGrid al 
secondo form ? 
 

 secondo form ?
 
Il secondo form non deve conoscere il dbgrid. Un dbgrid si interfaccia 
ad un datasource, che a sua volta usa un dataset. Il secondo form deve 
solo conoscere il dataset, tramite un datasource.
 
Spiega nel dettaglio quel che ti serve fare (non come tu lo vorresti 
fare). Forse ti si puo` dare un aiuto migliore.
 
-- 
4ndre4

 secondo form ?
 
Quello che ti ha suggerito Andrea e' il modo corretto di operare.
Comunque il modo "sporco" e poco raccomandabile e' spostare il riferimenti 
del tuo dbgrid (dbgrid1) nella sezione PUBLIC del form e mettere nella tua 
unit2 nelle uses la unit1.
Poi, se la form si chiama Form1 e la griglia DBGrid1, nella seconda form 
puoi chiamare la griglia con Form1.DBGrid1.
Ma dato che Andrea ti ha spiegato come lavora la dbgrid, iofarei cosi':
Definisco una unit dove inserico i datasource e i dataset (per esempio 
Datasource1 e, come dataset, TabellaProva).
Nella unit1 metto il dbgrid1 che e' linkato a datasource1 che a sua volta e' 
linkato a TabellaProva.
Nella unit1 fai quello che devi fare, poi apri il fom2 (in unit2) che a sua 
volta contiene una seconda dbgrid.
In questa seconda unit metti nelle uses la unit dove ci sono i dataset e 
datasource, metti una seconda griglia che usa lo stesso dataset e della 
dbgrid1.
In questo caso stai lavorando nella unit2, sulla dbgrid2 ma tutti i 
riferimenti e le modifiche sono apportate alla tabella originale.
 
Sembra complicato ... ma in realta' e' molto semplice.
 
Scusa se ti ho confuso le idee ...
 
Ciao
 
Daniele 
 

 unit2 nelle uses la unit1.
 
Il metodo è MOLTO sporco, e ASSOLUTAMENTE non raccomandabile...
 
La dbgrid, se creata a design-time si trova nella sezione published! Quindi, 
per il "tuo modo sporco", è già visibile dalle altre Form.
 
Se la sposti nella sezione Public la nascondi all'RTTI ed a run-time ti ritrovi 
una bella EClassNotFound exception durante la creazione della Form.
 
HTH,
David
 
 

Spiega nel dettaglio quel che ti serve fare (non come tu lo vorresti
fare). Forse ti si puo` dare un aiuto migliore.
-- 
4ndre4
 
Quello che intendo fare è un piccolo form con un CheckList che mostra le 
colonne di un DBGrid in modo che l'utente posa personalizzare i campi 
visualizzati. Pertanto il form prevede alcune proc per fare il load e il 
save degli oggetti colonna del DBGrid, nonchè il riempimento della CheckList 
con la spunta sulle colonne che risultano visibili.
Per poterlo generalizzare e usare in tutta l'applicazione e in tutti i 
DBGrid, vi faccio un esempio di come ho impostato le procedure:
 
procedure LoadDBGridColumns(aDBGr: TDBGrid; aColumnsFile: string);
begin
  if Fileexists(aColumnsFile) then
    aDBGr.Columns.LoadFromFile(aColumnsFile);
end;
 
procedure SaveDBGridColumns(aDBGr: TDBGrid; aColumnsFile: string);
{ Salva le COLUMNS del DBGrid con tutti i loro attributi }
begin
  aDBGr.Columns.SaveToFile(aColumnsFile);
end; 
 

In attesa dei vostri commenti, ho provato a fare cosě:
 
private
  { Private declarations }
  FGrid: TDBGrid;  // passato dal chiamante
public
  { Public declarations }
  property Grid: TDBGrid read FGrid write FGrid;
 

 in modo che l'utente posa personalizzare i campi visualizzati.
 > Pertanto il form prevede alcune proc per fare il load e il save degli 
oggetti colonna del DBGrid,
 > nonchè il riempimento della CheckList con la spunta sulle colonne che 
risultano visibili.
 
Quel che a te serve e` un form che accetti un TStrings (i nomi delle 
colonne), e che esponga il TStrings modificato dall'utente. NON ti serve 
far vedere il DbGrid.
 
-- 
4ndre4

Quel che a te serve e` un form che accetti un TStrings (i nomi delle
colonne), e che esponga il TStrings modificato dall'utente. NON ti serve
far vedere il DbGrid.
4ndre4
--
Hai ragione, in effetti avevo cominciato così, tanto che salvavo in un ini 
file le colonne scelte (con i nomi dei titles). Ma poi mi sono lasciato 
tentare dalla possibilità di salvare , non le stringhe, ma le colonne con 
tutti gli attributi. Con la semplice espressione:
DBGrid1.Columns.SaveToFile(aColumnsFile);
praticamente memorizzo il title, l'alignement, la width, etc., per cui i 
cambiamenti che l'utente opera sul DBGrid li salvo (e li ripristino) con 
un'ìistruzione. Ecco perchè ho preferito questa soluzione. Forse avrei 
potuto escogitare un sistema per associare la TStrings alle columns... ma 
non mi viene in mente una roba semplice. 
 

 colonne con tutti gli attributi. Con la semplice espressione:
 
Bene, ma anche in quel caso, non ti serve esporre l'intera DbGrid. 
Anziche` un TStrings, userai un TDBGridColumns. Il succo non cambia.
 
-- 
4ndre4

 Il metodo è MOLTO sporco, e ASSOLUTAMENTE non raccomandabile...
Verissimo.
Ho solo cercato di dare una risposta ad un problema che, onestamente, non 
credo esista.
Essendo una dbgrid, come aveva gia' anticipato Andra, si puo' fare tutto in 
una seconda form andando a condividere datasource e  dataset (che in questo 
caso sono gia' belli che pronti lasciati nella condizione di lavoro del form 
chiamante).
Credo che molto dipenda da cosa Stark deve fare nella seconda form.
 
Ciao e grazie.
 
Daniele
 

Credo che molto dipenda da cosa Stark deve fare nella seconda form.
 
Sopra ho spiegato cosa devo fare. Penso di aver risolto il problema 
definendo in form2 una property di tipo TDBGrid che il main form passa.
Comunque grazie a tutti dei suggerimenti. Credo che il valore della 
discussione vada molto oltre la soluzione dello specifico problema o della 
adozione dell'uno o dell'altro. Almeno per me costituisce un incredibile 
arricchimento che influisce molto sull'approccio allo sviluppo. Grazie 
 

 definendo in form2 una property di tipo TDBGrid che il main form passa.
 
La cosa bella e` che chiedi suggerimenti ma poi fai di testa tua (sbagliando).

Ciao Stark,
      quello che ti serve e' un gestore di properties che legge/salva le 
proprieta' delle colonne.
Cosi' puoi gestire la visibilita', larghezza, altezza, font ecc...
 
Ho trovato questo link, non so se puo' servirti ...
 
http://www.delphipages.com/forum/showthread.php?t=190260
 
 
Ciao e buon lavoro
 
Daniele 
 

 non credo esista.
 
Hai dato una soluzione ad un problema che, oltre ad essere sporca e non raccomandabile, 
NON FUNZIONA!
 
Secondo me, facendo cosě, si confondono solo le idee a chi chiede aiuto.
 
David 
 
 


Perchč anche il write? se viene passato dal chiamante nel costructor ti 
serve solo il read sulla property, altrimenti chiunque veda l'istanza 
del form potrebbe sovrascrivere la FGrid a piacimento.
 
-- 
Morde

La cosa bella e` che chiedi suggerimenti ma poi fai di testa tua 
(sbagliando).
 
Mi spiace che pensiate che me ne frego dei suggerimenti. E' che mentre mi 
arrivavano, io intanto avevo provato una soluzione che stava funzionando. 
Mentre non trovavo come fare le stesse cose altrimenti.
Per esempio, il suggerimento di passare una TStrings con i nomi dei campi 
l'ho sperimentata, ma con questa soluzione non riuscivo a fare quello che 
facevo avendo a disposizione il DBGrid. Ad esempio, mettendo checked o 
unchecked un item della checklist, rendere visibile o nascondere 
contestualmente la corrispondente colonna del DBGrid nell'altro form.
 
(Mentre avrei potuto risolvere il problema del salvataggio delle colonne e 
il loro ripristino mettendo queste proc nel mainform, ma mi dovevo inventare 
un congegno per individuare, dal nome sulla checklist, la corrispondente 
colonna sulla DBGrid).
 
 

Ho trovato questo link, non so se puo' servirti ...
http://www.delphipages.com/forum/showthread.php?t=190260
 
Ciao e buon lavoro
Daniele 
--
Mi sembra quello di cui stiamo parlando.. adesso ci guardo, grazie

 l'istanza del form potrebbe sovrascrivere la FGrid a piacimento.
 
MiaForm.Grid := nil;
 
:-)
 
 

 io intanto avevo provato una soluzione che stava funzionando.
 
La tua soluzione, formalmente, NON funziona, perche` e` una soluzione 
del cazzo. Cerco di essere chiaro e parlare fuori dai denti perche` a 
volte mi sembra che tu abbia grosse difficolta` a capire. NON DEVI 
esporre la TDBGrid tra form diverse perche` significa scrivere MERDA. Ci 
tieni almeno un po' a seguire un minimo di design corretto?
Almeno, se proprio vuoi seguire la tua strada, risparmiaci le tue 
soluzioni raffazzonate.
 
-- 
4ndre4

La soluzione che hai adottato è SBAGLIATA, punto.
Che poi funzioni o no, conta poco, perchè E' SBAGLIATA.
Ti consiglio:
Cresci
Studia
Sbattiti
Trova qualcosa di meglio partendo dagli spunti che ti sono stati dati.
 
 
A.
 
 
 
 
 
A.
 
 
 
 
 

 Secondo me, facendo cosě, si confondono solo le idee a chi chiede aiuto.
 
Hai ragione, tieni presente che la risposta era stata data sulla domanda 
"Come faccio conoscere il DBGrid al
secondo form ?"
Ha detto DOPO quello che in realta' voleva fare.
L'ho interpretata come "si puo' passare con il semaforo rosso?"
Ovvio che risposta e' no ..... ma comunque c'e' chi passa e (in teoria) si 
fa sua la responsabiltia' e conseguenze di cio' che potrebbe accadere.
 
Per essere chiari, condivido tutto quello che hai scritto.
 
Ciao e buona giornata
 
Daniele
 

NON DEVI 
esporre la TDBGrid tra form diverse perche` significa scrivere MERDA. Ci 
tieni almeno un po' a seguire un minimo di design corretto?
Almeno, se proprio vuoi seguire la tua strada, risparmiaci le tue 
soluzioni raffazzonate.
4ndre4
 
Ci sto provando ... 

 Che poi funzioni o no, conta poco, perchè E' SBAGLIATA.
 
A me pare che si stia esagerando.
Sappiamo tutti che non esiste l'unica soluzione. A seconda della 
capacità propria, uno disegnerà un'architettura OO più o meno coesa.
Anche un pessimo disegno può funzionare lo stesso.
Anche eliminando attributi privati e rendendo tutto accessibile si può 
scrivere programmi che funzionano.
 
-- 
Morde

 Anche un pessimo disegno può funzionare lo stesso.
 
Sappiamo tutti che non esiste un'unica soluzione, ma tra una soluzione 
errata ed una corretta, esiste un'unica soluzione. Qui non si tratta di 
"architetture OO piu` o meno coese", si tratta di aver fatto una pura e 
semplice cazzata.
 
-- 
4ndre4

 scrivere programmi che funzionano.
 
Ma il codice non deve "solo" FUNZIONARE ma deve essere anche MANUNTENIBILE.
Se "semini" cose di questo tipo alla prima difficoltà, ti troverai alla fine con un codice solo di poco meno peggio di quello farcito di "goto" del gwbasic.
E quando (nontare: non SE ma QUANDO!) dovrai metterci le mani, saranno uccelli per i diabetici (kazzi amari).
 
Come dicevo in un altro post, una soluzione del genere potrebbe andar bene in casi estremi.
E, aggiungo, a fronte di un problema OGGETTIVAMENTE COMPLESSO.
 
A.