Newsgroup: it.comp.lang.visual-basic
Titolo: Come dialogare tra EXE autonomi?

Salve a tutti.
Qualcuno di voi sa darmi qualche dritta sul seguente problema?
Nel vecchio GWBASIC, QBASIC, QUICKBASIC la parolina CHAIN aveva la magica
capacità di caricare e passare il controllo ad un altro programma (.BAS o
.EXE). Fin quì niente di nuovo, riesco a farle lo stesso in VB con
l'istuzione SHELL. Ma la "potenza" del vecchio basic era quella di riuscire
a passare i valori correnti delle variabili tra un programma e l'altro
(purchè allineate), cosa che VB non mi pare riesca a fare.
Ora, supponiamo di voler sviluppare un applicativo a più moduli; ogni modulo
è autonomo e funzionante indipendentemente dagli altri, ma se sente la
presenza di un altro modulo riesce a interagire con questo. Questo può
essere utile, ad esempio, per lo sviluppo di un programma complesso, quale
può essere un gestionale.
L'idea dovrebbe essere quella di sviluppare un modulo per l'anagrafica
clienti, fornitori, articoli, magazzino, contabilità, scadenziario,
pagamenti, fatturazione, statistiche, ecc...  Ecco che allora l'applicazione
può essere costruita su misura: vengono installati solo i moduli
strettamente necessari e se un domani voglio aggiungere qualche modulo non
faccio altro che installare l'eseguibile di quel modulo (e non ricompilare
un nuovo applicativo contenente quel modulo) e, dato che il sistema è
completamente integrato, riuscirà a "sentirlo" ed utilizzarlo correttamente.
Il problema sta principalmente sul fatto di far dialogare i moduli l'un con
l'altro. Una delle problematiche può essere questa:
- viene lanciata l'applicazione
- parte il modulo di richiesta username e password (ad ogni utente viengono
assegnati certi diritti di utilizzo)
- se l'utente "pippo" non ha il diritto di utilizzare il modulo
"statistiche", tale modulo deve essere a conoscenza dell'utente che ha fatto
il login, per impedire o consentire l'utilizzo del modulo stesso. Nel caso
di unico progetto a più form basterebbe utilizzare a livello di modulo
dichiarazioni l'istruzione <GLOBAL sUtente as String> per condividere a
tutto il progetto il valore contenuto nella variabile sUtente, ma qui stiamo
parlando di EXE autonomi. La soluzione potrebbe essere quella di utilizzare
un file INI di scambio ma... fa abbastanza schifo. Forse usare il DDE... un
po' complesso; ed in rete? Tutte le speranze cadono quando bisogna
utilizzare un DB. COME SI FA A CREARE UN RECORDSET IN UN APPLICATIVO E
PASSARE TALE RECORDSET AD UN ALTRO APPLICATIVO? Far aprire il DB da ogni
applicativo non mi sembra la soluzione corretta visto che vi sarebbero
accessi multipli sulla stessa macchina sommati agli accessi delle macchine
in rete...
Credo che questo problema, o tecnica, sia chiamata SCALABILITA', ma non mi
pare che VB la supporti. Qualche dritta?

 ...............

vaditità delle soluzioni)...

"componente aziendale"?
Dunque... se ho ben capito quello che cerchi di realizzare tu è una cosa sul
genere degli add-ins di VB o dei plug-ins di Netscape. Cioè la possibilità
di aggiungere nuove funzioni o diversificare il tipo di installazione del
tuo programma senza dover ricreare l'EXE.
NB: plug-ins e add-ins sono cose differenti.
 Entrambi solitamente risiedono in una DLL ma sono sostanzialmente
differenti.
 Un plug-in serve per aggiungere funzionalità a un programma ma rimane cmq
un corpo estraneo ad esso. Il punto di contatto è tutto nella linea di
comando con cui viene invocato. Serve quindi più come back-door al
programmatore che ha realizzato l'applicazione per potervi rientrare a suo
piacimento.
Un add-in, invece, è qualcosa che consente, per costruzione, a tutti di
modificare a piacimento il programma intervenendo in tutto il suo spazio e
accedendo a tutti i suoi oggetti. Un add-in si fonde con il programma come
se ne fosse una parte originale. Un add-in richiede la presenza di un
modello a oggetti sottostante.
Per maggiori informazioni ti consiglio di procurarti il N°70 di Computer
Programming (Giugno 98) dove c'è un articolo di Dino Esposito che tratta
l'argomento. Il titolo dell'articolo è "Programmi estendibili attraverso
moduli plug-in" e principalmente tratta la realizzazione di plug-ins. Cmq
nello stesso numero trovi pure un articolo sulla creazione di add-ins per
VB5, Quindi puoi prendere spunti anche da quest'ultimo articolo.
Il sito internet di Computer Programming è :  
http://www.infomedia.it
Zeross

Ti dico in sintesi cosa di solito faccio:
Supponiamo che in una applicazione vi sia una anagrafica Clienti, io creo un
modulo di classe che chiamoOBClienti con le proprità per es:
Codice,
Ragione sociale
PIva
Via
Comune


L'architettura da utilizzare dipende da molti fattori.
Nel tuo caso, a mio parere, l'architettura 3-tier (a 3 livelli concettuali,
non fisici: data, business, user) e' la piu' flessibile e permette futuri
sviluppi.
Non e' necessario che i 3 livelli concettuali corrispondano a 3 livelli
fisici, ossia non e' obbligatorio che i data objects siano su un DB server,
i business objects su un "business" server e gli user objects sui client.
Anzi, addirittura e' possibile raggruppare piu' livelli in un modulo fisico.
Chiaramente per modulo fisico stiamo parlando di ActiveX EXE (server di
automazione OLE).
Nel tuo caso specifica e' probabile che il design possa essere un "cluster"
(grappolo) di ActiveX EXE inter-comunicanti (come lo sono gli applicativi di
M$ Office: Word, Excel, Access, Outlook,...).
A questo punto le possibilita' sono:
1) NO Client/Server:
ogni ActiveX EXE contiene tutti (o quasi) i livelli concettuali (data
objects, business objects, user objects).
Soluzione attuabile se l'applicazione deve funzionare prevalentemente in
locale (sul client).
2) Client/Server:
i livelli 3-tier sono separati e suddivisi fisicamente in moduli ActiveX
(EXE o DLL).
In questo modo e possibile avere i business objects raccolti in uno o piu'
moduli ActiveX installati sul server, e accessibili da ogni client.
Nell'architettura C/S descritta i client comunicano con i moduli ActiveX
server tramite DCOM (Distributed COM).
Per ulteriori informazioni, se hai VB enterprise trovi una descrizione
concettuale del design C/S sui books on-line.
--
Roal Zanazzi
z...@iol.it

Rispedisco:


>Salve


caratteristica non supportata da VB professional).
Tempo fa qualcuno su questo NG diceva che e' possibile anche con la
professional, se ti interessa cerco il msg.
--
Roal Zanazzi
z...@iol.it


Guarda,
se il tuo problema è semplicemente quello di scrivere un gestionale
modulare in tempi finiti ti dico come ho fatto io.
Ho creato un solo exe che contiene tutti i moduli. In questo modo
sparisce la maggior parte dei tuoi problemi. Poi, per dare ad ogni
cliente solo quello per cui ha pagato, ho strutturato i numeri di
serie in modo che contengano implicitamente i moduli da attivare.
Quando un utente installa il programma deve specificare un numero di
serie che fornisco io. In base al numero di serie digitato
all'installazione il programma povvede a nascondere i moduli che non
sono stati comprati.
In questo modo quando il cliente compra altri moduli basta dargli un
nuovo numero di serie.
Lo so che avventurarsi nel mondo COM e ActiveX è più sexy, ma vedo
meglio questa soluzione per la gestione di archivi tramite siti WEB,
dove tutti questi accrocchi girano in un ambiente controllato e
monitorato da personale competente.
Far girare i programmi sulle macchine dei clienti che combinano ogni
genere di porcata è un altro paio di maniche. Ho già problemi con il
mio approccio, credo che una soluzione basata su componenti ActiveX
non sarebbe abbastanza robusta per sopravvivere ai barbari che devono
usare il programma.
Ciao
--------------------------------------------------------------------
Fulvio Senore
Eliminate "zz" dall'indirizzo e-mail per scrivermi (spammers...)
Remove "zz" from e-mail address to write me (spammers...)
--------------------------------------------------------------------

caratteristica non supportata da VB professional).
Tempo fa qualcuno su questo NG diceva che e' possibile anche con la
professional, se ti interessa cerco il msg.
ilizza
RE:---------------------------
Grazie ma uso l'Enterprise!
--

Custom Control.
E probabilmente in molti casi e' piu' performante rispetto all'uso di
collections.
--
Roal Zanazzi
z...@iol.it