StringGrid Colonne nascoste

[petrusic]

La mia StringGrid corrente è formata da 24 colonne.
Di esse vorrei lasciare visibili solamente le prime 7, perchè le successive contengono dati utili solo per la programmazione.
Avevo pensato perciò di renderle tutte abilitate ma NON Visibili.
Ho scoperto però che impostando la proprietà "Visible= False", le colonne vengono anche disabilitate.

Dopo tale scoperta l'unica alternativa percorribile è quella di creare una tabella bidimensionale che riporti al suo interno l'intera StringGrid.

Una tale gestione però mi complicherebbe molto la vita, perchè impegnerei intanto tanta memoria in più di quella effettivamente necessaria e poi, perchè dovrei ogni volta portare un doppio aggiornamento, uno sulla StrngGrid ed una sul corrispondente elemento della tabella.

Dal mio punto di vista di programmatore, non capisco come mai non sia possibile impostare la proprietà Enabled per le colonne componenti la StringGrid.

[bonmario]

Ciao,
quella che ti sto per descrivere, è una soluzione che avevo trovato anni fa, non ricordo i motivi, e può anche essere che nel frattempo le cose siano cambiate, ma oramai mi sono abituato così

Questo il codice che uso a programma per nascondere le colonne, in pratica imposto la loro larghezza a 0:

Codice: [Seleziona]

WrkStringGrid.ColWidths[NumCol]:=0;

dove WrkStringGrid è il nome della tua StringGrid, e  NumCol è il numero della colonna che vuoi nascondere. Occhio che la prima colonna è la colonna 0, e così via.


Il difetto di questa soluzione, è che se uno sa che c'è questa cosa, potrebbe "allargare" la colonna col mouse, come si fa normalmente in "Esplora risorse" o simili

Ciao, Mario

[CompilaQuindiVa]

La mia StringGrid corrente è formata da 24 colonne.
Di esse vorrei lasciare visibili solamente le prime 7, perchè le successive contengono dati utili solo per la programmazione.

Ciao, stavo riflettendo sulla parte del tuo messaggio in cui hai specificato "dati utili solo per la programmazione".

Mi fa pensare che il controllo StringGrid che stai utilizzando visualizzi informazioni a partire da una struttura dati già esistente (tabella, lista, ecc.), recuperata in precedenza: se questo è vero, perché non togliere queste informazioni che non devono essere visualizzate dalla griglia e mantenere una sorta di "riferimento" (indice della riga, campo ID, ecc.) all'interno della griglia stessa, facendo sì che tramite questo dato si possa risalire alla struttura in memoria che contiene tutte le altre informazioni?

Metti anche il caso in cui, in futuro, tu debba memorizzare per le righe dati che non sono "piatti", ossia organizzati in un solo livello, ma più strutturati e quindi difficilmente rappresentabili in termini di colonne, questo approccio ti consentirebbe di farlo, mentre la memorizzazione all'interno della griglia da questo punto di vista ti limiterebbe enormemente.

C'è anche un altro aspetto da considerare: usare la griglia come "storage" per i tuoi dati incentiverebbe troppo la scrittura di codice legata eccessivamente a elementi dell'interfaccia utente, che come tali si portano dietro API, routine e altre risorse (in generale, dipendenze) che dovresti sempre "linkare" anche se il tuo unico scopo magari è quello di mantenere dati in memoria.

Prova a fare una riflessione in merito, poi suppongo che altri utenti possano darti consigli più specifici in proposito.

Certo, lo scenario è più complesso di quello attuale, quindi la scelta di "azzerare" la larghezza della colonna può essere una soluzione "secca e dura", come si suol dire, valida nel suo contesto.

Un saluto! 👋

[petrusic]

Grazie.

quella che ti sto per descrivere, è una soluzione che avevo trovato anni fa,
 . . .
in pratica imposto la loro larghezza a 0:
. . .

Non ci avevo pensato, però l'Utente può sempre aumentare la larghezza delle colonne e leggere dati per lui non significativi.

. . .
C'è anche un altro aspetto da considerare: usare la griglia come "storage" per i tuoi dati incentiverebbe troppo la scrittura di codice legata eccessivamente a elementi dell'interfaccia utente, che come tali si portano dietro API, routine e altre risorse (in generale, dipendenze) che dovresti sempre "linkare" anche se il tuo unico scopo magari è quello di mantenere dati in memoria.

Prova a fare una riflessione in merito,
. . .

La soluzione:
Ampiezza colonna = 0
 non mi piace perchè in realtà non nascondo le colonne, allora tanto varrebbe impostare anche, nel progetto definitivo'  il colore del testo uguale a quello dello sfondo, quanto meno le colonne restano visibili ma sembrano vuote.

La soluzione:
 Pensare allo spreco di memoria usando la StringGrid come se fosse una tabella
 è pesante, lo so, ma quando l'ho pensata, mi è sembrata pratica da impegare ed ora mi divenma oneroso modiicarla

Volendo metterla in pratica, si potrebbe:
1) Riorganizzare i dati in modo da distribuirli fra quelli utili solo per l'utente finale e quelli utili solo per la programmazione.
    -- Però mi sembra farraginosa da gestire.
2) Costruire una tabella di interfaccia, che contenga sia i dati utili all'Utente finale, sia tutti gli altri e scrivere ciascuna riga della StringGrid copiando nelle celle corrispondenti soltanto gli elementi utili all'Utente finale.
      -- Anche questa impegna non poco per adottarla.

Ci ragionerò sopra.
Grazie ancora.

[DragoRosso]

Ciao @petrusic.

Dal punto di vista generale, tendenzialmente non si usa una "stringgrid" per contenere dati (formule o altro) come fosse un foglio Excel.
Accennava @CompilaQuindiVa che quei dati possono essere raccolti altrove (ad esempio in un array a due dimensioni che simula riga e colonna per i dati eccedenti).

E in effetti questa potrebbe essere sicuramente la soluzione più semplice. Poi ovviamente è necessario vedere il tuo contesto, ad esempio se quei dati necessitano di svariate modifiche e quindi è necessario presentarli comunque in modalità grafica.

Ti ricordo che, come hai fatto nel passato nel personalizzare il riempimento della StringGrid, puoi sempre non "disegnare" quelle colonne lasciando a vuoto il valore in caso ad esempio di uso utente, e di visualizzarne il contenuto in caso di "progettazione". In questo caso l'uso di un semplice array esterno ti facilita le cose.

Complessità delle operazioni, a cui giustamente tu accenni: prova a fare un pensiero a delle procedure (o funzioni) che facciano il lavoro "sporco", non sei tu a codice che riempi 1, 2 tabelle o n array, è la tua procedura che lo fà in fase di riempimento o lettura della stringgrid senza doverti preoccupare di dover fare queste operazioni da tutti i "punti" in cui inserisci i dati.

Esempio:

Codice: [Seleziona]

type
  TStringGrid1 = Class(TStringGrid)
        ....
        ....
     public
        procedure RiempiGriglia(.........);
  end;

var StringGrid1: TStrinGrid;
      stringarray:  array of array of string; //Devi dimensionare da qualche parte l'array prima di usarlo
      USOPROGETTAZIONE: boolean = False;      /SE messo a TRUE indica che i dati devono essere visualizzati in griglia

...........
...........

procedure TStringGrid1.RiempiGriglia(.........);
begin
   //Qui non faccio i controlli di coerenza .... devi farli tu in base ai tuoi dati.
   //Il tutto può ovviamente evolversi.

   .......
   .......

   //Col e Row indicano la cella che devi riempire
   //ColDaNascodere indica il numero massimo di colonne da visualizzare

   if (not USOPROGETTAZIONE) and (Col >= ColDaNascondere)  then
     begin
        //Inseriamo i dati nell'array invece che nella griglia
        stringarray[Col-ColDaNascondere][Row] := DATO_DA_INSERIRE;
     end
   esle
     begin
        //Inseriamo i dati nella griglia
        StringGrid1.Cells[Col, Row] := DATO_DA_INSERIRE;
     end;
end;

Oltre a questo, c'è la gestione come accennato del ridimensionamento dell'array a runtime (sia in costruzione / modifica / distruzione), del suo svuotamento preliminare quando carichi una griglia nuova, e della operazione opposta ossia della lettura dei dati per la loro memorizzazione dall'array o dalla griglia in base all'uso utente o progettazione.

[petrusic]

@ DragoRosso

Si, tutto vero. L'ho anche indicato nella mia risposta  di  prima. In ogni caso bisogna che metta di nuovo le mani nelle porzioni di codice che si occupano dei relativa caricamenti.

Come detto prima, ci devo pensare.

Per ora devo capire come variare la larghezze di una o più colonne col mouse, da utente finale.
Il meccanismo funzionava fino a 2 o 3 giorni fa. Ora non funziona più. Ma ciò non riguarda questa discussione.
 

[DragoRosso]

Il meccanismo funzionava fino a 2 o 3 giorni fa. Ora non funziona più. Ma ciò non riguarda questa discussione.
 

(StringGrid1) -> Options ... SPUNTA goRowSizing, goColSizing nell' Object Inspector