Italian community of Lazarus and Free Pascal

@ 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.
 

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.

Ciao Marco e benvenuto. Mi ha fatto estremo piacere che ti sei unito a noi dopo che hai letto quel mio commento su linkedin.

Grazie! Almeno questo mitiga un pochino la mia "colpevolezza" nel non essermi aggiunto prima. 

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! 👋

Il problema di apertura del display l'ho risolto installando il demone come user demone e impostando la partenza del servizio solo dopo l'apertura la creazione della sessione grafica.

Il "problema del display" non sappiamo quale è ... non ne hai accennato.

Come commento, anche se ciò che hai fatto è lecito (almeno in Linux), far dipendere un servizio dalla sessione grafica non è una buona cosa ... ovviamente a meno che il servizio non necessiti esplicitamente della sessione grafica, cosa che un servizio normale non ha.

Il cambio tra X11 e Wayland e gli stessi aggiornamenti di Wayland (che non è ancora stabile) potrebbero influire sul funzionamento del servizio in qualsiasi momento. Non da meno eventuali aggiornamenti o mantenimento di librerie di default. Diverse distribuzioni di Linux stanno "ragionando" se mantenerle o meno, per cui ti potresti trovare con una macchina nuova apparentemente identica a quella "vecchia" che però ... non funziona.

Detto questo ti auguro buon lavoro.