Newsgroup: it.comp.lang.visual-basic
Titolo: with multiplo

Salve, ho un piccolo quesito:
ho un form1 con grid e form2 con grid; in un modulo, una funzione mi nomina 
e dimensiona le celle della grid; ora mi chiedevo se con una unica funzione 
si poteva gestire le due grid, a seconda di cio' che sta a video :
    	with nomeform.grid
    	     qui creo la struttura della griglia
    	end with
 
quindi, sempre usando le stesse righe, gestire le grid dei due form, senza 
dover ripetere la procedura....spero di essere stato chiaro..
Grazie

 ha scritto nel messaggio
news:Xns92C49D726...@195.31.190.132...

Public Sub Crea_Struttura(byref Griglia as Object)
     with griglia
          qui creo la struttura della griglia
     end with
End Sub
Dalle form:
Call Crea_Struttura(form1.Griglia1)
o
Call Crea_Struttura(form2.Griglia1)
Ciao
Alberto

 si poteva gestire le due grid, a seconda di cio' che sta a video :
cosě, al volo....
potresti fare una sub pubblica del tipo
sub sistemacampi (griglia as object)
    griglia.columns(0).caption =
......
end sub
e poi, da ciascuna form che ti interessa la richiami passandogli la grid in
questione
ps: ho utilizzato as object perchč non mi ricordo il nome della classe del
controllo, sarebbe opportuno sostituirlo con il tipo adatto.....
Salutoni
Sergio

 controllo, sarebbe opportuno sostituirlo con il tipo adatto.....
Pensa che invece io nelle mie sub pubbliche faccio il possibile per usare
Object (anzi, sviluppo con il tipo giusto, per avere l'intellisense, poi
commento e scrivo Object).
Così, posso spostare un modulo che contiene 50 Sub o Function da un progetto
ad un altro, senza dover inserire riferimenti e componenti che non mi
servano direttamente.
ciao
Alberto

 commento e scrivo Object).
Lungi da me l'intenzione di aprire polemiche religiose sull'utilizzo del
late binding o dell'early (posto che si scriva così), vorrei però provare ad
approfondire l'argomento.
Diamo per scontato che l'early binding produce codice compilato più compatto
e performante (o, almeno, così sta scritto nei pochi testi che ho letto).
Vorrei capire i vantaggi che ritieni di ottenere dal tuo approccio. Mi
spiego meglio (ci provo)
Se faccio un codice utilizzando le proprietà e i metodi specifici di un
controllo (ed è quello che mi sembra faccia anche tu, visto che usi
l'intellisense), che vantaggio ne ho a usare poi il late binding?
Salutoni
Sergio

 l'intellisense), che vantaggio ne ho a usare poi il late binding?
Bella discussione.
Vediamo di esplicitare i miei profondi pensieri:
1) Massima riusabilità del codice
2) Bassa ridondanza e duplicazione di moduli di codice
Quindi, se ho 3 progetti VBP che devono accedere a funzioni comuni (caso
classico è il calcolo del checksum dei codici prodotto, che ovviamente deve
essere la stessa function per tutti gli applicativi per uno stesso cliente),
metto le funzioni condivise in un modulo BAS, e lo inserisco in tutti i tre
progetti (eventualmente lo metto in sola lettura, così sto anche tranquillo
che per modificarne il contenuto devono chiedere a me).
A questo punto mi trovo un bel modulone BAs, con dentro 50 function e sub,
visibile da 3 progetti diversi.
Diciamo che il 60% delle funzioni è acceduto da tutti i 3 progetti, mentre
un restante 40% è utilizzato solo da due o uno dei tre progetti.
Viceversa, però, alcune delle funzioni accedute da solo uno o due dei
progetti, utilizzano a loro volta alcune delle funzioni comuni.
Problema:
Se utilizzo una dichiarazione di variabile o parametro utilizzando una
classe specifica (ad esempio di ADO, o un controllo come il DataGrid,
MSCOMM, ecc...), devo avere in tutti i progetti il riferimento alla
libreria/componente.
Ma se uno dei progetti non usa la seriale, perchè dovrei mettere in un form
un MSComm32.Ocx?
E se un progetto non usa Excel, perchè dovrei mettere Excel9.Olb?
Soluzione:
Dopo aver creato, testato e approvato le function, commento le dichiarazioni
con le classi (Early Binding), e metto dei bei As Object.
Conclusione:
Tutti i 3 progetti compilano regolarmente.
Alcuni di essi avranno, compilate ma non utilizzate, funzioni o sub che sono
state fatte per gli altri, ma stiamo parlando di 50k di differenza, a fronte
di una comodità ed una flessibilità operativa non indifferente.
Per quanto riguarda le performance, in realtà ho fatto alcune prove proprio
con il DataGrid (ho una funzione che imposta la larghezza delle colonne
sulla base del tipo del Field del Recordset), chiamandola 1000 volte con
l'Early e 1000 volte con il Late binding.
I risultati sono stati contrastanti, nel senso che a seconda che il sistema
fosse più o meno 'in forma', a volte ha vinto uno e a volte ha vinto
l'altro, per cui credo che nel complesso non ci siano grosse differenze.
E' però evidente che occorre prestare attenzione al debug, perchè se un
oggetto viene utilizzato dentro un IF, potrebbero passare 1000 test senza
che sia usato, e appena arriva dal cliente chiaramente entra nell'IF.
Ciao
Alberto

[Albe V°]
(snip totale)
Direi che la filosofia è condivisibile.
Adesso attendo con fiducia che qualcuno faccia osservazioni opposte,
spiegando (ipotizzo) come in realtà sia cattiva politica mettere riferimenti
ado oggetti nelle routine condivise, e che debbano essere le routine
chiamanti a risolvere il problema passando solo tipi di dati "intrinseci".
(ripeto per chiarezza: la frase sopra riportata è stata generata in modo
assolutamente casuale, non è una seria ipotesi di lavoro)
è che se il thread si ferma qui un lurkatore accanito e curioso come me si
trova a corto di spunti....
Salutoni
Sergio

> 2) Bassa ridondanza e duplicazione di moduli di codice
Idem come 1. Se inserisco un modulo per ogni routine o un modulo con tutte
le routine, _non_ c'e' ridondanza: il numero delle routine e' lo stesso,
semmai la comodita' e' nel non "dover scegliere" gli eventuali opportuni
moduli, ma inserire il "pacchetto" bello e pronto (quella che Albe definisce
bassa duplicazione di moduli di codice).
Ma e' una comodita' di facciata: il late binding puo' creare tanti problemi
con il debug, conflitti di versione (magari il codice nel modulo BAS e'
scritto usando i riferimenti a Office 9.0 e non funziona piu' con i
riferimenti a Office 10.0). In particolare il "calderone" delle routine non
permette una facile manutenzione in caso di aggiornamenti (ad es. se
cambiano le costanti, gli enumerati, i parametri di alcuni metodi ecc.)
perche' bisogna andare a pescare nel marasma tutte le routine che si
appoggiavano a tali riferimenti e a tali "valori".
Le routine andrebbero separate in "camere stagne" (moduli BAS) a seconda dei
riferimenti e/o del tipo di operazioni che effettuano. E se esistono
funzioni "base" comuni a piu' moduli (leggi funzioni "matematiche" o
algoritmi come checksum e affini, indipendenti da riferimenti particolari)
queste andrebbero isolate ed inserite in un "core" comune a tutti gli altri
moduli.
Ho bisogno di lettore codice a barre con controllo checksum e accesso a db?
Inserisco nel progetto AlbeCore.BAS, AlbeBarcode.BAS ed AlbeDB.BAS,
tralasciando AlbeOffice9.BAS (o meglio AlbeWord9.BAS e affini ;) ),
AlbeWinsock.BAS e quant'altro!
L'early binding permette, fra l'altro, di sfruttare gli enumerati e le
costanti caratteristici della libreria "riferita" che *possono*
(ms-permettendo) rimanere invariati anche da versione a versione, cosa che
con alta probabilita' non accade con il *valore* dei medesimi
enumerati/costanti. Inoltre l'early binding, permette di scovare errori
anche ad una prima compilazione (sempre valido l'esempio dei riferimenti a
Office9.0 e 10.0), cosa che non accade con il late binding.
Perdonate la lungaggine, ovviamente il tutto e' da intendersi IMO:
just my 2 euro-cents ;)
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

 [CSSoft]
Direi che la filosofia è condivisibile.
[Lokar]
Io direi di no :p
(snippone galattico)
Grazie a Lokar per aver raccolto l'invito.....
Sarà banale dirlo, ma ritengo che confrontare i diversi punti di vista sia
cosa più bella del NG, quando poi le posizioni sono espresse senza accusare
gli avversari di tutti i mali del mondo ed efficacemente argomentate è un
vero piacere.
Salutoni
Sergio

 Perdonate la lungaggine, ovviamente il tutto e' da intendersi IMO:
Tutto valido e condivisibile.
Ognuno dà un peso ad un vantaggio ed un peso ad uno svantaggio. Poi decide.
Effettivamente, la problematica del debug 'ad alto rischio' l'avevo
evidenziata anche io.
Il non poter utilizzare le enumerazioni delle librerie è un problema serio.
Se devo dire la verità, diciamo che anche io ho alcuni moduli che svolgono
solo poche cose, diciamo moduli molto specializzati, in cui ovviamente
utilizzo l'Early Binding, proprio per poter utilizzare le costanti delle
librerie.
Per il resto, trovo molto comodo avere un modulo "funzioni_ClienteX", a cui
tutti i progetti per lo stesso cliente si appoggiano. Per poter usare
l'early binding, dovrei avere due moduli, ad esempio
"funzioni_ClienteX_Per_Excel" e "funzioni_ClienteX_Per_Seriale". Niente di
male in questo, ma a volte funzioni (generiche, non che utilizzano Excel
direttamente) sviluppate per supportare attività relative a Excel, mi
servono anche nella gestione della seriale (formattazione di stringhe,
checksum, ecc...), per cui a questo punto dovrei aggiungere un terzo modulo
"funzioni_clienteX_Generiche", inserito in entrambi i progetti. Anche
stavolta niente di male, anzi, Lokar lo considera un modo per mantenere
l'ordine, e in parte avrebbe anche ragione.
Ma a questo punto diventa una questione di punti di vista.
Ciao
Alberto

 2) Bassa ridondanza e duplicazione di moduli di codice
[SNIP]
Lo scopo e' condivisibile... pero', il late binding, l'intellisense,
l'overhead di codice compilato nonche' la necessita' di fare debug
articolati (metti la classe, prova, togli la classe e metti object) e' un
prezzo che puoi fare a meno di pagare, con qualche accorgimento in piu'.
Alcune di queste cose, qui da noi, le abbiamo maturate nel passare a suo
tempo da VB3/4 al 5/6, altre piu' recentemente, ma il vantaggio e'
avvertibile, quindi, se posso permettermi, ecco un paio di dritte
(naturalmente, tutto da considerarsi "IMHO")...
Innanzi tutto, il "bel modulone Bas", non e' quasi mai la soluzione migliore
a livello di organizzazione; una strada preferibile e' quella di creare un
repository comune a *tutti* i tuoi progetti, per esempio sotto forma di
banale cartella condivisa, isolato dal resto dei sorgenti. Qui puoi
mantenere il tuo set di moduli riutilizzabili; bas, cls o altro ha poca
importanza, quello che serve pero' e' che siano ben organizzati per
argomenti, anche a costo di averne un numero elevato... ora, sono convinto
che tu non intendessi veramente UN modulo, comunque io sto parlando di
qualcosa tipo 15/20 moduli, ciascuno per quanto possibile indipendente
dall'altro, o quantomeno cercando di isolare un "core" di funzioni da cui
non possono prescindere tutti gli altri, e separando il resto.
Il fastidio di aggiungere parecchi moduli a ogni progetto e' irrisorsio
rispetto al vantaggio di poter includere solo quello che davvero ti serve; e
lo scopo non e' cosi' difficile da raggiungere se ti basi sui vari aspetti
applicativi (database/interfaccia utente/file system ecc.)
Un'altra cosa da non sottovalutare, quando vuoi svincolare un'applicativo
dai riferimenti a librerie esterne, sono le variabili di compilazione
condizionale: riprendendo il tuo esempio relativo a Excel9.Olb, che abbiamo
sperimentato di persona, considera ad esempio un approccio del genere:
#If LATEBINDING Then
Private Function FunzioneSuExcel(ex As Object) As Object
    Dim WBook    As Object
    'replichiamo le costanti definite nella libreria di Excel
    Const xlAlignCenter = -4108
    Const xlAlignLeft = -4131
#Else
Private Function FunzioneSuExcel(ex As Excel.Application) As Excel.Worksheet
    Dim WBook    As Excel.Workbook
    'qui le costanti non sono necessarie, in quanto definite
#End If
'[corpo della funzione]
End Function
in questo caso, ottieni qualcosa di simile a quello che gia' fai, ma con due
grossi vantaggi:
- non sei costretto a modificare tutto il codice in fase di test, per
cambiare i tipi di dato.
- sei libero si decidere se utilizzare o meno l'early binding *a livello di
singola applicazione*, di nuovo senza dover toccare una riga del codice
condiviso.
Tutto questo semplicemente modificando la singola costante LATEBINDING nelle
proprieta' dei progetti...
Considera infine, relativamente alle classi, la definizione di interfacce
per sfruttare il polimorfismo: avere una funzione X con tipi Object che si
pensa di applicare a casi diversi vuole sempre dire, implicitamente,
aspettarsi che tutti i possibili oggetti abbiano quelle determinate
proprieta'/metodi in comune, e fatti in un certo modo... a questo punto
isola questi elementi comuni, fanne una classe interfaccia e implementala in
tutte le classi che ti servono; nelle funzioni comuni lavora con la classe
interfaccia invece che con Object, e riguadagnerai early binding,
intellisense, errori in compilazione e non piu' in esecuzione ecc.
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 l'ordine, e in parte avrebbe anche ragione.
Francamente sì.    :-P
Se le funzioni in oggetto sono "generiche funzioni di gestione stringhe",
allora devono stare in un "generico modulo dedicato alle stringhe", non
nel "modulo dedicato ad excel" nè nel "modulo dedicato alla seriale"...
...senza nulla togliere agli obbiettivi inizali di riusabilità del codice,
bassa ridondanza e duplicazione di moduli.
...il resto è già stato detto da Lokar e Luca.
ciao
ugo

 vero piacere.
Cosa dire se non che sono pienamente daccordo ?
Specialmente per chi "usacchiava" il visual basic come me , leggendo questi
3ad si riesce ad avere una visione globale del classico "no, non si puo' "
oppure del "Vai tranquillo cosi.."
3ad cosi sono stupendi !

 ...il resto è già stato detto da Lokar e Luca.
umm da esterno potrei dire che la risposta definitiva sta come al solito nel
mezzo ^_^
1) creare dei moduli + specializzati possibili (seriale.bas report.bas
ecc.. )
2) creare una cartella con dentro tutte le funzioni generiche possibili
organizzate sempre con il metodo della specializzazione  tipo :
GENERICA_stringhe.bas GENERICA_hook_mouse.bas GENERICA_hook_keyb.bas ecc.. )
tanto non credo "cambi qualcosa" nell'importare 1 modulo generale immenso o
20moduletti che insieme formano il "modulo generale" , parlo di "cambiamenti
pericolosi" a livello di perdite di dati o perdite di moduli.bas .
certo che e' un po stressante cercare i moduletti generali che mi servono
per ogni programma, pero' e' molto meglio dell'importare 1 supermodulo con
l'utilizzo del 20% delle func e sub contenute in essa rischiando di
incappare in errori di riferimenti di cui 1 non si ricorda nemmeno il
perche' !
pro:
manutentibilita' elevata del codice , lasciando alle form solo lo stretto
necessario e avere organizzato in modo pignolo tutti i moduli di cui abbiamo
bisogno.
contro:
impossibilita' di usare chiamate incrociate nei vari moduletti generali e
rischiare di riscrivere 10 volte nel form o in un altro modulo aggiuntivo le
varie chiamate incrociate
credo che sia ora che inizi a farmi questa benedetta cartella aggiungendo
che, come al solito , ogni programmatore se le organizza in maniera
OGGETTIVA.

 applicativi (database/interfaccia utente/file system ecc.)
[snippone]
[autocompiacimento = true]
evvai , da perfetto niubbetto vedo che quello che ho appreso e elaborato dal
3ad e' lo stesso procedimento che usate voi , bello , e' soddisfacente
vedere che a volte navigo nella direzione gusta.
cmq l'aggiunta del if per il late o l'early binding e' ancora + semplice di
quello a cui pensavo.