Italian community of Lazarus and Free Pascal

ma mi sono bloccato per la presenza fra i parametri, del TObiect (non so cosa scriverci).

Quell'oggetto è la tua StringGrid, quindi passi l'istanza (ossia la variabile, non la classe).

Citazione da: petrusic - Giugno 27, 2025, 09:59:15 am

l'anomalia, al click su una cella della StrinGrid, mi si manifesta solamente quando clicco sulla cella dati della 1^a colonna e della 1^a riga della StringGrid.

Secondo me ciò succede solo alla prima visualizzazione. Prova a cliccare una cella della seconda riga e poi di nuovo uno della prima e vedrai che funzionerà.
Accade perchè la griglia alla partenza è predisposta con una cella "puntata" e dovrebbe essere la cella 1 sulla riga 1 (ciò la prima dopo le righe / colonne "fixed").
Quindi il primo click li non funzionerà. Se cambi cella e ritorni li invece dovrebbe lanciarti l'evento.
Non sò se ciò è effettivamente così, ma a memoria ricordo di una anomalia simile.

Si, se cambio cella, funziona, ma se insisto a cliccare sempre sulla 1 cella dati di vertice (dopo le righe / colonne "fixed"), continua a NON funzionare. L'ho già constatato. Per non dovermi ricordare di non cliccare sulla quella cella, pensavo infatti di aggirare l'ostacolo, richiamando io la procedura GridPreMomBeforeSelection, ma mi sono bloccato per la presenza fra i parametri, del TObiect (non so cosa scriverci).

Può capitare infatti che la griglia si componga di una sola riga dati o che, debba cliccare sulla prima delle righe dati e, siccome, in teoria, non sono obbligato a fare attenzione su quale cella di una riga debba andare a cliccare, volevo liberarmi dalla costrizione  operativa di escludere dal click la prima cella della prima riga dati.

Ma mi pare di capire che stiamo parlando di un'anomalia di Lazarus, non aggirabile.

Ciao @xinyiman,
ho visto il tuo post sull'argomento nel forum internazionale.
Il progetto viene seguito direttamente dal Michael Van Canneyt e da Mattias Gaertner.

Entrambi non fanno attività sul forum da diverso tempo, quindi probabilmente non hanno letto o non sono stati avvertiti mancando un qualsi voglia riscontro al tuo post (poi magari ti hanno risposto in privato).

Prova a rivolgerti direttamente a loro per avere info più specifiche rispetto a quelle che puoi dedurre.

Se vedi il progresso del progetto dai commit, secondo me siamo ancora lontani da una proposta usabile in produzione: è di Aprile l'implementazione ad esempio dell'HANDLING da TASTIERA, due mesi fà.

Inoltre e da più di un mese che non ci sono attività sul progetto.

Sostituire (o in qualche modo adattare o convertire) le LCL ad un ambiente WEB nativo non è operazione da poco .. sopratutto se orientato su diversi sistemi operativi (praticamente quelli coperti da SKIA).

Io, a parte il grande entusiasmo legato al primo annuncio (e stavo quasi andando in Germania alla convention), non penso che lo vedrò operativo per poterlo usare ... 

Se posso commentare il tutto, anche sull'onda generale, secondo me i team LAZARUS / FPC dovrebbe concentrarsi di più su un ambiente (SO) specifico, chiudere il più perfettamente possibile quello e poi passare "in massa" ad un altro.
La politica di non produrre aggiornamenti che stabilizzerebbero almeno una situazione sino a quando tutta una schiera di ambienti non sono allineati non mi convince.

Il compilatore FPC ha ormai più 4 anni con dei bachi importanti noti, e solo perchè molti hanno protestato stanno per uscire con un aggiornamento (FPC 3.2.4 / 3.2.5 fermo anche quello da anni) che tra l'altro non sistemerà tutto il pregresso.

E se vedi moltissimi post riportano: "ma su FPC 3.3.1" questo è stato sistemato, usate la versione trunk, salvo poi fare marcia indietro con l'avvertimento dei più saggi che dicono di attendere o assolutamente non usare la versione trunk per gli ambienti di produzione.

Tanto per fare un esempio, mi pare che gli utilizzatori Linux di Lazurus siano la maggioranza (ed è giustificato dalla presenza di pochi ambienti di sviluppo simili a Lazarus integrati sotto Linux).

Secondo me si dovrebbero dedicare un tot di risorse su ciò e stabilizzare perfettamente l'ambiente Linux, poi magari si passa su Windows o su altro.
Tra l'altro Linux è la base per tutta una schiera di altri SO derivati, quindi stabilizzando Linux si avrebbe probabilmente una stabilizzazione anche di tutti gli altri.

Ma questa è una mia visione, e probabilmente non coincide (o non è fattibile la percorrenza di ciò) con la visione dei team, o magari la mia visione è totalmente sballata.

Comunque, ritonando a bomba sull'argomento, prova acontattare i due manutentori del progetto Fresnel. Quel progetto porterebbe veramente una ventata di novità ed è più probabile che risulti più stabile addirittura della LCL.
SKIA è un prodotto ormai maturo, ampliamente usato anche da Delphi nei vari ambienti:

OS    Version Requirement
Windows    10, 11
Linux    Ubuntu 24.04+
macOS (x86_64)    10.15 or later
macOS (arm64)    11 or later
iOS    12 or later
Android    5.0 (Lollipop) or late

e potrebbe veramente rappresentare un futuro (stò parlando per gli aspetti UI, cioè grafici in quanto ciò ha molto poco a che fare con applicazioni senza grafica).

Bye bye

Oggi ho incontrato una sorpresa imprevista, mquando, nella prova programma, dopo avere riempito una StringGrid coi dati riepilogativi di una serie di movimenti, ho cliccato sulla prima riga della StringGrid.

Ebbene, l'Evento OnBeforeSelection non si è attivato e cella cliccata, insieme a tutta la riga, non è stata selezionata.
Il codice interessato è il seguente:

Dalla Console ho rilevato la mancata chiamata della procedura "TForm4.GridPreMomBeforeSelection":

-----
procedure TForm4.GridPreMomClick
iyCell= 0
ixCell= 0
iRgMax= 8
procedure GridPreMomSel

Come si può riscontrare, la prima procedura attivata dal click sulla GridPreMom è la TForm4.GridPreMomClick, mentra avrebbe dovuto essere la TForm4.GridPreMomBeforeSelection

Non so se qualcuno della comunità ha mai vissuto esperienze come la m ia attuale.
Vorrei solo sapere se posso richiamere io, da codice, la  TForm4.GridPreMomBeforeSelection, in modo da potere ottenere le coordinate della cella cliccata.

Si ma il cliente vuole che il codice sorgente possa essere compatibile e compilare sia in delphi sia in lazarus

Usa il TJVMemoryData che è (dovrebbe ?? ) essere disponibile sia in Delphi che in Lazarus.

L'alternativa è usare componenti di ultriori terze parti come ZEOS (compatibile sia con Delphi che con Lazarus) ... da verificare se ha la possibilità di creare i DS in memoria.

Il TClientDataSet mi pareva che una volta potesse creare tabelle in memoria, ma sinceramente non lo uso da anni a causa della distribuzione della MIDAS.DLL (ora c'è il link statico della LIB e non serve più distribuire la DLL).
Potrebbe esserci (vado a memoria) una classe equivalente in Lazarus tipo TBufDataSet (o simile).