Form con Gridview pluririchiamata

[Picavbg]

Anche se la classe che ne faccia uso sia sempre la PdfWriter.Repo03pdf, l'argomento riguarda la necessità di creare una classe con object statico al fine di permettere il caricamento dei dati in esso contenuti. Spero di riuscire a spiegarmi:
Nel programma devo gestire l'eventualità che il riepilogo di una data giornata contabile venga richiesto, per la stampa, da due form diverse:
- Fmain, attraverso la barra dei menù
- Frm3, cioè la Form di quadratura e chiusura di una giornata contabile.

Entrambe le Form richiamano la Form di anteprima-stampa con:

Codice: [Seleziona]

FrmPrint01 = NEW FormPrint01($FrmParam, $TabResta, fSaldoIni, fSaldoFin, $TipoValuta)

La FormPrint01 a sua volta richiama PdfWriter per procedere alla stampa:

Codice: [Seleziona]

pdf = NEW Repo03pdf("Portrait", "mm", "A5")

Dovendo, a questo punto, PdfWriter.Repo03pdf estrarre i dati dalla griglia costruita in FormPrint01, ho incontrato qualche difficoltà ad indirizzare la FormPrint01.grigldview, perchè il percorso di indirizzamento cambia a seconda da quale sorgente parta la richiesta (FMain o Frm3). Per capire quello che sto dicendo basta dare un'occhiata ai due seguenti comandi:
 

Codice: [Seleziona]

ME.Cell(6, 4, FMain.Frm2.Frm3.FrmPrint01.GriStampa.Columns[0].text, TRUE, 0, "C", TRUE)
 ME.Cell(6, 4, FMain.Frm11.FrmPrint01.GriStampa.Columns[0].text, TRUE, 0, "C", TRUE)

i due comandi dovrebbero ottenere lo stesso risultato, ma, purtroppo, non in maniera perfettamente alternativa, e ciò a causa della diversa modalità di richiamo della FrmPrint01. Infatti se va bene per una, l'altra causa l'errore NUll Object.
 Allora ho studiato, provato e, dopo esserci riuscito, messo in pratica il seguente metodo:

Ho costruito una nuova classe che ho chiamato StmpRieMoG:

Codice: [Seleziona]

STATIC PUBLIC GriRiepMovg AS Object
STATIC PUBLIC iNuRiSt AS Integer
STATIC PUBLIC $TitDoc AS String

PUBLIC SUB _new(GridInput AS Object, $Titolo AS String, iTotRighe AS Integer)
'------------------------------------------
  GriRiepMovg = GridInput
  $TitDoc = $Titolo
  iNuRiSt = iTotRighe
END

Dentro la FrmPrint01 ho trasferito in essa i dati necessari per la stampa :

Codice: [Seleziona]

DIM GriStampa AS StmpRieMoG
----- bla ----- bla ----- bla -----
GriStampa = NEW StmpRieMoG(GridStamp, ME.Text, iTotRgStamp)
  RANDOMIZE 
  pdf = NEW Repo03pdf("Portrait", "mm", "A5")
----- bla ----- bla ----- bla -----

Infine nella WriterPdf.Repo03pdf, ho poteuto, finalmente leggere dalla gridview copiata prima in StmpRieMoG, i dati da stampare:

Codice: [Seleziona]

  ME.Cell(6, 4, StmpRieMog.GriRiepMovg.Columns[0].text, TRUE, 0, "C", TRUE)
  ME.Cell(72, 4, StmpRieMog.GriRiepMovg.Columns[1].text, TRUE, 0, "C", TRUE)
  ME.Cell(28, 4, StmpRieMog.GriRiepMovg.Columns[2].text, TRUE, 0, "C", TRUE)
  ME.Cell(18, 4, StmpRieMog.GriRiepMovg.Columns[3].text, TRUE, 0, "C", TRUE)
  ME.Cell(18, 4, StmpRieMog.GriRiepMovg.Columns[4].text, TRUE, 0, "C", TRUE)
----- bla ----- bla ----- bla -----
$StriMia = StmpRieMog.GriRiepMovg[i, 0].text
 ME.Cell(6, 4, $StriMia, TRUE, 0, "R", FALSE)
----- bla ----- bla ----- bla -----

Il risultato ottenuto è splendido, tuttavia mi lascia perplesso lo spazio occupato in memoria dalla duplicazione della gridfview, in forma statica. Infatti la dichiarazione STATIC PUBLIC GriRiepMovg AS Object fatta nella nuova classe impegna certamente un tot di memoria, ma da quando e per quanto tempo? Dall'avvio del programma? Da quando viene richiamata per la prima volta? Inoltre, l'impegno di memoria rimane fino alla conclusione del programma o fino alla chiusura delle form che ne fanno uso?

Mi sono dilungato un pò troppo, lo so, ma il mio desiderio di conoscenza è grandissimo, per cui grazie anticipate ìa chi possa colmare la mia ignoranza.
  

[md9327]

Utilizzare sempre classi statiche non è buona cosa...

Da quello che vedo hai implementato il passaggio di un puntatore ad un oggetto GridView, e la cosa và bene in quanto non ti obbliga ad indicare esattamente da quale form provenga. Questa metodologia non necessità di impostare classi statiche, anzi, è proprio il metodo giusto per evitarlo.

Riguardo all'occupazione di memoria, qualsiasi oggetto (anche una variabile o metodo) se definito statico occupa tanta memoria quando è la sua dimensione binaria. Qualsiasi riferimento ad un oggetto statico non duplica lo spazio occupato, ad eccezione dell'indirizzo binario del puntatore medesimo.
L'uso della memoria di un'oggetto statico è valida da quando viene avviata l'applicazione, fino a quando non viene chiusa. In alcuni linguaggi (non sò esattamente per Gambas), l'occupazione parte dal primo uso dell'oggetto, ovvero quando viene obbligatoriamente e dinamicamente creato da una prima chiamata.

Per ritornare al primo punto, io consiglio sempre di utilizzare il più possibile l'uso del passaggio parametri tramite metodi, anche se questo potrebbe risultare a prima vista dispendioso. Con l'implementazione in Gambas3 della possibilità di definire un parametro come puntatore di riferimento e/o copia della variabile passata, rende la cosa molto più dinamica e controllabile. E' ovvio che uno studio approfondito preliminare, ovvero un'analisi del singolo progetto, potrebbe risolvere molte cosette, ed evitare l'uso di sistemi anomali e l'uso indiscriminato e inutile di memoria.

[Picavbg]

Utilizzare sempre classi statiche non è buona cosa...

Da quello che vedo hai implementato il passaggio di un puntatore ad un oggetto GridView, e la cosa và bene in quanto non ti obbliga ad indicare esattamente da quale form provenga. Questa metodologia non necessità di impostare classi statiche, anzi, è proprio il metodo giusto per evitarlo.

Riguardo all'occupazione di memoria,...

Per ritornare al primo punto, io consiglio sempre di utilizzare il più possibile l'uso del passaggio parametri tramite metodi

Quando ho creato la StmpRieMoG.class, ho definito le variabili necessarie così:

Codice: [Seleziona]

PUBLIC GriRiepMovg AS Object
 PUBLIC iNuRiSt AS Integer
 PUBLIC $TitDoc AS String

ma ho ricevuto errore proprio perchè non erano "StTATIC". Perciò ho dovuto aggiungere la parolina. Può darsi, per quanto mi dici, che abbia sbagliato qualcos'altro, ma, purtroppo, non lo immagino neppure.
A me, come puoi capire,  la dichiarazione static di variabili non piace, ed è per ciò che ha aperto la discussione. Se m'illumini ulteriormente, potrei migliorare il pogramma. 
 

[md9327]

A meno che tu non abbia creato variabili NON statiche in una classe STATICA, mi pare molto strano che ti abbia ritornato errore, semmai il contrario.

Credo che il concetto di "statico" sia stato affrontato più e più volte, ma è anche probabile che alcune cose non siano state recepite come dovrebbero, a causa sicuramente di qualche lacuna personale, che è ovviamente comprensibile...

STATIC: il concetto "static" definisce una cosa che prende immediatamente vita appena il contesto in cui si trova si attiva, ovvero e nel nostro caso l'avvio dell'applicazione. Una volta che il supporto, ovvero l'applicazione viene meno (si ferma), il contesto cade e tutte le cose che facevano riferimento e su cui si appoggiavano cadono anch'esse, ovvero vengono eliminate. Non stò qui a parlare di come questo avvenga, perchè credo serva più parlare della logica che racchiude il concetto, che quello che lo applica.

DINAMIC: diversamente da "static", una cosa dinamica viene creata quando serve, e muore quando si decide che questa non sia più utilizzabile. La cosa, o "oggetto", è anch'esso dipedente dal contesto in cui viene creato, e quindi può vivere solo se l'ambiente stesso, ovvero l'applicazione, è viva.

A livello di programmazione, è possibile creare oggetti dinamici con componenti statiche (es. un metodo o una proprietà), mentre non è assolutamente possibile farlo con oggetto statici, che possono supportare solo metodi e proprietà anch'esse statiche. Un elemento statico non può fare riferimento diretto a elementi esterni ad esso (es. un'altro oggetto), ma solo tramite passaggio di puntatori validi. Questo può avvenire in due modi: 1) assegnando ad un elemento statico un valore definito (es un valore numerico), oppure 2) un puntatore (che è sempre un numero) ad un oggetto già creato (o da creare , dipendentemente dalla logica usata).

Detto questo, e riprendendo il mio precedente discorso, l'utilizzo della memoria, sia per un oggetto statico che per un oggetto dinamico è diverso. Il primo la occupa dall'inzio alla fine della vita dell'applicazione, il secondo solo per il tempo della sua miserevole vita...
Quanto poi un oggetto occupa come spazio di memoria, dipende dal tipo di oggetto. Tieni conto che una proprietà è uguale ad una semplice variabile, ad eccezione del fatto che di questa ne viene creato un duplicato per ogni oggetto creato dello stesso tipo. Lo spazio usato dalla varibile è dipendente dal tipo.
Per i metodi la cosa è leggermente diversa... Un metodo è una porzione di codice, che può contenere anche sue variabili per uso interno, e lo spazio che utilizza è dipendente dalla complessità del metodo stesso. La differenza dalle varibili stà anche nel fatto che la duplicazione dell'oggetto non duplica anche i metodi, ma solo le variabili usate dal metodo (gran risparmi di memoria, no?).

Per il momento mi fermi qui, in quanto ho superato i limiti di tempo...