23/05/2026 - sihsandrea ha scritto:
22/05/2026 - Catafirro ha scritto:
Avrei voluto scrivere sulla vecchia discussione, non potendo ho messo il link, lì è tutto spiegato. In ogni caso non chiedo ne voglio nulla, avverto solo di aver trovato finalmente la ragione per cui le form si rovinavano, magari qualcuno può evitare il problema, e avvertire chi avesse interesse alla soluzione delle tabelle temporanee che ho spiegato che si è dimostrata molto efficiente. Tutto qui.
Come ti è stato detto precedentemente, il tuo approccio è sbagliato. Anche distruggere il form alla terza chiusura non ha senso.
Quando si decide di creare il form al bisogno e distruggerlo quando non serve più appena si rende necessario il form si ricrea. In ogni caso, tu distruggi un form con dipendenze da form chiamante. Da lì l'errore generico che racchiude più casistiche che lo generano. I form li puoi distruggere quando il form principale viene chiuso, tu distruggi il form che deve riportare informazioni necessarie al form principale, ma distruggendolo non sono più disponibili le informazioni che il form richiede e da lì nasce l'errore. Puoi distruggere il form anche al primo close ma se il form viene evocato dal principale è il principale che deve distruggerlo, dopo aver prelevato le info che servono. In poche parole, se form1 fa create forme è form 1 che deve fare form2 destroy (o qualunque sia il comando per distruggere il form).
Form2 create
Fai quello che deve fare form2
Chiudi form2
Dopo la chiusura torni a form1 e quindi
Form2.destroy o free o altro in base al linguaggio
Se form1 crea form2 per avere dei dati e quando esci da form2 lo distruggi, form 1 non ha più accesso alle informazioni perché form2 non esiste più insieme ai suoi controlli e sue variabili.
Ergo, la soluzione che hai architettato è ancora precaria, in più devi gestire i casi di prima e seconda chiusura che non distruggono il form.
P.s. se vuoi puoi sostituire la parola distruggere con sfasciare ma nel primo caso la soluzione sarebbe arrivata all'istante. Distruggere significa che ho eliminato il form, sfasciare significa che qualcosa non funziona più.
Sicuramente per colpa mia, ma non credo tu abbia capito. Non c'è alcuna dipendenza tra le mie form, si tratta delle form multiistanza che vengono aperte non con il classico "DoCmd.OpenForm XXXXX", che consente di aprire una sola forma, ma con la sequenza
Public MultiForm As New Collection
....
....
Set frm = New Form_XXXXXX
frm.Visible = True
MultiForm.Add frm, frm.hwnd & ""
La collection Multiform contiene gli oggetti delle form aperte, la form esiste fino a che esiste il suo riferimento nella collection. Quando la form viene chiusa, sarebbe buona norma eliminare l'oggetto dalla collection, che altrimenti rischia di gonfiarsi di oggetti non più validi. Il problema del mio codice era che eliminavo l'oggetto nell'evento FORM_CLOSE della stessa form, che così si trovava ad esserne privata ancora prima di uscire definitivamente dalla memoria. La cosa non mi aveva mai dato problemi nella vecchia versione dell'applicativo, che interfacciava un backend access, in questa che interfaccia un db MySql sporadicamente rovinava la form nel repository. Quando me ne sono accorto ho evitato di eliminare l'oggetto dalla collection a chiusura maschera, ma lo faccio fare a una routine che entra in gioco periodicamente, scorre la collection, e quando trova un oggetto non più valido (corrispondente a una maschera chiusa) lo rimuove. Così tutto funziona benissimo.
La soluzione temporanea che avevo messo in piedi può comunque continuare ad avere un senso, poiché evita di usare la collection alla prima apertura (operazione che comunque costringe Access a lavorare di più), che viene eseguita con il classico DoCmd.OpenForm ed evita di aprire e chiudere le form di uso molto frequente, adottando la soluzione di renderle visibili/invisibili invece di aprile/chiuderle, con un percettibile miglioramento di performance per form molto pesanti.
Riguardo la mia soluzione delle tabelle temporanee, che funziona benissimo sul campo, la riassumo brevemente
1. Per ogni tabella MySql ho una sua immagine Access, che eventualmente può avere anche dei campi in più di comodo
2. Quando disegno una form, la collego alla tabella Access, mai alla tabella MySql che non collego neppure
3 Nell'evento Form_Open genero un clone temporaneo della tabella Access e lo collego alla form al posto di quella originale. Ho così una tabella temporanea nella quale posso caricare i record MYSql.
4 Carico i dati nella tabella temporanea attraverso recordset ADO
5 Le modiche ai dati vengono effettuate nella tabella temporanea
6 A conferma delle modifiche i dati vengono aggiornati nel db MySql via recordset ADO.
Eventuali campi in più nella tabella Access possono servire per visualizzare dati complessi non esistenti nel db MySql
Sia ben chiaro che non sono qui per insegnare il mestiere a nessuno, magari esistono soluzioni migliori della mia, senz'altro, forse però qualcuno può anche avere interesse a un approccio così fatto.