Newsgroup: it.comp.lang.delphi
Titolo: [D5][TADOQuery][DBGrid] La griglia non visualizza una cippa...

Salve,
Quando dico che detesto i componenti data-aware, forse non ho
proprio tutti i torti, perché ecco qui una idiosincrasia di cui non
capisco la causa.
Scenario: ho una TAdoQuery che uso per filtrare dei dati da un DB.
Il filtering avviene tramite una riapertura della query rispetto a quella
"originale" applicando il filtro appropriato.
Nota bene: la griglia "funziona" a design-time, ma non a run-time.
Ecco il codice del pulsante "Cerca":
procedure TSearchProductsFrm.SearchBtnClick(Sender: TObject);
var T_Query : String;
begin
  T_Query := GetTotalQuery;
  ECommerceDataModule.RequeryProducts( T_Query );
  ECommerceDataModule.LoadProductsExt( FProducts );
end;
GetTotalQuery prende tutto lo statement( filtro incluso ).
Ecco il codice di RequeryProducts:
procedure TECommerceDataModule.RequeryProducts(NewQueryString: String);
begin
  try
    ExtendedProductQuery.Active := False;
    ExtendedProductQuery.SQL.Text := NewQueryString;
    ExtendedProductQuery.Active := True;
  except
    on E: EOleException do
    begin
      MessageDlg( 'Si è verificato un errore :
'+E.Message,mtError,[ mbOk ],0 );
    end;
  end;
end;
Come vedete si tratta solo di riaprire la query con il nuovo testo, quindi
nulla di
sconvolgente. Ecco, infine, il codice di LoadProductsExt( tagliato delle
parti non
necessarie ):
procedure TECommerceDataModule.LoadProductsExt(
  out ProductsList: TObjectList);
var OptVal_Idx : Integer;
    Attr_Idx : Integer;
    Prod : TProduct;
    Cat : TCategory;
    SubCat : TSubCategory;
    Producer : TProducer;
    Options : TObjectList;
    Attributes : TObjectList;
begin
  try
    if Not( ExtendedProductQuery.Active ) then
      ExtendedProductQuery.Active := True;
  except
    on E: EOleException do
    begin
      ProductsList := nil;
      exit;
    end;
  end;
  try
    ProductsList := TObjectList.Create( True );
    ExtendedProductQuery.DisableControls;
    while not( ExtendedProductQuery.Eof ) do
    begin
        // Qui riempiamo le varie classi
        ExtendedProductQuery.Next;
    end;
    ExtendedProductQuery.EnableControls;
  except
    on E: EOleException do
    begin
      if Assigned( Prod ) then
      begin
        MessageDlg( 'Si è verificato un errore durante il caricamento del
prodotto: '+
                    Prod.Name,mtError,[ mbOk ],0 );
      end
      else begin
             MessageDlg( 'Si è verificato un problema durante il caricamento
dei '+
                         'prodotti',mtError,[ mbOk ],0 );
           end;
    end;
  end;
end;
Come vedete non c'è nulla di eccezionale in questo codice e - in teoria -
dovrebbe
andare tutto bene... il problema è che la query sembra *inattiva* nella
DBGrid, il che è
impossibile visto che anche quando la disattivo poi viene riattivata subito
dopo.
Non credo sia un problema di eccezioni( magari poteva essere che dopo averla
disattivata non si riattivasse per una eccezione ) ma non credo, altrimenti
Delphi
protesterebbe in turco rimandandomi nell'editor.
Ho anche provato a togliere Disable/EnableControls, ma nessun cambiamento.
Ribadisco che a *design time*( quando cioè tutto il codice di requery non
viene
eseguito ) funziona bene.
Ah, per chi avesse lampi di genio improvvisi, SI, la dbgrid è collegata al
DataSource, il
quale a sua volta è abilitato :-)
Vabbeh che d'estate perdo colpi e che sto più rintronato, ma a tutto c'è un
limite... :-)
Qualche idea?
Andrea

 quale a sua volta è abilitato :-)
a me però per in un programma che ho diviso in dll qualche volta è capitato 
di dover "forzare" il collegamento.
hai provato così, puoi farlo mettendo un bottone e assegnando a runtime il 
datasource.
ciao

 ciao
Ciao
Andrea

 E' una cosa assurda.
Facci vedere come crei la form e il datamodule...
--
Andrea /\/\agni
ICQ#: 174108000

 Facci vedere come crei la form e il datamodule...
procedure TSearchProductsFrm.FormCreate(Sender: TObject);
begin
  FCategoryList := TObjectList.Create( True );
  FProducerList := TObjectList.Create( True );
end;
Non c'è nulla nell'OnCreate del DM
Andrea

The DeerBear wrote:
<snip>
Ci tengo a sottolineare che *ad oggi* non avevo usato un
controllo DA in quella posizione perché avevo preferito una
listview, quindi non ci sono "artifici strani" o cose esoteriche.
Solo quello che avete visto...
Andrea

 Solo quello che avete visto...
Io uso molto i dbaware (anche con form e dm creati runtime) e non ho mai
avuto problemi... sono curioso di capire il perchè di questo
malfunzionamento...
Ciao :-)


 Ciao :-)
Ciao Andrea M :-)
Andrea

 Grazie per il consiglio.
Prego :) guarda ti dirņ che mi sono guardato i miei sorgenti e praticamente 
ho forzato l'assegnazione del Ds ogni volta.
I motivi li ignoro sembra che in qualche caso si dimentichi che gli ai 
assegnato il ds e mette la proprietą a nil.
ciao

 ciao
Ciao
Andrea

> ai assegnato il ds e mette la proprietà a nil.
Questa è un'altra questione ed è legata alla risoluzione "by name" dei
riferimenti in Delphi. (non è una peculiarità dei db-aware...)
Ciao


The DeerBear wrote:
<snip>
Magari non c'entra nulla, ma non si sa mai... le classi all'interno di
LoadProductsExt
vengono riempite con dei campi persistenti.
Facendo un pò presente la struttura dell'applicazione:
Ogni DM ha una serie di query, quindi diciamo che ogni DM ha uno
"scopo"( inserisci, elimina, ecc ).
Nel corso del riempimento delle classi, vengono richiamate query da altri
due DM, ma
sinceramente non vedo come possano cambiare le cose questi fatti.
Resto in ascolto.
Andrea

 Ciao
Ciao
Andrea

The DeerBear wrote:
<snip>
Spostando il collegamento a run-time del dataset nell'OnCreate della
form, funziona tutto benissimo. Prima lo avevo messo nel pulsante "cerca".
Ok, pare che sia un problema a design-time.
Andrea

 all'AdoConnection.
Ok, dunque:
La form1 è l'equivalente della tua mainform, c'è solo un pulsante con questo
OnClick:
procedure TForm1.Button1Click(Sender: TObject);
begin
  with TForm3.Create(Self) do
    try
      ShowModal;
    finally
      Free;
    end;
end;
Questo è il codice del datamodule:
type
  TDataModule2 = class(TDataModule)
    ADOConnection1: TADOConnection;
    ADOQuery1: TADOQuery;
    DataSource1: TDataSource;
  private
    { Private declarations }
  public
    { Public declarations }
    procedure ReQuery(SQL: String);
    procedure LoadData(var s: string);
  end;
var
  DataModule2: TDataModule2;
implementation
uses Unit3;
{$R *.dfm}
procedure TDataModule2.LoadData(var s: string);
begin
  s:= '';
  ADOQuery1.DisableControls;
  try
    ADOQuery1.First;
    while not ADOQuery1.Eof do begin
      s := s+' '+ADOQuery1.FieldByName('ID').AsString;
      AdoQuery1.Next;
    end;
  finally
    ADOQuery1.EnableControls;
  end;
end;
procedure TDataModule2.ReQuery(SQL: String);
begin
  ADOQuery1.Active := False;
  ADOQuery1.SQL.Text := SQL;
  ADOQuery1.Active := True;
end;
La form3 ospita la griglia e un pulsante con questo OnClick:
procedure TForm3.Button1Click(Sender: TObject);
var
  s: string;
begin
  DataModule2.Requery('SELECT * FROM Dati');
  s := '';
  DataModule2.LoadData(s);
  ShowMessage(s);
end;
A design ho:
- settato la stringa di connessione della ADOConnection
- definito la query come "SELECT * FROM Tabella" (NB: Tabella<>Dati)
- associato la griglia (form3) al datasource (datamodule2)
e funziona tutto...
Secondo me ti scappa un DisableControls di troppo da qualche parte... (ma
cosa intendi quando dici "è che la query sembra *inattiva* nella dbgrid" ?
Che è come quando chiami un DisableControls [e quindi vedi i dati ma non li
puoi cambiare /spostare il cursore] o che è come quando la query è chiusa?)


 Ciao
Ciao
Andrea

 che se assegno il datasource a run-time, la griglia mostra i dati!
Boh... sinceramente mi sembra proprio strano...
Anche perchè se ci fosse sul serio un bug del genere, metà dei miei
programmi non funzionerebbero.
Riesci a ricreare un progettino 2 form e 1 dm col problema?
(io ora esco ma se me lo mandi quando torno ci do un'occhiata)
Ciao :-)


Non credo sia un problema di eccezioni[...]
Una nota sul tuo uso delle eccezioni (per il resto non intervengo): a
mio avviso non è corretto.  L'eccezione deve essere gestita in un
_unico_ punto ed in modo chiaro.  Una funzione richiamata all'interno
di un'elaborazione più generale dovrebbe assolvere la sua funzione,
appunto, senza preoccuparsi di avvisare l'utente in alcun modo.  
Se avvisare o meno l'utente con una dialog box oppure loggare il
messaggio di errore su un log file in modo silenzioso è compito del
gestore del processo.  Gli si deve lasciare ampia libertà, da questo
punto di vista.  Le funzioni dovrebbero semplicemente avere un
try/finally per l'eventuale rilascio delle risorse allocate.  Per fare
un esempio, il seguente codice è logicamente errato:
function Funzione(const A, B: Double): Double;
begin
  // alloco le mie risorse
  try
    try
      Result := A/B; 
    except
      on E: Exception do
        ShowMessage('Errore ' + E.Message);
    end;
  finally
    // dealloco le mie risorse
  end;
end;
procedure GestoreProcesso;
begin
  Funzione(3, 0);
end;
E` più corretto scrivere, invece:
function Funzione(const A, B: Double): Double;
begin
  // alloco le mie risorse
  try
    Result := A/B; 
  finally
    // dealloco le mie risorse
  end;
end;
procedure GestoreProcesso;
begin
  try
    Funzione(3, 0);
    // altra funzione del processo
    // altra funzione del processo 
  except
    on E: Exception do
      // gestisco l'eccezione come mi aggrada
  end;
end;
-- 
Andrea Laforgia
Open Delphi Manual
http://groups.yahoo.com/group/delphi_open_manual/

end;
Pericolo di memory leaks lungo il programma.
Aggiungici un try/finally.


 riferimenti in Delphi. (non è una peculiarità dei db-aware...)
Adesso che me lo dici effettivamente non posso che darti ragione.
nb che io non ho niente contro i controlli db-aware quando posso li uso 
molto volentieri a differenza dell'amico Andrea(The DeerBear).
Ciao :-)

> I DM sono autocreate, mi stanno più comodi.
In che senso?
Io preferisco creare le cose solo quando servono, in modo che le mi app non
allochino risorse che poi non vengonop utilizzate.
Inoltre, se hai un solo DM, ok ma se sono di + la partenza della app è +
lenta.
Dulcis in fundo, come qualcuno del ng mi fece notare, se fai la free,
sarebbe + corretto usare:
TQualcosa.Create(NIL)
Bye
A

 A
Andrea

 appunto, senza preoccuparsi di avvisare l'utente in alcun modo.
Ma se la funzione e' in grado di interpretare l'eccezione _e risolverla_
e' meglio la gestione locale (con eventuale rialzo a scopi di log o che
altro). Esempio:
function InserisciOAggiornaValore;
begin
  try
    InsertQuery.Execute;
  except
    on EKeyViolation do begin
      UpdateQuery.Execute;
      raise EIlValoreCEraGia.Create();
    end;
  end;
end;
Saluti
Paolo Arosio

e' meglio la gestione locale
Siamo d'accordo.  Nel caso specifico, mi riferivo alla scelta di far
vedere un messaggio a video.  E` chiaro che se ci sono operazioni da
fare quando si solleva l'eccezione, all'interno della funzione,
bisogna comunque gestirle.  L'essenziale è che l'eccezione non venga
"assorbita" nella funzione, ma venga comunque rimbalzata sul
chiamante, quindi il "raise" è indispensabile.  Diciamo che lo schema
dovrebbe essere:
function YourFunc( ...;
begin
  // allocazione risorse
  try
    try
      ...
    except
      // gestione locale (NO messaggi)
      raise
    end;
  finally
    // rilascio risorse



Open Delphi Manual (
http://groups.yahoo.com/group/delphi_open_manual/
)

 stabile che non sia stato costruito su un cimitero indiano. :-D
ROTFL... ma, dico, ti pare normale una cosa come quella successa a me?
E dire che il codice non è nulla di eccezionale... non oso immaginare su
programmi un pò più complicati( questo è minuscolo, solo una ventina di
units ).
Devi sapere che prima usavo una listview in quel punto, poi sono stato
costretto a
passare alla DBGrid... decisioni "dall'alto".
Finché usavo una listview, mi credi, nemmeno un problema... poche righe di
codice mi permettevano di fare *qualunque* cosa, ora con la DBGrid, per
esempio, l'ordinamento per colonna è un incubo( vorrei far notare che in una
ADOQuery la proprietà RecNo restituisce la *distanza* tra la riga attuale e
l'inizio del recordset, il che significa che se viene cancellata una riga,
si sfalsano i
risultati, con gli evidenti problemi relativi... ).
Poi il problema di oggi del datasource, che dimmi tu da dove diavolo esce
visto che sei così esperto dei data-aware controls! :-)
Tornando all'ordinamento per colonna, vorrei far notare che visualmente è
una
schifezza, perché il click sul titolo serve anche per spostare la colonna,
quindi
viene fuori un bruttissimo rettangolino nero che non so come togliere...
d'altro
canto se blocco la possibilità di spostare le colonne tolgo una cosa che
all'utente
potrebbe tornare utile, quindi devo lasciare il rettangolino nero e
bruttissimo a
vedersi( a meno che qualcuno non ha già affrontato - e risolto - il
problema )!
A presto...
Andrea

 problema )!
Che rettangolino?
Per differenziare le due cose inventati qualcosa tipo "Shift+Click" ordina,
se clicchi soltanto sposti...
Ciao



    Via De Gasperi, 14 - 42019
    Scandiano (Reggio Emilia)

 Ciao!
Ciao
Andrea

 Ciao
Ciao
Andrea




 (terminata l'operazione di Drag&Drop). Qual č il problema?
Il problema č che appare anche se solo faccio click sul titolo per cambiare
ordinamento!
Ecco qual'č il problema!
Andrea

Guarda Andrea, fin qui ci arrivo pure io :-)
E allora se ci arrivi, arrivi anche a capire che l'eventuale "incubo"
di cui parli non dipende dall'uso della DBGrid, ma dal dataset
sottostante.  Ad esempio, col ClientDataSet ottieni il miglior metodo
di ordinamento che si conosca, visto che lavora in memoria ed č
velocissimo, la griglia si occupa, al limite, di scatenare un
OnTitleClick e si ferma lě.


> ordina, se clicchi soltanto sposti...
Sto lavorando a una dbGrid modificata che incorpora il click sulla colonna 
restituisce il campo della colonna cliccata e mette la freccina in su/giů a 
seconda se č discendente o no.
L'idea di differenziare il click con qualcosa d'altro non č male.
X The DeerBear unico problema che mi sa che prima che finisco tu hai finito 
il prg ;)
Ciao
ps: il rettangolino che dici fa schifo anche a me, mi sono stampato tutta 
la unit Dbgrids sto cercando di capire un po di cose .... 

sconsigliare a priori. 
Concordo.
Sono studiati per lavorare con qualsiasi TDataSet e per questo si
rivelano, a volte, molto comodi.  


 tutta la unit Dbgrids sto cercando di capire un po di cose ....
Prova a dare un'occhiata a MouseDown in TCustomDBGrid... :-)
Andrea

 Ecco qual'è il problema!
Ah, ora ho capito finalmente.
Signori, siamo sviluppatori Delphi o no?
Facciamo un bel controllo discendente e modifichiamo il comportamento
standard della DBGrid... ;-)


 standard della DBGrid... ;-)
Ma no, bisogna puntare al riuso... <g>
Andrea

The DeerBear wrote:
<snip>
Nuovo quesito per i cultori dei componenti Data-Aware: come faccio a
determinare se c'è
qualcosa selezionato nella DBGrid? SelectedIndex *non* funziona :-)
Andrea

 SelectedIndex *non* funziona :-)
Non funziona neanche SelectedField... e vorrei far notare che non sto
chiedendo la luna, eh? Solo come ottenere di sapere se c'è qualcosa di
selezionato...
Andrea

The DeerBear wrote:

Leggere l'help di Delphi non ti farebbe male: SelectedRows.


 Leggere l'help di Delphi non ti farebbe male: SelectedRows.
Bello mio, l'ho letto l'help ed ho visto SelectedRows, MA:
"SelectedRows is only meaningful when the Options property includes
dgRowSelect and dgMultiSelect." .
Io, però, *non* *posso* includere dgMultiSelect, poiché mi serve per vedere
i dettagli di un
*singolo* record, quindi dare la possibilità di fare una selezione multipla
non è proprio una
bella cosa.
Andrea

non è proprio una bella cosa.
*Se* *ti* *serve* *il* *singolo* *record* *non* *ha* *senso*
*controllare* *se* *qualcosa* *è* *selezionato*.


bella cosa.
Se è il singolo record quello che ti serve, perchè andarlo a cercare
sulla grid? Basta leggere il record attivo sul dataset.
-- 
"La velocità luce non è sufficiente Comandante Nunziatella, 
dobbiamo passare alla velocità smodata!"

Aggiungo che SelectedField, nel caso si voglia selezionare un singolo
campo, funziona egregiamente.


 sulla grid? Basta leggere il record attivo sul dataset.
Alle volte ho la sensazione che nessuno di voi ha mai utilizzato la
DBGrid...
Vi siete mai accorti che la griglia parte *senza selezione* e che se c'č un
pulsante "Modifica" premuto senza nessuna selezione attiva si rischia il
disastro?
Andrea

disastro?
Stai dicendo un mare di stupidaggini (tanto per cambiare), con l'unico
(vano) fine di screditare l'uso dei componenti db-aware.  La
responsabilità di controlli di questo tipo è nelle mani del
programmatore.  Ogni mio pulsante di modifica, ad esempio, ha qualcosa
del tipo seguente, in testa:
if MioDataSet.IsEmpty then MessageDlg('Nessun record da modificare...
Se mi serve che siano selezionate 2 o più righe, ci metto un controllo
del tipo:
if MioDataSet.SelectedRows.Count < 2 then MessageDlg('Selezionare 2 o
più righe...
etc... etc...


disastro?
Io invece ho la sensazione che tu sia o assolutamente prevenuto  o
assolutamente incompetente.
A te la scelta.
Ti sei mai accorto che basta controllare se *esiste* un record
selezionato *prima* di fare una modifica per non fare *alcun*
disastro?
Utilizzare componenti DB Aware non significa trascinare due icone su
una form e basta.


procedure TForm1.acnEditUpdate(sender: tobject);
begin
   TAction(Sender).Enabled := Not (grid.datasource.dataset.IsEmpty)
end;
oppure:
procedure TForm1.acnEditExecute(sender: tobject);
begin
 if grid.datasource.dataset.IsEmpty then
 begin
ShowMessage('Nessun record selezionato. Selezionare un record e
riprovare.');
  exit;
end;
....
end;
Bye
A

 disastro?
Ecco, appunto!
Ma come faccio a sapere se c'è un record selezionato, visto che non ho
alcun modo per saperlo?
Il fatto di avere un certo numero di records, non significa affatto che uno
sia
selezionato! Quello è il succo della questione!
Il punto è tutto lì.
Dal mio post:
"vorrei far notare che non sto chiedendo la luna, eh? Solo come ottenere di
sapere se c'è
qualcosa di selezionato..."
Quello che cerco di fare è proprio di determinare *se* c'è un record
selezionato,
altrimenti di abortire la procedura, _MA_:
1) SelectedIndex non assume mai un valore < 0 anche se di selezionato non
c'è nulla,
2) SelectedField è sempre assegnato anche se *nulla* è selezionato,
quindi inutilizzabile.
3) SelectedRows va bene solo se aggiungi dgMultiSelect a dgRowSelect, che
per
quello che mi serve è inaccettabile.
Per "selezionato" intendo che abbia il rettangolo intorno.
Quindi, prima di dire che sono prevenuto o incompetente, vedi di *leggere*
quello che
scrivo.
Sono TRE ORE che sto dicendo che non so come determinare se c'è qualcosa di
selezionato, proprio per vedere come evitare di trovarmi nella situazione di
cui sopra!
Per la cronaca: ho anche provato ad impostare *io* SelectedIndex a -1 *dopo*
la
ricerca, in modo da poterlo avere disponibile a -1 se necessario.
Ovviamente, sebbene sia possibile impostarlo a -1, non resiste come
impostazione.
Andrea

selezionato
E sono TRE ORE che ti stiamo facendo vedere come si fa.


prima di tutto, calma.
Non ha molto senso polemizzare.
Vediamo di chiarire le cose, ok?
1) non è vero che non hai modo di sapere se un record è selezionato.
Ogni dataset ha un record corrente, ovvero, attivo, ovvero, selezionato,
altrimenti la property IsEmpty ti da true e tu sai che nel dataset non
esiste alcun record.
Qui stiamo parlando a livello di dataset, per il quale il record attivo,
selezionato etc è sempre e solo UNO.
2) la dbgrid è di fatto un componente a cui spetta solo mostrare il
contenuto del dataset ad essa associato.
Quindi, se tu scrivi una cosa del tipo:
valore := nessunvalore;
if Not then grid.datasource.dataset.IsEmpty
valore :=
grid.datasource.dataset.fioeldbyname('TuaChiavePrimaria').AsQualcosa
if valore = nessunvalore then
  showmessage('nessun record selezxionato
else
  //edit/show etc etc etc
ottieni la chiave primaria del record attivo sul dataset
Questo codice se ne frega di ciò che è attivo/selezionato sulla grid, se la
grid ha il focus etc etc etc etc.
Il succo non è che non puoi sapere, ma cosa usare tra cio' che sai.
Se te ne freghi della selezione multipla di appoggi al dataset sottostante
da cui sai tutto.
Se ti serve la selezione multipla puoi usare quella standard fornita da
dbgrid e accedere a selectedrows.
Non vuoi le restrizioni che ti impone la dbgrid per la gestione della
selezione multpla?
Ok: no problem! Ti inventi un tuo meccanismo di selezione multipla.
Bye
A

Ho risolto brutalmente impostando a mano RecNo su 1, ma visualmente ancora
non
compare il rettangolo... come faccio a far comparire quel CACCHIO di
rettangolo?
Andrea

Ho risolto brutalmente impostando a mano RecNo 
Ci rinuncio, è un caso disperato.



Sei sicuro che la griglia abbia il focus?


cui sopra!
Tre ore? 
Vedi, sei talmente presuntuoso che pensi di poter risolvere e
comprendere le cose in 3 ore. 
E con questo chiudo e ignoro il thread, Mi hai stufato.


 Sei sicuro che la griglia abbia il focus?
Si, quello è risolto.
Adesso però c'è una cosuccia che non capisco, mi faccio
risentire appena ho capito dov'è il problema.
Andrea

Allora, riesaminiamo il problema:
La questione era molto semplice.
Nel codice di caricamento della lista di oggetti, mancava un .First prima
del
ciclo ad Eof, ok?
Mancava semplicemente perché il lavoro sui dati veniva affidato a parti
specifiche di programma e non ai controlli visuali.
La DBGrid, dal canto suo, si posiziona sull'ultimo record, modificando
quindi
quell'ordine costituito.
Questo vuol dire semplicemente che il record selezionato di
default è sempre l'ultimo( per quale motivo, non si sa... ).
Di per sè la cosa non costituisce un problema, tuttavia essendo il
programma stato progettato per funzionare *senza* controlli data-aware,  si
è
creata una situazione di disallineamento, risolta proprio aggiustando il
caricamento dei
dati nella lista.
Ancora una volta, sono io che mi devo adattare ai controlli DA e non loro a
me...
Andrea

 default è sempre l'ultimo( per quale motivo, non si sa... ).
Seriamente tu ti stai chiedendo, dopo un ciclo del tipo
while not DataSet.Eof do begin
  // qualcosa
  DataSet.Next;
end;
perchè sei sull'ultimo record ?
--
Andrea /\/\agni
ICQ#: 174108000

 perchè sei sull'ultimo record ?
Ovviamente no, mi sto chiedendo solo perché non torna su.
Andrea

 Ovviamente no, mi sto chiedendo solo perché non torna su.
Io mi chiederei perchè mai dovrebbe farlo di sua iniziativa...
Cmq spero che questo thread non sia stato ormai ignorato da tutti e
approfitto per salutarvi: domani con grande gioia me ne vado al mare!
Buon lavoro a tutti quelli che restano sulla tastiera, buone ferie a tutti
gli altri ! :-)


 tutti gli altri ! :-)
Ciao, buone ferie :)))
Gaetano M.
ps.: quest'anno sono uno di quelli che restano :(

 tutti gli altri ! :-)
Buone vacanze, Andrea, io parto l'8!!!!!
Andrea

forse sarebbe il caso di chiedersi:
"xche dovrebbe tornare su?"
"chi ha la responabilità per decidere se tornare su o no?'
"in base a cosa, chi ha la suddetta responsabilità, decide se tornare su o
no?"
e non
"xche non torna su?'.
bye
A

 Beh, semplicemente perché io conto da 1, generalmente :-)
Ma arrivi fino in fondo e poi non ricominci da capo .. o no ?
Comunque le differenze di come si vedono certe cose ci sono, hai mai notato 
come negli stati uniti indicano il 3 con la mano (e come lo facciamo noi).
Ciao ;)
ps: riposati quando vai in vacanza mi sembri stressato :PPP

 ps: riposati quando vai in vacanza mi sembri stressato :PPP
Dopo 8 mesi passati fuori, nel paese dei Polaretti, lo saresti anche tu,
credimi :-)
Andrea

Ovviamente no, mi sto chiedendo solo perché non torna su.
...e vorrei vedere pure.


gli altri ! :-)
Grazie per il buon lavoro, ne ho bisogno sono ormai un uomo distrutto
BUUUUAHHHHHHH!!! BUUUHHH !!!!
(ormai sono andato..)
-- 
Morde. 
(morde at programmer dot net)

 (ormai sono andato..)
Tranqui non sei l'unico :-)
Andrea

 loro a me...
Questo è ridicolo. Certo che hai delle belle pretese!
La DBGrid è utile per navigare, inserire e modificare...ma se tramite
codice influisci su questi comportamenti, non puoi pretendere che i Data
Control intuiscano tutto ciò che hai inserito nel codice
"malaprogrammato" e risolvano i bug derivanti al posto tuo.


 "malaprogrammato" e risolvano i bug derivanti al posto tuo.
Mah, controllerň questo aspetto.
Se č davvero il codice mio a fare caciara, vi farň sapere.
Andrea

 Se è davvero il codice mio a fare caciara, vi farò sapere.
Sia ben chiaro, non ho assolutamente detto che il tuo codice sia errato,
ma se per qualche motivo scorri la tabella per effettuare
un'elaborazione e ti ostini a voler associare a tale tabella una
griglia, otterrai che:
1)
il codice lavora correttamente perchè esegue il compito per il quale è
stato progettato;
2)
la griglia lavora correttamente perchè riflette le modifiche e le
elaborazioni sul DataSet, inclusi inserimenti, aggiornamenti e
scansioni;
3)
il programma non funziona perchè hai un controllo a video influenzato
dal codice che hai scritto.
Sto dicendo che non è un problema di codice o di griglia...il problema è
che stai utilizzando uno strumento (la griglia) in un ambito in cui non
può essere applicato (elaborazioni tramite codice), pertanto non ottieni
effetti collaterali ma...solo un gran casino.


AH! Allora non sono pazzo a chiedere che lo faccia! :-)
Difatti lo fa.  Ciò che non fa è risolvere i bachi dei tuoi programmi.
Io non so se ti rendi realmente conto del modo usuale in cui tu pensi
di poter discutere di un argomento sul piano tecnico.  Non leggi
quanto viene scritto, non leggi l'help, non stai ad ascoltare.
Analizzi i malfunzionamenti di un tuo programma, relegando come
ultima, estrema possibilità, il fatto che tu possa aver fatto un
errore.  Accusi prima di tutto noi che non sappiamo usare la DBGrid, i
controlli db-aware, in generale, poi magari qualche bug nascosto nella
mente di qualche programmatore Borland e chissà cos'altro.  Insomma,
punti il dito contro tutto l'ordinamento delle cose, meno che verso te
stesso.  Questo è contrario al modo in cui un programmatore,
generalmente, cerca di risolvere i problemi.   Non sai programmare e
la cosa peggiore è che poi diffondi consigli a destra e a manca su
cosa usare Delphi.  Consigli che hanno come fonte, puntualmente, le
tue sperimentazioni sballate.


 pertanto non ottieni effetti collaterali ma...solo un gran casino.
Si, effettivamente non collaboravano :-)
Adesso si però :-)
Andrea

 consigli a destra e a manca su cosa usare Delphi.
Potresti riformulare, please? Non sono intelligente come te,
sono uno stupido, incompetente ignorante ricordi?
Devi parlare in modo semplice :-)
Andrea

 Adesso si però :-)
Solo per definire la mia posizione, viste anche le altre risposte
ricevute, dico solo che:
1) se il tuo intento è quello di risolvere i problemi del tuo programma,
personalmente non c'è alcun motivo per cui non si debba cercare di darti
una mano, anche per trarne qualche giovamento (leggi "imparare qualcosa
di nuovo") nel valutare questa o quella soluzione;
2) se hai il solo scopo di sostenere tesi infondate come
l'inaffidabilità della DBGrid tentando di inserirla in un luogo dove non
può stare e prendendo come effetti collaterali tutto ciò che la griglia
fa correttamente come una battaglia all'ultimo sangue contro i Data
Control in generale, allora non penso che continuerò a partecipare alla
discussione.
Ciao!


certi momenti la sensazione era quella
Con certa gente la pazienza è sempre troppa.
*plonk*
