Italian community of Lazarus and Free Pascal
Programmazione => Generale => Topic aperto da: Avogadro - Maggio 23, 2023, 12:52:43 pm
-
Ciao a tutti .
Allora, nelle versioni precedenti di lazarus era immediato cambiare le proprietà (colore, font etc) di una riga dei una dbgrid in funzione di una data condizione.
Esempio in letteratura:
https://forum.lazarus.freepascal.org/index.php?topic=39288.0
Ma c'è ne sono tanti altri, soprattutto in delphi.
Ora con l' ultima versione il cambiamento chiesto viene applicato solo sulla cella e non si propaga all' intera riga:
Codice reale *:
procedure TForm1.RxDBGrid4PrepareCanvas(sender: TObject; DataCol: Integer;
Column: TColumn; AState: TGridDrawState);
...
begin
...
// fuori controllo
//
// R:4:1s definizone: Two measurements in the same run have a 4 standard deviation difference
// 2 casi, range e range mobile
// 1:2s, 1:3s: ....
...
...
case column.FieldName of
'RM': case iszero(ztable4RM.AsFloat) of
true:;
false: begin
// testa Srw , scarto tipo assegnato
case iszero(ztable3Srw.AsFloat) of
true: ;
false: if (ztable4RM.AsFloat > 4*ztable3Srw.AsFloat) then
with (Sender as TRxDBGrid) do
Canvas.Font.Color:= clred;
end; // case
....
Questo codice nelle vecchie versioni di lazarus colorava di rosso l' intera riga, adesso solo la casella selezionata .
Si, per l' interfaccia con l' utente va bene così, purtuttavia come si fa a cambiare il colore dell' intera riga in funzione di una data condizione ?
Grazie anticipate .
*
si, è del codice per una carta di controllo di shewart, lo scopo è avere in real time il fuori controllo
-
Buongiorno, senza un esempio da poter testare diventa difficile esserne sicuri. Però a naso direi che il problema è nei case in cui vai a finire. Hai provato a mettere dei brackpoint e vedere da che parti passa?
-
Quell'evento viene chiamato per tutte le celle che devono essere "disegnate", quindi ogni cella che aderisce ai vari case / if deve essere colorata.
Come ti riportava @xinyiman, verifica i case.
Ciao
-
I case li ho seguiti sia con il debugger step by step, sia con il logout di tutto in un campo memo .
Sono andato in loop perchè lo stesso codice nelle versioni precedenti del compilatore (ante 2019) colorava l' intera riga, adesso solo casella selezionata dal case "fieldname".
Finisse qui:
- Ho provato a smanettare ulteriormente con degli esempi trovati in rete ed esce un errore di type casting .
- c'è un problema con i colori: funzionano solo quelli standard (https://wiki.freepascal.org/Colors ) , gli altri non funzionano - no, in rete non ho trovato nulla in merito .
Pazienza, aveva ragione Guglielmo di Occam, "È inutile fare con più ciò che si può fare con meno".
-
Proprietà "DefaultDrawing" del componente è a false ?
-
verifico subito ...
-
in effetti era su true, deseleziono e provo a ricompilare
-
Le cose sono peggiorate: adesso l'alternate color non va pui' e tutte le righe sono con lo sfondo bianco e solo la casella con il fuori limite è con il font di colore rosso .
Pazienza, va bene lo stesso così, alla fine l' importante è che il fuori specifica risalti subito ; un ' intera riga in rosso salta prima all' occhio, ma va bene anche una casella con il testo in rosso.
L' ideale sarebbe un "hint" sulla casella in rosso che spieghi il fuori limite (tipo i commenti alle celle in excel et similia) ma in letteratura non ho trovato nulla.
-
Giusto per .
Allora, google propone questo video
https://www.youtube.com/watch?v=vbHhS4EthU4
L'esempio è in delphi e si poggia sull' evento della dbgrid "drawcolumncell" ed è piu' complesso della soluzione da me adottata.
Ora non ricordo bene, ma avevo letto che l' uso di "dracolumncell" è deprecato in lazarus ed è preferibile il "prepare canvas" ; il perchè non lo so, documentazione per approfondire non se ne trova - non so che stia succedendo sul web, si trova sempre meno materiale interessante e il web stesso sta diventando l'analogo dei depliants publicitari degli ipermercati -
Tornando all' esempio del video: fanno uso di "if then else ", io preferisco l'approccio con il selettore multiplo e l' uso di funzioni tipo iszero, inrange et similia ; il codice è piu' leggibile - giusto per : a suo tempo avevo trovato un sorgente in turbo pascal per formattare il codice pascal e renderlo così piu' leggibile -.
Nel caso delle carte di controllo di shewart et similia non è questione di lana caprina: vanno implementate le regole di Westgard (https://www.westgard.com/) ed altre ancora e reificarle in un codice sorgente non è immediato.
Proverò a seguire l'esempio del video , anche se delphi è un altro pianeta - il probelma non è solo il costo, è anche restare aggiornati -.
-
Il discorso non è complesso.
L'evento preparecanvas non esiste in Delphi ed è prevista in Lazarus per la differenza di gestione delle "canvas" per il multipiattaforma.
Dentro li è meglio porci i settaggi riguardanti background e font.
L'evento DrawColumnCell invece è quello in cui "scrivi" il testo formattandolo (ad esempio allineamento a destra, sinistra o centrato) in Lazarus, mentre in Delphi ci fai tutto.
Nel caso di una griglia standard non legata al DB gli eventi relativi riportano le coordinate della cella (riga, colonna), invece nei controlli DBAware gli eventi sono legati alla colonna.
Sono stati fatti diversi post su questi argomenti nel forum, te ne indico uno vecchiotto ma sempre valido:
https://www.lazaruspascal.it/index.php?topic=1929.msg13389#msg13389 (https://www.lazaruspascal.it/index.php?topic=1929.msg13389#msg13389)
Ciao
-
ok, grazie
:)
-
Risolto: per cambiare colore all' intera riga basta poggiarsi sull' evento "draw column cell "
procedure TForm1.RxDBGrid10DrawColumnCell(Sender: TObject; const Rect: TRect;
DataCol: Integer; Column: TColumn; State: TGridDrawState);
begin
case ztable10lock.AsBoolean of
true:RxDBGrid10.Canvas.Font.Color:=clblue;
false:RxDBGrid10.Canvas.Font.Color:=clblack;
end;
RxDBGrid10.DefaultDrawColumnCell(Rect, DataCol, Column, State);
end;
-
Se puo' servire:
Allora, il problema è proteggere le celle di una dbgrid da sovrascritture accidentali (come si fa in excel et similia) ; non è questione id lana caprina, l'entropia è sempre lì , pronta portare i sistemi nel caos *.
Girando per il web per la storia dei colori nelle dbrgid in funzione di determinate condizioni , ho messo a punto il seguente codice, che sembra funzionare - ovvio che tutto è perfettibile -
procedure TForm1.ZTable10AfterScroll(DataSet: TDataSet);
var i, n:integer;
ro: boolean; // read only
begin
// per evitare editing accidentali
n:=rxdbgrid10.Columns.Count;
ro:=rxdbgrid10.ColumnByFieldName('lock').Field.AsBoolean;
statusbar1.Panels[2].Text:=ztable10norma.AsString;
for i:=0 to n-1 do
case rxdbgrid10.Columns.Items.Field.FieldName='lock' of
true:;
false: rxdbgrid10.Columns.Items.ReadOnly:=ro;
end;
end;
*
e a veicolare un rilievo in fase di audit -"non ha ... " -.
Ciao a tutti .
-
Per proteggere un DBGrid ci sono due semplici modi alternativi:
1) Attivare la proprietà ReadOnly del componente;
2) Disattivare la proprietà "dgEditing" dalle "options" del componente.
Se uno vuole editare si può attivare l'edit tramite una richiesta esplicita con una messagebox oppure un altro componente. O anche una sequenza di tasti similmente a CTRL DEL che cancella il record (o riga) e magari lo si fà notare all'utente con un cambio di colore, un lampeggio, etc ....
Ciao
-
Si concordo, ma il problema è la "dinamicità", mi si passi il termine .
Cerco di spiegarmi meglio: cerco di limitare al massimo i click, i messaggi, etc etc .
E' un bias che mi ha indotto delphi perchè dopo qualche icona in piu' se ne usciva sempre con l' errore che "le hand" erano terminate e tutto andava in crash - che cosa proponevano tutti quelle belle cose nell' ide se poi windows dopo qualche tasto in piu' andava in crash ?* - .
Quindi trovo piu' comodo mettere nella riga della dbgrid un tasto "lucchetto aperto /chiuso " che protegga i dati da cancellazioni o sovrascritture involontarie e nel frattempo non appesantisca l' interfaccia con l'utente con messaggebox e quant' altro .
Poi ripeto, ci sono piu'modi per fare la stessa cosa, ognuna con i suoi pro e i suoi contro
Adesso ho un' ultima gatta da pelare: sto sviluupando un sw in "house" per le carte di shewart**; la ratio è che quando l' utente mette il un dato di un controllo l' eventuale "fuori controllo/fuori specifica" deve saltare subito all' occhio- perchè da quel controllo mancato un lotto della produzione puo' saltare, poi con sti chiari di luna vallo a dire al capo -. Ora senza stare lì a disegnare grafici - si è un attimo e tchart è un prodotto egregio - , l' idea è quella di un hint che al passaggio del mouse sul fuori limite dica cosa è successo .
Come fare ancora non so, ma come diceva il poeta "se tutto il codice dovessi leggere, se tutto l' indice dovessi volgere, qualche garbuglio si troverà"
Ciao.
*
si adesso non è piu' così ma rimane sempre valido il principo di pareto applicato all' informatica : l' 80 e passa % delle "cose" di un sw non viene mai usato, già va bene quando se ne usano un 10 % , quindi tanto vale limitarsi all'essenziale.
**
si, in giro se ne trovano anche free sul web, ma il punto è avere una visione d'insieme delle cose che si fanno in officina .
un esempio sui controlli statistici è questo sito :
https://www.statskingdom.com/
si, son tutte cose che sulle librerie - gratis - di lazarus ci sono già, ma è un sito ben fatto, fare di piu'non so se ne poi ne vale la pena
anche questo sito è un cult :
https://keisan.casio.com/exec/system/14059932254941
e anche in questo caso le stesse cose si possono fare con le varie librerie di lazarus, ad esempio c'è l 'esempio "fit" nelle demo a corredo , che dà anche un output migliore.
Morale: adesso l' importante è avere delle idee, per reificarle ci sono tutti i mezzi free sul web .
-
O della "Quinta legge dell'inattendibilità": "Errare è umano, ma per incasinare davvero tutto ci vuole un computer.”
L' evento "draw column cell " cancella tutti i valori aggiunti della rxdbgrid, in primis il word wrap nelle celle .
Quindi avevano ragione a dire che è un componete da considerasi deprecato, tant'è che l' ho dovuto levare dalle rxdbgrid .
Pazienza, cerchero' soluzioni alternative , tipo i panels della status bar.
-
O della "Quinta legge dell'inattendibilità": "Errare è umano, ma per incasinare davvero tutto ci vuole un computer.”
L' evento "draw column cell " cancella tutti i valori aggiunti della rxdbgrid, in primis il word wrap nelle celle .
Quindi avevano ragione a dire che è un componete da considerasi deprecato, tant'è che l' ho dovuto levare dalle rxdbgrid .
Pazienza, cerchero' soluzioni alternative , tipo i panels della status bar.
Quell'evento viene chiamato per "disegnare" la cella, ossia colorare il background, "scrivere" con un font il testo (o altro), formattare i caratteri, bordare , ....
Se nulla viene fatto in quell'evento allora la cella rimane vuota.
Quando si pone la proprietà DefaultDrawing a false, la cella non viene più toccato dal gestore standard. E' in quell'evento che deve essere "riempita".
Ciao
-
Si è così, ma mi ero poggiato su rxdbgrid per evitare di dover gestire direttamente tante cose, in primis le righe che si adattano in altezza al testo.