Newsgroup: it.comp.appl.access
Titolo: Variabile pubblica: impossibile assegnare un valore all'oggetto

Sto diventando pazzo. Due giorni che tribolo con lo stesso problema.
 
In un modulo standard dichiaro come Pubbliche 3 variabili stringa: 
EserCorr, EserPrec, EserSucc richiamate abbastanza spesso dalle numerose 
maschere del db (da qui il motivo 'Pubbliche').
 
Mentre EserCorr ed EserPrec mantengono regolarmente il loro valore, 
appena apro una maschera (Preventivi) la var. EserSucc è NULLA. Non dà 
errore e la procedura prosegue come se niente fosse.
Se tento di valorizzarla ecco il messaggio in oggetto numero -
2147352567
 
(80020009).
Ho riscritto quasi tutto il codice della form, ho fatto il debug 
passo-passo con F8, ho compilato il codice nell'editor dal menù debug > 
compila Database1 (lo uso in caso di difficoltà perché mi tira sempre 
fuori qualche str...), ho, ovviamente, guardato su internet se trovavo 
qualcosa di chiarificatore, ho perfino cambiato il nome alla variabile 
pensando che al mio PC non gli piacesse... nisba... buio assoluto!
Sono già cotto a puntino e pronto per la neuro, ma prima che quei 
signori in camice bianco arrivino, qualcuno può suggerirmi qualcosa di 
drasticamente utile?
Grazie.
 
P.S. Pardòn: A2010 32bit su Win10 64bit

 Sto diventando pazzo. Due giorni che tribolo con lo stesso problema.
 
Generalmente Access ha sempre ragione.
Sei sicuro che sia dovuto a quella variabile?
Fare un copia incolla del pezzo di codice che ritieni in
errore non sarebbe male.
Segnalando la istruzione che lo provoca.
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)


 
Non c'è nessun codice particolare. Comunque:
 
Private Sub Form_Open(Cancel As Integer)
     Dim sSql As String, sumTab As Single
     Dim rs As DAO.Recordset, noDivZero As Single
 
     On Error GoTo errsub
     'cancella eventuali dati esistenti
     sSql = "DELETE tblTmpPrev.* FROM tblTmpPrev;"
     CurrentDb.Execute sSql
     sSql = "INSERT INTO tblTmpPrev ( Esercizio, Tab, Descr, Spesa, 
EserSucc, Variaz, Prev ) " _
         & "SELECT tblBase.Esercizio, tblBase.Tab, tblBase.Descr, 
Sum(tblBase.Debito) AS Spesa, " _
         & "'" & EserSucc & "' AS EserSucc, CSng(0) AS Variaz, 
Sum(tblBase.Debito) AS Prev " _
         & "FROM tblBase " _
         & "GROUP BY tblBase.Esercizio, tblBase.Tab, tblBase.Descr;"
     CurrentDb.Execute sSql
 
Funziona così: all'avvio si apre la form principale che contiene un 
controllo 'spostamento', che non è altro come un controllo a schede che 
già conoscevamo. Premendo uno dei pulsanti in colonna sulla sinistra 
visualizza la form interessata, né più né meno come fa un controllo a 
schede. Funziona tutto. Quando però premo il pulsante per visualizzare 
frmPreventivi e parte la routine sopra esposta, la variabile EserSucc è 
Null mentre un miliardesimo di secondo prima era ancora valorizzata. Se 
imposto una riga tipo EserSucc="2016-17" appare il msg descritto nel 
posto precedente. Questo avviene anche se tento di valorizzare la 
variabile nella finestra immediata.
Nota che se invece cambio, anche manualmente, il valore di EserCorr ed 
EserPrec tutto funziona come deve funzionare.
Riesci a capire qualcosa, p...ca v...ca?!?!?
 
 
 


Il NULL /non/ dovrebbe dare problemi poiche' fai questa concatenazione
& "'" & EserSucc & "' AS EserSucc.. che male che vada diventa
& "'' AS EserSucc..
Non ho capito pero' dove prende /quello/ errore.
Non sulla execute! E non sulla concatenazione! Immagino
Il fatto che tu abbia cambiato nome alla variabile ed hai ancora errore
esclude che ci sia una variabile locale dello stesso nome ed hai
giurato che le tre variabili sono stringhe.



Ale ti ringrazio per l'attenzione (sono diversi anni che seguo questo 
gruppo ed ho sempre fatto tesoro delle indicazioni tue e degli altri). 
Ma, guarda, un rompicapo come questo non mi era mai capitato.
Questa stramaledetta variabile (è stringa, te lo assicuro) mantiene il 
valore nel momento in cui si apre la maschera (evento 'su apertura'), ma 
diventa NULL quando si esegue l'INSERT INTO, e non si capisce il perché. 
Anche su internet non c'è casistica se non per quanto riguarda questo 
errore riferito a controlli e/o maschere.
Se non trovo una soluzione devo ritornare alla prima stesura che era 
quella di memorizzare questi tre valori in una piccola maschera nel FE, 
ma questo metodo mi comporta una marea di DLookUp da usare in ogni 
routine in cui mi serve il dato. Bah, pazienza... grrr...!!! :-(
 
In ogni caso sempre un caloroso grazie a te e a tutto il ng.
 
mantro
 
--
 

 routine in cui mi serve il dato.
 
Io invece persino preferisco caselle di testo (spesso invisibile) sulla 
maschera di avvio/principale, cioè switchboard, dell'applicazione. 
Diverso delle variabile pubbliche è sicuro che hanno un valore anche 
dopo un errore nel codice.
 
Uso funzioni pubbliche che prendono i valori dalla maschera. Poi 
dapertutto nell'applicazione (espressioni di query, maschere ecc. o 
codice) chiamo queste funzioni.
 
-- 
Ciao
Karl
*********
Access FAQ:  
http://www.donkarl.com/it
 
 


Grazie Karl, sempre cortese come al solito. :-)
Alle txtbox nascoste, sinceramente, non avevo pensato. È una possibilità 
che devo valutare per le numerose chiamate occorrenti.
Il ricorso a funzioni pubbliche lo faccio abbastanza spesso proprio su 
tuo suggerimento in risposta a vari quesiti.
Solo che, questa volta, pensavo di aver scoperto l'acqua calda usando 
variabili pubbliche. Ma guarda in che casino sono andato a mettermi!!
 


E' una form di tipo dialog?
Ricordati che se non lo e' esegue l'evento ma poi continua ad eseguire
il codice dell'eventuale chiamante.



Non è una form; ho sbagliato a scrivere; è una tabella.
Mi spiego. Quando devo ricorrere spesso agli stessi dati, come in questo 
caso in cui ho bisogno di usare di frequente il valore dell'esercizio 
corrente, precedente o successivo, creo in locale nel FE una 
semplicissima tabella che mi tiene memorizzati questi dati.
C'è ovviamente un aggiornamento o ad ogni avvio del programma oppure 
durante lo stesso se si dovesse rendere necessario. Si tratta 
praticamente di un solo record.
Il problema (se problema si può definire) è che devo usare un DLookUp 
ogni volta che una routine ha bisogno di questi dati.
Pensavo di accorciare il lavoro con le variabili pubbliche, ma visto il 
ginepraio...
 


Si ma quel codice da dove lo lanci?
Ooops!
Scusa non avevo visto che lo hai sulla Open
Vabbe' io non uso la tua struttura (e neanche quella di Karl)
ma non ho /mai/ avuto problemi con le Public di qualsiasi tipo
Tu mi stai dicendo che mettendo un breakpoint, che ne so,
ad esempio sulla On Error EserSucc e' impostata e che, invece,
  se guardi poi in sSql dopo averla valorizzata con la INSERT
  trovi il valore vuoto?
Hai scritto che usi il debugger.
 
Non ci credo neanche se lo vedo ;-)


 Non ci credo neanche se lo vedo ;-)
 
Dunque: (e con dunque non si inizia mai un discorso... insegnavano una 
volta a scuola...)
 
- Apertura programma tramite piccola form popup con due listbox in cui 
si sceglie l'esercizio ed il condominio; ci sono già evidenziate due 
voci in base ai dati ancora memorizzati in quella tab posta nel FE dalla 
chiusura precedente.
- Con il pulsante cmdOK
	--> se la selezione del condominio è cambiata, riallego le tabelle (per 
non complicarmi troppo la vita ho un BE per ogni condominio),
	--> assegno i valori alle variabili pubbliche poste in un modulo standard,
	--> chiudo la popup di apertura e apro la form principale che, con un 
nome molto fantasioso, ho chiamato frmGestione.
 
Questa è composta da un ctr di tipo spostamento (che fino ad A2003 non 
esisteva, giusto?) con sette pulsanti posti in verticale sulla sinistra. 
Ogni volta che premo uno di questi pulsanti posso accedere ad un 
ulteriore controllo a schede che mi permette di lavorare sulle form che 
mi interessano: anagrafiche, impostazioni, spese, letture, suddivisioni, 
ripartizioni ecc. ecc.
Funziona tutto perfettamente, le variabili pubbliche hanno sempre il 
loro valore, ma... quando premo il pulsante per aprire il ctrScheda con 
due schede (Consuntivi e Preventivi rispettivamente) succede l'inghippo.
Aprendo la frmPreventivi (è il codice che ho postato), la var. EserSucc 
NON HA PIù il suo valore, è NULLO! La procedura va in errore ed esce.
 
Tu dubiti che usi il debbuger! E come no! Ho messo il breakpoint subito 
dopo la riga on error. L'errore è il 2424 "Impossibile trovare 
l'oggetto" o qualcosa di simile. Ho cancellato praticamente tutta la 
SELECT rimettendo tutti gli oggetti uno alla volta,beh... l'oggetto che 
manca è proprio lo stramaledetto EserSucc... non esiste più, svanito, 
puff!... ma EserSucc esiste ancora, solo che è Nullo, e mi puoi credere, 
Ale, che è proprio così! Che ci sia qualcosa di sbagliato ne sono 
convinto anch'io, ma cosa? A meno che sia proprio access pronto per la 
neuro... cosa comunque di cui ne dubito :-)
Se tento di rivalorizzare EserSucc mi appare l'errore chilometrico di 
runtime di cui ho già scritto "Impossibile assegnare un valore all'oggetto".
Una precisazione: questa variabile la uso solo in questo modulo, mentre 
le altre due le uso in tutto il programma e funzionano benissimo.
Ora sto riscrivendo tutto il codice per questa maschera e proverò a 
mettere la variabile solo in locale, speriamo bene! Ciò non toglie però 
che le... pallottole mi stiano girando vorticosamente...
 
 
 


 
Perche' non posti lo snip di dove definisci ed inizializzi le variabili?



 
Caro Ale... HO RISOLTO!!!
Onestamente mi vergogno a dirlo perché sono scivolato sulla classica 
buccia di banana ed ho commesso un errore che non mi sarei mai aspettato.
La famigerata variabile ha lo stesso nome di un controllo della 
frmPreventivi. Controllo che non uso e che ero convinto di aver 
cancellato ancora nelle precedenti stesure. Invece, il maledetto si era 
nascosto dietro un altro e l'ho scoperto solo per caso accedendo 
all'elenco a discesa dei controlli nelle proprietà della form.
Dire che sono rimasto di m.... è usare un eufemismo troppo benevolo.
Sono sinceramente dispiaciuto per il tempo che ti ho fatto perdere.
Grazie comunque per la tua cortesia!
 
mantro