[VB6] Controllo ADODC e DB Access con Password

[oregon]

Ma hai letto il mio post? Non mi sembrava trasparente ...

[calabar]

@Oregon
Certo che l'ho letto
Ma, dimmi tu se ho mal interpretato, si riferiva al fatto che non riuscissi a cambiare la connection string, cosa che invece era dovuta ad un errore di copiaincolla della stringa, e quindi era stato risolto (la "piccola correzione... " cui accenno subito sotto).

@vaitrafra
Ok, credo di seguirti.
Ero convinto occorresse comunque settare la connection string correttamente, ma noto che, se l'adodc non è legato al alcun controllo, non è necessario.

Piuttosto ora devo trovare il modo per legare il datagrid all'adodc da codice (idee?).
EDIT: si associa tramite la parola chiave "Set".

C'è però un ultimo punto: il caricamento dei vari form.
Finora mi è parso che la cosa avvenisse in maniera del tutto automatica (prima l'mdi, poi gli altri in ordine), quando hai detto di caricare i form tramile "load" ti riferivi forse ad un caricamento manuale?
In tal caso, come procedere, o meglio, come evitare il caricamento automatico?

[calabar]

Ri-Edit: Per quanto riguarda il caricamento dei form, ho notato che il richiamo degli adodc dalla mia sub di inizializzazione provoca immediatamente il load dei form in cui questi sono inseriti.
Cosa decisamente prevedibile, ma che mi ha costretto a spostare alcune routine che, caricate durante il load del form, davano errore a causa degli adodc non ancora del tutto inizializzati.
Sarebbe meglio a questo punto dichiarare esplicitamente il caricamento dei form?

[vaitrafra]

stai vedendo la luce fratello!

chiariscimi un po' la struttura del programma...usi un sub main?

[calabar]

Diciamo che siamo vicini ad una stesura funzionale.

La descrizione è abbastanza semplice: un MDIForm e 4 form child, più altri due non child, e un modulo bas, che ho chiamato Glo, con funzioni pubbliche e variabili globali.
Il form MDI viene caricato per primo, quindi nella sua load richiama una sub di Glo chiamata Inizialize: questa setta i valori di alcune variabili e tramite la sub setDBConnections assegna i dati di connessione degli adodc (il problema di questo topic, insomma) e quindi lancia la sub Restore, che ripristina il programma in caso di crash o chiusura improvvisa.
Subito dopo il load dell'MDIForm richiama un'altra sub, MenuSwitch, che gestisce la visualizzazione dei form dentro l'MDI.

La cosa che mi hai detto però mi ha fatto drizzare le orecchie.
Purtroppo non ho avuto un approccio molto formale a VB6, quindi regna sovrana la tecnica dell'arrangio e la lettura sporadica da manuale e msdn.
Non ho mai utilizzato un "main" stile C, ti va di dire due parole a riguardo?
Finora ho sempre subito VB6 in termini di caricamento dei moduli.

Se non ti stresso troppo, vorrei chiederti anche due altre piccole cose:
- le scrollbar (nel mio caso dei controlli datagrid con cui visualizzo i dati del DB) non rispettano le proporzioni tra testo visualizzato e testo totale del controllo. C'è un modo per ottenere questo effetto o è un difetto intrinseco irrisolvibile dei controlli di VB6?
- Nel passaggio tra un form child all'altro all'interno dell'MDI, si ha un effetto sfarfallio, come se il form interno fosse piccolo e venisse ingrandito fino alla posizine di maximized (cosa che io stesso ho impostato). Ho provato anche a settare la visibilità del form a false durante il passaggio (trucco che funziona benissimo per evitare lo sfarfallio nei datagrid nella lettura riga per riga), ma senza risultato.
Conosci qualche barbatrucco per evitare il problema?

[vaitrafra]

dunque:

La sub main è una sub particolare che è molto pratica quando la tua applicazione necessita di un caricamento selettivo delle form allo startup in base a dei parametri memorizzati in qualche file di configurazione, nel registro o in un database. Per il tuo problema comunque non è necessaria.

Riguardo allo sfarfallio dei form MDI direi che è dovuto alle animazioni delle fnestre di windows, ma magari mi sbaglio...
Per controllare prova questo
-Tasto dx su risorse del computer -> proprietà
-seleziona il tab Avanzate
-nel frame Prestazioni clicca il bottone "impostazioni"
-Togli la spunta dalla voce "Anima le finestre quando vengono ingrandite o ridotte ad icona"
-Apllica

Ripeto, non ne sono assolutamente sicuro, è una prova.
Altra cosa che potresti provare è inserire il codice di preparazione dei controlli delle form MDIChild nel loro evento load e poi richiamare i form in questa maniera

Load frmMdiChild1
DoEvents
FrmMDIChild1.show

vedi msdn per i dettagli su DoEvents.

Per le scrollbars non ti so aiutare, credo cmq che ci sia poco da fare a meno di non usar una qualche api.

Per risolvere il problma principale del topic fai così
fai partire il progetto dal form che usi per immettere nomeutente e password.

nell'evento click del tasto di conferma nomeutente e pwd tu setti due variabili a livello di modulo
nel modulo

dim user, password as string

nell'evento click del tasto di conferma

Private Sub cmdConnect_click(button as integer ...)
        password= txtpassword.Text
        user= txtUsername.Text
        LOAD frmMDIParent
        frmMDIParent.Show
        Unload Me                 'questo distrugge la form di inserimento password.
End Sub

nella load del form MDI padre, prima di fare qualsiasi altra cosa setti la tua strnga di connessione con password e utente recuperati dalle variabili locali

adodc.connectionString= "stringaJETsolita user="& user & " password=" & password

poi puoi riprendere la normale esecuzione del programma che hai già scritto.

L'ultimissimo consiglio che ti voglio dare è di provare a studiarti (online trovi miliardi di articoli) la gestione dei database tramite ADO (recordsets). E' un po' più macchinosa se vuoi, ma ti consente un controllo (quasi) completo su ogni aspetto riguardante i dati dei tuoi programmi.

[calabar]

Ok, molto esauriente.

Per la sub main, puoi dirmi velocemente come crearla? (immagino che ci sia una pocedura particolare...)

Per l'animazione delle finestre, è disattivata. Non è quello.
Il caricamento dei child è gestito da una funzione di Glo chiamata MenuSwitch. Nel tuo codice c'è "DoEvents", di cui non sono sicuro di cogliere il significato: una volta che il form è caricato, non dovrebbe automaticamente verificarsi l'evento load? DoEvents che fa quindi?
Da notare che una volta caricati, i form, non vengono buttati giù se non visualizzati, ma solo nascosti e visualizzati tramite le proprietà hide e show, generando un evento activate.
PS: ho guardato le msdn, mi dice che restituisce un intero indicativo del numero di form aperti e passa il controllo (di cosa?!?) al sistema operativo

Per la gestione con ADO, l'ho già studiata
Ma in effetti il fatto che fosse macchinosa ha fatto si che non la usassi mai (non per pigrizia, ma perchè all'esame il tempo era limitato!), e ora mi sono abituato con l'adodc.
Non dovrei avere difficoltà ad usare l'ado, ma questo programma è ormai al termine, cambiarlo ora sarebbe troppo lavoro. Magari in una versione futura...

Grazie davvero per tutti i consigli.
A buon rendere, se sarà possibile!

[vaitrafra]

allora, doevents non è altro che una chiamata al SO per far si che windows abbia la possibilità di aggiornare e ridisegnare le finestre della tua app(e non solo) prima che il flusso della stessa riprenda.

Quindi, quando fai operazioni molto lunghe e dispendiose di risorse un doevents non guasta mai, per far si che la tu app sia "più Sveglia". Questo esiste in VB6 perchè non ha la gestione dei thread.

La sub main puoi crearla semplicemente dichiarando

Public Sub Main()

End sub

poi vai in progetto->proprietà selezioni sub Main dalla combo oggetto di avvio(dovrebbe essere, io in inglese ho Startup Object)

per il load... Quando fai

Load from1

viene caricata in memoria la form specificata, eseguito l'evento Load della form e poi questa rimane inattiva finchè non richiami manualmente il metodo Show della form che scatena un evento Activate. Se piazzi un Doevents tra la load e lo show, sei più sicuro chela tua form venga caricata completamente prima che venga visualizzata... questo no è sempre vero in vb6 comunque perchè ci sono casi particolari dove l'evento show viene gestito da sistema operativo prima che la form sia completamente caricata in memoria(e quando succede si vedono i classici buchi al posto dei controlli).


zià

[calabar]

Forse ho risolto il problema dello sfarfallio.
Al richiamo di FormX.show (X sta per un numero qualsiasi di form), VB visualizzava a volte il form child in oggetto correttamente massimizzato, come da impostazione, e volte rimpicciolito (e per giunta molto più piccolo comunque della dimensione impostata quando non massimizzato), in maniera del tutto casuale.
Per rimediare a questo, dopo la visualizzazione, imponevo la massimizzazione, e da qui lo sfarfallio.

Ora, imponendo la massimizzazione PRIMA della visualizzazione, pare non sfarfallare più!
Non che la cosa mi rassicuri, devo ammettere che la massimizzazione successiva alla visualizzazione mi dava più garanzie, ma dopo qualche test pare che anche in questo modo funzioni bene e non visualizzi mai mai la finestra non massimizzata.

Direi che con questo la versione utilizzabile è pronta

Grazie ancora del supporto!



PS: quindi la sub main non è un vero costrutto di VB, ma praticamente una sub che io decido di far caricare per prima (anche da me lo chiama "startup object" mmm... credo di avere l'ambiente di sviluppo in inglese!). Insomma, volendo potrei creare un modulo qualunque e dare quello come startup object, giusto?