Scusami non avevo capito che il codice era VB e io non sono abbastanza esperto.
In ogni caso mi sembra che quanto stai cercando di scrivere in codice VB sia la sequenza logica di quanto vorresti vedere a video, ma credo non sia la strada migliore.
Posta un po' di codice per dare un'idea di quanto stai facendo, altrimenti immaginiamo tutti cose diverse dalla realtà. Ad esempio io mi aspetterei quanto segue (scrivo in C# per comodità ma credo sia comunque abbastanza intellegibile):
Punto 1: i dati vanno segregati in classi che li gestiscono, sia per le letture che per le scritture. As esempio le fatture immagino che siano istanze di una classe del tipo:
using System;
using System.Collections.Generic;
public class InvoiceItem
{
string description;
float qty;
float unitPrice;
float totalprice
{
get
{
return unitPrice * qty;
}
}
}
public class Fattura
{
//MEMBRI
string address;
ClientList cliente;
List<InvoiceItem> itemList;
static int maxID = 0;
int invoiceID;
public InvoiceValue
{
get
{
..un foreach sui totalPrice di ogni elemento.... e lo ritorni
}
}
public Fattura()
{
... quanto serve qui per inizializzare una fattura...
invoiceID = maxID++;
}
}
class Program
{
public static List<Fattura> ListaFatture;
... varie proprietà....
... il main che richiama il form principale...
}
Tali dati andrebbero sencondo me dichiarati come statici nel wrapper del software (che in C# sarebbe la classe Program) in modo che siano raggiungibili da ogni form che tu possa generare.
Punto 2: ogni Form che crei deve contenere solo membri per gestire le funzioni essenziali dell'esperienza utente, non i dati a cui gli algoritmi si applicano. In linea di principio nemmeno gli algoritmi dovrebbero far parte delle classi che derivano da Form.
Punto 3: Ogni form deve poter accedere al database statico, in modo da poter sincronizzare gli accessi e non corrompere i dati. Quando scrivi che per poter accedere all'elenco fatture devi accedere al form3 secondo me fai un errore. I dati devono essere scorporati dal form, anzi devono essere segregati in qualcosa che possa essere gestito indipendentemente dalla vita del Form. (Domanda stupida: se il form non esiste in runtime non esiste nemmeno l'elenco fatture?, mi sembra assurdo...devo aver imaginato male)
Punto 4: Ogni fattura dovrebbe essere indirizzabile in lista tramite un campo identificativo univoco, come per esempio quello che io ho chiamato invoiceID, che è gestito da un contatore statico che sicuramente ti permette di generare id unici, e che viene incrementato direttamente nel costruttore di classe come ti ho indicato sopra. a questo punto qualsiasi form che acccede all'ipotetico metodo
public static Fattura Program.ListaFatture.GetFatturabByID(int requestedID)
{
foreach (Fattura ft in ListaFatture)
{
if (ft.InvoiceID == requestedID)
return ft;
}
return null;
}
può usare la fattura in lettura, scrittura, elencazione.
Un'ultima nota, che comqune ti sconsiglio: se proprio non voui modificare quanto hai già fatto, allora puoi aggiungere un referrer ad ogni Form seocndario richiamato dal primo form, del tipo
(dentro Form 2 e 3)
private Form referrer;
....
nella classe program al punto di definizione delle variabili globali metti
public static Form linkerToForm1;
nel costruttore di FOrm1 metti:
Program.linkerToForm1 = this;
e nel costruttore di Form2 o di Form3 metti
referrer = Program.linkerToForm1
in questa mainera se dichiari i metodi pubblici di form1, potrai richiamarli da dovunque, generando qualcosa is simile ad un callback artigianale.
Ora però ti consiglio di postare un po' di codice davvero, altrimenti fai faticare chi tenta di aiutarti senza probabilmente darti vero valore aggiunto.
Spero di aveti comunque aiutato in qualche modo.
[terza modifica ma di sicuro l'ultima: leggiti questo post in VB per il passaggio variaibili tra form :: http://www.dotnethell.it/forum/messages.aspx?ThreadID=39991.]
Ciao
Alessandro
Alessandro Parma
Programmazione multipla scoposta con prognosi ancora da definirsi