[RISOLTO] Passaggio dati tra due Form

[Gianluigi]

@Tornu

Io il tuo programma l'ho scaricato tanto che se ti scarichi quello che ho postato io, due post sopra questo rispondendo a Picavbg ti accorgi che tengo proprio conto di quanto da te postato e successivamente scritto. O meglio quello che io ho capito.
Evidentemente però non ho capito e quindi sono a chiederti: Visto che intanto l'ho fatto puoi vedere quello qui postato che scambia fra tre finestre e dirmi cosa non fa che tu vorresti invece facesse?
Grazie
 

[tornu]

Ho scaricato e provato il tuo esempio, ma non si applica all'esigenza per cui io ho aperto questa discussione.
Tu hai creato una Form che fà da contenitore ad altre tre Form sempre attive che vengono inizializzate all'avvio
del programma dalla FMain e scambiano dati tra di loro.
La mia esigenza è diversa , e non credo che possa applicare il tuo codice.
Provo a sintetizzartela in modo schematico (magari il mio esempio o quello da me scritto nei precedenti post non sono eplicativi).

1) Avvio il programma visualizzando una Form vuota (nel mio caso FMain) che automaticamente visualizza al suo interno la prima Form (Form1)
   e che fa sempre (FMain non viene mai chiusa) da contenitore alle altre Form che vengono richiamate/visualizzate solo se eccessario
   da oggetti o procedure.
2) Per mia neccessità (nel caso in discussione) quando richiamo per esempio dalla Form1 la Form2, la Form1 viene chiusa.
3) Quando richiamo la Form2 si possono verificare tre casi:
    caso1: La Form1 non passa dati alla Form2, ma deve prelevarli da essa, chiudendo la Form2 deve passare i dati prelevati alla Form1.
    caso2: La Form1 alla sua chiusura passa dei dati alla Form2, nel quale vengono elaborati., chiudendo la Form2 i dati modificati passano alla
              Form1
    caso3: La Form1 alla sua chiusura passa dati alla Form2, i dati passati dovranno essere modificati prelevando i nuovi dati da una Form che si
              aprirà in modalità ShowModal (lasciando la Form2 attiva) chiusa la quale i dati vengono inseriti nella Form2....ect...
La casistica secondo che programmi realizzi può essere anche molto più complessa, ma capita la logica (quello che stò tentando io) la si può applicare
a qualsiasi neccessità come dice Picavbg.
Spero di averti spiegato in modo più comprensibile l'esigenza, avevo postato l'esempio2 proprio perchè spiegarlo a parole mi senbra più complicato.

[Picavbg]

Non ho capito l'utilità della variabile iSwReturn puoi essere più dettagliato.
La Form chiamata riceverà i dati dell'array con il metodo _new, ho capito bene?

L'array valorizzato nella Form chiamante (da questo momento FormX1) coi dati da passare alla Form chiamata (da questo momento FormX2) viene acquisito dal costruttore della FormX2, cioe dalla classe _new di quest'ultima. Una volta costruita la FormX2, l'esecuzione del contatore di istruzioni ritorna sulla FormX1 che esegue la chiamata in modalità Showmodal. Tuttavia è necessario indicare come destinataria del valore numerico di ritorno una variabile di tipo integer, esattamente come si fa quando si richiama una funzione:

Codice: [Seleziona]

iSwReturn = FrmX2.showmodal()

Detto meccanismo permette di avere ritornato non solo iSwReturn, ma anche i dati dell'array modificati in tutto o in parte dalla FormX2. Attenzione però perchè l'array preso in carico dalla FormX2 dovrà, qualora occorra, essere modificato al suo interno. Infatti il suo aggiornamento non è automatico.
Come succeda che al rientro dalla FormX2, l'array valorizzato nella FormX1 risulti modificato non è dato saperlo perchè nessuna guida di Gambas lo chiarisce, però ciò succede solo utilizzando il metodo di chiamata in showmodal descritto sopra. Se si prova ad eseguirlo nella maniera tradizionale, anche dopo avere richiamato il costruttore (_new), l'array conterrà sempre i valori di partenza, senza le modifiche apportate nella FormX2.

Spero che abbia chiarito tutti i tuoi dubbi. 

[tornu]

Grazie Picavbg, concetto esposto con molta chiarezza ed applicato con successo. 

Ora mi viene in mente un'altra domanda (l'appetito vien mangiando...) sempre inerente il concetto di passaggio dati.
Poniamo che il nostro progetto sia un gestionale, abbiamo una Form "Ricerca Anagrafica Clienti" che come puoi ben
capire sarà richiamata da vari punti del programma Emmissione Fatture, DDT, Ordini, ect... e quindi dovrà passare
uno o più dati alla Form chiamante, con i concetti da te espressi posso passare al costruttore _new un dato
tramite variabile o più dati con un array, ma come faccio a scindere quale è la Form chiamante e passargli i dati?

La prima cosa che mi è venuta al volo è quella di aggiungere un'altra variabile in caso di passaggio tramite variabili
o un'altro dato all'interno dell'eventuale array da usare come flag di identificazione della Form chiamante, è la strada
corretta o ci sono altri metodi?

[Picavbg]

Grazie Picavbg, concetto esposto con molta chiarezza ed applicato con successo. 

Ora mi viene in mente un'altra domanda (l'appetito vien mangiando...) sempre inerente il concetto di passaggio dati.
Poniamo che il nostro progetto sia un gestionale, abbiamo una Form "Ricerca Anagrafica Clienti" che come puoi ben
capire sarà richiamata da vari punti del programma Emmissione Fatture, DDT, Ordini, ect... e quindi dovrà passare
uno o più dati alla Form chiamante, con i concetti da te espressi posso passare al costruttore _new un dato
tramite variabile o più dati con un array, ma come faccio a scindere quale è la Form chiamante e passargli i dati?

La prima cosa che mi è venuta al volo è quella di aggiungere un'altra variabile in caso di passaggio tramite variabili
o un'altro dato all'interno dell'eventuale array da usare come flag di identificazione della Form chiamante, è la strada
corretta o ci sono altri metodi?

La chiamate di un Form tramite il parametro showmodal pone il Form chiamato  in stato di dipendenza rispetto al Form chiamante. Ciò significa che mentre è attivo, il Form chiamante resta in stand-by, in attesa che il Form chiamato gli restituisca il controllo delle operazioni di elaborazione. Te lo dimostra il fatto che se tu clicchi sul Form chiamante, visibile sotto quello attivo (il chiamato ), non ottieni alcun effetto. Quindi il Form chiamante potrà ritornare attivo solamente dopo che il Form chiamato avrà eseguito la sua brava Close e nel caso specifico della chiamata eseguita nella modalità su cui stiamo ragionando dovrà restituire anche un valore. Riporto, anche se ridondante, la chiamata fatta dal Form chiamante:

Codice: [Seleziona]

FrmX = New FormX(vDati)
iSwReturn = FrmX2.showmodal()

Nel Form chiamato all'esecuzione della:

Codice: [Seleziona]

 Me.Close(x)   ' dove x costituisce i valore destinato a iSwReturn

come avrai certamente utilizzato, il Form chiamato cessa il suo status di attivo che viene ripreso dal Form chiamante con l'istruzione successiva a quella della chiamata. Essa dovrebbe essere quella di riconoscimento del contenuto di iSwReturn. E' anche il momento di rilevare del contenuto aggiornato dell'array che hai passato al momento della chiamata.

Non vedo perciò alcuna necessità di passare dati dal chiamato al chiamante in maniera diversa da quella appena descritta più dettagliatamente.
Se ci rifletti con lo showmodal hai realizzato un pseudo-incapsulamento. Non è proprio un incapsulamento perchè non è completamente automatico, ma si avvale della chiamata preliminare del costruttore _new.
 

[Gianluigi]

La chiamate di un Form tramite il parametro showmodal pone il Form chiamato  in stato di dipendenza rispetto al Form chiamante. Ciò significa che mentre è attivo, il Form chiamante resta in stand-by, in attesa che il Form chiamato gli restituisca il controllo delle operazioni di elaborazione. Te lo dimostra il fatto che se tu clicchi sul Form chiamante, visibile sotto quello attivo (il chiamato ), non ottieni alcun effetto. Quindi il Form chiamante potrà ritornare attivo solamente dopo che il Form chiamato avrà eseguito la sua brava Close e nel caso specifico della chiamata eseguita nella modalità su cui stiamo ragionando dovrà restituire anche un valore. Riporto, anche se ridondante, la chiamata fatta dal Form chiamante:

Codice: [Seleziona]

FrmX = New FormX(vDati)
iSwReturn = FrmX2.showmodal()

Nel Form chiamato all'esecuzione della:

Codice: [Seleziona]

 Me.Close(x)   ' dove x costituisce i valore destinato a iSwReturn

come avrai certamente utilizzato, il Form chiamato cessa il suo status di attivo che viene ripreso dal Form chiamante con l'istruzione successiva a quella della chiamata. Essa dovrebbe essere quella di riconoscimento del contenuto di iSwReturn. E' anche il momento di rilevare del contenuto aggiornato dell'array che hai passato al momento della chiamata.

Non vedo perciò alcuna necessità di passare dati dal chiamato al chiamante in maniera diversa da quella appena descritta più dettagliatamente.
Se ci rifletti con lo showmodal hai realizzato un pseudo-incapsulamento. Non è proprio un incapsulamento perchè non è completamente automatico, ma si avvale della chiamata preliminare del costruttore _new.
 

Attenzione perché quanto qui sostieni è corretto solo nel caso di form esterno.
Se al contrario, come inizialmente postato da Tornu noi inglobiamo il form chiamato nel form chiamante, noi non avremo il comportamento tipo della finestra di dialogo ma un normale show e quindi quanto qui sostieni viene a cadere, tranne che otterremo lo stesso i dati corretti.
Poi per quanto io ne possa capire visto che solo ora mi interesso di OOP, riguardo l'incapsulamento qui siamo agli antipodi.
Naturalmente sempre per quanto io ne possa capire tu con questo sistema dai un contenitore, pieno in parte o vuoto che sia, e lo consegni all'altro oggetto che ne faccia ciò che gli pare prima di restituirtelo cambiato.
Esattamente l'opposto dell'incapsulamento che infatti consiglia l'uso delle proprietà che è il sistema per ricevere il valore da altri controllare (di nascosto) se è corretto e quindi implementarlo.
Si lo so che questo è comunque demandato al programmatore ma questo è l'attrezzo e il sistema migliore per poter ottenere detto incapsulamento.
Poi dovremmo anche tener conto del polimorfismo, vale a dire come si presentano gli oggetti abitualmente a noi.
 

[Picavbg]

@ GianLuigi

Scusami, ma non capisco cosa vuoi dire.
Per quanta riguarda la chiamata di un Form  con showmodal il Form chiamato non è un Form esterno. Esso è direttamente dipendente del Form chiamante e mentre il chiamato è attivo il Form chiamante va sicuramente in stand-by.
 

[Gianluigi]

@ GianLuigi

Scusami, ma non capisco cosa vuoi dire.
Per quanta riguarda la chiamata di un Form  con showmodal il Form chiamato non è un Form esterno. Esso è direttamente dipendente del Form chiamante e mentre il chiamato è attivo il Form chiamante va sicuramente in stand-by.
 

Quando Tornu ha aperto la discussione ha postato due esempi il primo funzionante come dimostrazione di quanto voleva ottenere e il secondo quello vero che non faceva quanto da lui sperato.
Vuott ha trovato subito la soluzione, però a mio modestissimo parere in modo diciamo così non conforme ai canoni teologici della programmazione orientata agli oggetti. 
Quanto da Tornu richiesto era lo scambio di informazioni fra una finestra Fmain, una finestra Form1 incorporata in Fmain e una Form2.
Se noi ci atteniamo a questo e insieme usiamo il metodo da te indicato “ereditato” da md9327, metodo che se non erro dovrà essere così applicato (almeno io l'ho provato in questo modo e funziona):

Codice: gambas [Seleziona]

Frm1 = New Form1(vParametri, Fmain)

a questo punto anche se mostriamo la Frm1 in modalità modale (dialogo) non otterremo quanto otterremmo dal tuo codice se non incorporassimo la Frm1 e la chiamassimo con ShowModal().
Volevo dire questo quando mi sono riferito a “Form esterno” rispetto al Form incorporato.

Intendiamoci io non sono lo sciamano addetto alla reliquia della Prima Proprietà, il mio intento è solo comprendere bene per poter bene indirizzare giovani gamberetti.
Pertanto non posso che ringraziarti del tuo cortesissimo interessamento.
Sai come in tante altre cose la programmazione ci offre molte vie alla meta ma io credo che alcune siano migliori di altre, non intendo più dirette o con minore occupazione di memoria, intendo complessivamente più consone.
 

[Picavbg]

@ Gianluigi

Non so da quanto tempo tu di dedichi alla OOP, personalmente, dopo avere approcciato qualcosa in VB, ai vecchi tempi antecedenti all'incontro con Linux, ho cominciato ad addentrarmi un pò nel bosco di tale ambiente dopo avere fatto i primi passi con Gambas. Ho appreso alcune sue caratteristiche con la pratica di sviluppo del programma  che mi interessava di più. Le conoscenze teoriche sono la conseguente deduzione  delle applicazioni pratiche delle varie istruzioni e metodi, sia dirette che indirette, attraverso le costruttive discussioni affrontate e vissute in questo nostro magnifico Forum.
Sicuramente porto con me ancora molte lacune, soprattutto in argomenti come incapsulamento, ereditarietà, poliformismo, metodi nascosti ...

Penso però anche che insistendo su queste nostre riflessioni possiamo darci tutti una mano a superare ostacoli e capire concetti ancora nebulosi. È giusto pertanto che ne continuiamo a parlare, anche facendo riferimenti ad appunti ed informazioni presenti nella grande biblioteca di Internet.
 

[vuott]

... in modo diciamo così non conforme ai canoni teologici della programmazione orientata agli oggetti.  

...ma questo principio può valere soltanto in un ambito meramente didattico.

[Gianluigi]

@Picavbg
Sono d'accordo con te in tutto e per tutto. Anche se il “possiamo darci tutti una mano” mi sa che è un tutti un po tanto ristretto.
Aggiungo solo una riflessione a quanto dici per me la programmazione orientata agli oggetti non è un dio, un totem e vedo che non lo è per lo stesso Minisini che infatti l'ha inglobata in Gambas solo in parte.
Io ad esempio penso che difficilmente avrei occasione di usare l'ereditarietà, se mi serve una classe più estesa non vedo il motivo di farne una più striminzita per poi doverla allargare, a meno che non si tratti di esigenze future allo stato attuale non esistenti e manco prevedibili. Quindi utile solo in prospettiva futura. Intendiamoci comunque un'opportunità in più per la nostra programmazione.
Poi il concetto seppur interessantissimo del riutilizzo del codice lo vedo un po tanto difficile da mettere in pratica. Io certamente se penso una classe la penso per quel particolare problema e la creerò per quel singolo problema senza starmi tanto a scervellare se poi potrò usarla per altro o addirittura per tutto e potrei continuare così su altri aspetti.
La cosa per me veramente importante di questa astrazione è la disciplina che ti puoi imporre nel tentare di creare una applicazione armoniosa fatta tutta di mattoncini intercambiabili come una costruzione Lego. Questo si che io trovo veramente geniale, se si riesce a creare un programma in cui nessuna classe dipende da elaborazioni fatte in altre classi il gioco è fatto.
Avremo un debug semplicissimo perché potremo escludere dall'errore via via ogni oggetto che darà risultati coerenti. Se un domani dovremo aggiungere qualcosa ad una classe basta intervenire solo li e se l'interfaccia non deve cambiare il gioco della manutenzione diventa decisamente semplice.
Bene se sei ancora sveglio ti saluto.

@vuott
Come vedi da quanto scritto a Picavbg sono d'accordo anche con te, non sono certamente un fanatico di questa astrazione.
Però, per quanto detto, trovo che cercare di rendere indipendente ogni classe sia un'ottima cosa. Un'applicazione ben congegnata con classi indipendenti difficilmente affonderà proprio come una nave con buone paratie stagne.

 

[Top Fuel]

Vuott ha trovato subito la soluzione, però a mio modestissimo parere in modo diciamo così non conforme ai canoni teologici della programmazione orientata agli oggetti.  

Il mio (altrettanto) modestissimo parere è che non è obbligatorio essere un talebano della OOP e seguire al 100% la Bibbia del Programmatore ad Oggetti se una soluzione alternativa permette di risolvere un problema.
Anche Francesco Balena (sappiamo tutti e 2 chi è) quando scriveva su Computer Programming diceva chiaro e tondo di essere uno che non andava tanto per il sottile se trovava una soluzione che migliorava/velocizzava un certo algoritmo, compreso l'utilizzo dei famigerati Goto/Gosub (e posso dimostrartelo) perciò penso che l'utilizzo di qualche variabile globale o qualche cazzabubolo non strettamente OOP non credo che faccia implodere il Sistema Solare in un buco nero.

[Gianluigi]

@TopFuel
ma dai quale talebano delle OOP, come ho ampiamente detto io sto tentando di capirci qualcosa.
Butto li delle cose e vedo se poi qualcuno salta su dalla cadrega. 
Però insisto per quanto riguarda la disciplina della classe incapsulata, questa la trovo davvero utile.
Hai praticamente un faro che ti guida ovunque, una volta abituati ad usarlo tutto dovrebbe essere più semplice.
Inizialmente può apparire complicato ma se lo si analizza bene e ci si costringe ad usarlo diventa semplice e in seguito dovresti avere meno grattacapi.
Uso il condizionale perché le mie per ora sono solo prove sperimentali che non hanno ancora subito il battesimo del fuoco anzi neanche quello della compilazione.
Io noto una cosa che si ripete continuamente in modo similare; chi arriva da esperienze VB/VBA come me tende a creare in Linux con Gambas il clone di quanto aveva già fatto in Windows.
Proprio prima di Natale ho ricevuto una mail da un ex cliente che mi chiedeva, essendo la precedente defunta, un parere su quale stampante fosse più adatta da usare per “il suo eccellente programma... un modello che possa adattarsi alle caratteristiche del suo software...”.
Come vedi anche io avrei qualcosa da clonare ma non ci penso neanche ad usare Gambas come ho usato VBA senza prima adattarmi a Lui.
Il discorso che tu fai ha la sua valenza io ad esempio nel succitato software, o in altro di pari difficoltà ora non ne sono sicuro, ho usato i salti con le etichette però successivamente riguardando il codice mi sono accorto che avevo fatto una cosa inutile che potevo facilmente evitare oltre tutto scrivendo meno codice. Poi che cosa significa velocizzare dipende dal tipo di software io ad esempio quel poco che ho fatto era tutto software che interagiva con l'user pertanto la velocità contava praticamente zero.
Il mio modesto pensiero è questo fare programmazione è difficile, farla bene lo è ancora di più se utilizzi un metodo, o un sistema vedi tu, ti rendi la vita più facile. Lo devi fare per te stesso mica per gli altri.
Riguardo il mitico Balena se ti leggi il super tomo di .net 1300 pagine circa temo stenteresti a riconoscerlo.
 

[Picavbg]

@ Gianluigi
Benissimo, allora, a parte le disquisizioni di carattere tecnico, volendo tornare all'oggetto dell'argomento corrente, tu dici:

Quando Tornu ha aperto la discussione ha postato due esempi il primo funzionante come dimostrazione di quanto voleva ottenere e il secondo quello vero che non faceva quanto da lui sperato.
Vuott ha trovato subito la soluzione

Secondo me, sebbene sia una soluzione pratica,  quello non è un passaggio di dati ma è semplicemente una valorizzazione di una variabile appartenente ad un altro Form.

Ho riguardato il tuo esempio:

Codice: [Seleziona]

Frm1 = New Form1(vParametri, Fmain) 

ma non ho capito il secondo campo nella lista dei parametri (Fmain) passati alla Form1.
 

[Gianluigi]

@ Gianluigi
Benissimo, allora, a parte le disquisizioni di carattere tecnico, volendo tornare all'oggetto dell'argomento corrente, tu dici:

Quando Tornu ha aperto la discussione ha postato due esempi il primo funzionante come dimostrazione di quanto voleva ottenere e il secondo quello vero che non faceva quanto da lui sperato.
Vuott ha trovato subito la soluzione

Secondo me, sebbene sia una soluzione pratica,  quello non è un passaggio di dati ma è semplicemente una valorizzazione di una variabile appartenente ad un altro Form.

Qui occorre intendersi quindi ti chiedo si tratta solo di "semantica" oppure intendi qualcosa di più specifico?

Ho riguardato il tuo esempio:

Codice: [Seleziona]

Frm1 = New Form1(vParametri, Fmain) 

ma non ho capito il secondo campo nella lista dei parametri (Fmain) passati alla Form1.
 

Ti allego una piccolissima dimostrazione che credo sia più esplicativa, così mi dici come avresti fatto tu e ci capiamo meglio.