\nuovoarticolo{Rocco Coluccelli}{The OLE System v1.0 \\ Objects Links Exchanged \\ (Scambio di Oggetti e Collegamenti)}{}{} \subsection{Introduzione} Tutti gli utenti "progrediti" di Amiga sanno che questa favolosa macchina può essere programmata a vari livelli. Mi spiego meglio, a partire dal linguaggio Assembly, tralasciando i sottolivelli di microprogrammazione hardware, si possono identificare tanti livelli di programmazione, sempre più evoluti e specializzati. Ad esempio i linguaggi C, C++ e tutti i linguaggi compilati richiedono, da parte del programmatore un impegno inferiore a quello dovuto per l'Assembler, ma restano "inavvicinabili" per tanti utenti "normali". Su altre piattaforme il livello successivo è costituito dagli applicativi che l'utente usa e configura (leggi "programma") per le sue necessità. Un livello intermedio potrebbe essere quello della programmazione batch, con applicabilità limitate a determinati ambiti (AmigaDOS generalmente). Ritorniamo al livello superiore, alcuni applicativi sono dotati della possibilità di registrare delle macro. Questo aggiunge già delle possibilità per l'utente che può così crearsi piccoli insiemi di funzioni specializzate. Le macro hanno però l'inconveniente di essere confinate nell'applicativo che le ha generate. Ed arriviamo finalmente all'anello mancante, qualcosa che fosse sufficientemente potente, flessibile ed assolutamente semplice: AREXX Non starò adesso a tessere le lodi di questo linguaggio di programmazione, che tutti dovrebbero già conoscere, dirò semplicemente che mi ha permesso di creare applicazioni delle più diverse, con estrema semplicità. IL CONCETTO L'idea nacque osservando le OLE di Windows, ricordando le hot-links di Pagestream v2.22 e alcuni script di Professional Page v4.0. Mi ero avvicinato da poco alla programmazione con ARexx, ma tanto da comprenderne le sconfinate potenzialità. Dopo aver steso alcuni script per Cygnus EDitor, provai il programma Final Writer e scrissi due semplici funzioni per l'allineamento di più oggetti, come già presenti in PageStream. La facilità con cui si potevano aggiungere nuove funzioni a Final Writer grazie ad ARexx mi spinse verso un progetto più ambizioso: uno script per importare una tabella da Professional Calc all'interno di Final Writer conservandone gli attributi. Il progetto divenne più interessante quando cominciai a provare le funzioni di altre librerie per ARexx (rexxsupp.library, rexxarplib.library, etc.). OLE System nasce quando cominciai a pensare ad uno script analogo per PageStream v3.0. La sezione che leggeva i dati da Professional Calc sarebbe stata la medesima: perchè allora scriverla tante volte ? Inoltre tutti i moduli dovevano avere la medesima interfaccia e allora, perchè non raccogliere le funzioni comuni in un solo modulo ? Ecco finalmente la struttura alla base di OLE System. L'utente, usando un applicativo, esegue dal suo interno uno script ARexx per svolgere una determinata funzione. Questo altri non è che il modulo di partenza che chiama, in modo trasparente all'utente, OLE Server indicandogli l'applicativo chiamante e i successivi moduli da lanciare. Da questo momento in poi il controllo passa ad OLE Server che inizializza ed esegue i moduli richiesti. Questi ultimi realizzano materialmente la funzione richiesta dall'utente. Gli script per importare tabelle da Professional Calc all'interno di un altro applicativo cambieranno solo nel modulo che realizza la scrittura della tabella nel programma chiamante. Ciò rende più semplice l'aggiornamento degli script. La modularità di OLE System porta anche ad una standardizzazione nella scrittura di nuovi moduli che di fatto conservano la medesima struttura interna. LOCALIZZAZIONE Tutti i programmi scritti per OLE System sono localizzabili. Il metodo adottato non fa uso della "locale.library" per dare la possibilità a ciascun utente di personalizzare i messaggi della sua interfaccia usando un comune editor di testi. I files che contengono la traduzione dei messaggi di ciascun programma nelle varie lingue hanno una struttura molto vicina a quella standard. Si parte da un file sorgente, uno per ciascun modulo di OLE System, che contiene tutti i messaggi in tutte le lingue che si desiderano. Ogni file sorgente deve avere il medesimo nome del programma cui si riferisce con il suffisso ".ct" aggiunto alla fine (il catalogo sorgente per il programma "OLE.rexx" sarà quindi "OLE.rexx.ct"). Questi files sono tipicamente raccolti nel cassetto "OLE:Misc", ma possono trovarsi ovunque. Il compilatore di cataloghi inserito nel programma di configurazione di OLE System provvederà a creare un file di localizzazione per ciascun linguaggio inserito nel documento sorgente. Questi files, che cambiano il suffisso in ".catalog", verranno automaticamente suddivisi e copiati nelle directory appositamente create per ciascun linguaggio. Il compilatore sovrascrive i vecchi cataloghi automaticamente. Segue una descrizione del formato adottato per i sorgenti dei cataloghi: ; questo è un commento, con ";" in prima posizione nella linea ## language ; comincia un nuovo catalogo per il linguaggio "language" ; language = italiano, english, deutsch, ... # ID ; così inizia la definizione di un nuovo messaggio, ; "ID" deve essere una stringa priva di spazi. ; ; NON USARE CARATTERI DI TABULAZIONE ; NON USARE VIRGOLETTE Se preceduto da una linea "ID" valida, questo è un messaggio valido che può essere diviso su più linee e il compilatore ; ; commenti possono essere aggiunti nel mezzo di un messaggio, ; saranno comunque ignorati dal compilatore. ; ne conserva la struttura senza concatenarle. # ; così termina la definizione di un messaggio valido ; le linee vuote vengono ignorate, ; se poste al di fuori di un messaggio valido ## ; ; così termina la sezione dedicata ad un particolare linguaggio ; Onde evitare errori con le funzioni di visualizzazione, il compilatore opera alcune sostituzioni nell'ambito di ciascun messaggio: ogni linea viene terminata dal carattere "\" il carattere "'" viene sostituito con "´" la virgola "," viene rimpiazzata da "¸" Al termine della compilazione, ciascun messaggio ha questa struttura: þIDþ messaggioÞ Per ciascun linguaggio, tutti i messaggi vengono concatenati in una unica linea che viene salvata come file catalogo. OLE SERVER Descrivo adesso la struttura del fulcro su cui poggia tutto OLE System: OLE Server. Torno a ripetere concetti esposti prima perchè li ritengo fondamentali. Come ho detto, l'utente non chiama direttamente OLE Server, ma esegue uno script, come fosse una macro, dall'applicativo che sta usando in quel momento. Questo script inizializza l'ambiente operativo dei successivi moduli (porta ARexx dell'applicativo, schermo in cui si trova l'utente, moduli da lanciare) e lancia in background l'esecuzione di OLE.rexx (questo, poi, diventa OLE Server). Una volta lanciato, OLE Server perfeziona l'ambiente esecutivo caricando alcune librerie ed inizializzando alcuni parametri fondamentali che serviranno a tutti gli altri moduli. Ad ogni chiamata, OLE Server assegna dei nomi indicizzati per ciascun "oggetto" che sarà "scambiato" o farà da "collegamento" tra esso stesso ed i moduli esterni (da qui il nome OLE, Objects and Links Exchanged). Ogni istanza di OLE System avrà un set di "oggetti" diversi per evitare conflitti. Terminata questa fase iniziale, OLE Server prepara l'esecuzione del primo modulo esterno caricandogli la configurazione e la localizzazione. Lanciato il primo modulo, OLE Server si pone in attesa dei messaggi che saranno inviati alla sua porta. Tralascio la descrizione di questi messaggi che riprenderò approfonditamente commentando il listato di OLE.rexx. I MODULI ESTERNI Passiamo ora a descrivere brevemente i moduli esterni che vengono lanciati da OLE Server. Questi realizzano effettivamente la funzione richiesta dall'utente. Conservano la medesima struttura interna suddivisa in blocchi. Un primo blocco riceve la descrizione dell'ambiente esecutivo da OLE Server ed inizializza le variabili necessarie. Una volta aperta la porta per ricevere messaggi, si passa al successivo blocco. Il secondo blocco costruisce l'interfaccia (GUI) con cui l'utente potrà pilotare l'esecuzione della funzione richiesta. Un altro blocco vede iniziare il dialogo tra il modulo stesso ed OLE Server fino a quando l'utente, terminata la fase di configurazione, non dia il via alla esecuzione vera e propria. Il blocco esecutivo non risiede necessariamente in un unico modulo. Questo perchè una particolare funzione (come quella di importare tabelle da ProCalc in Final Writer) può richiedere l'utilizzo di più applicativi contemporaneamente. È qui la ragione di spezzare l'esecuzione in più moduli, perchè ciò semplifica la scrittura o l'aggiornamento degli stessi moduli. Non solo, volendo cambiare OLE Server radicalmente, non è necessario riscrivere tutti i moduli, ma solo quelli nuovi. Provvederà, infatti, lo script di inizializzazione a dirottare la chiamata verso il nuovo OLE Server. Facciamo un breve passo indietro, per parlare di altre caratteristiche dei moduli degne di nota. Ho già detto che ciascun modulo possiede una sezione dedicata alla configurazione di quei parametri necessari alla successiva elaborazione (tale sezione esiste in ragione alla presenza di parametri da impostare). Bene, l'utente può salvare i parametri che ha impostati, se lo desidera. La perdita dei file di configurazione non ha grande importanza perchè ciascun modulo conserva un set di parametri di default al suo interno. Altro è invece la perdita dei files relativi alla localizzazione che non hanno riscontro all'interno dei moduli. In questo caso si può sempre ricorrere al programma di configurazione di OLE System per ricompilare i cataloghi perduti. CONFIGURAZIONE DI OLE SYSTEM Ho scritto anche un programma di configurazione generale di OLE System. Al momento in cui scrivo, esso permette all'utente di editare e compilare i cataloghi e aggiustare alcuni parametri necessari alla GUI. Anche se l'ho pensato per stare nel cassetto delle preferences, può trovarsi ovunque (è uno script come quelli descritti che lancia l'utente). Altri particolari, come la discussione dettagliata della struttura di OLE System, le rimando alla documentazione per gli sviluppatori. Ringrazio cortesemente quanti siano giunti alla fine di questo articolo, COPYRIGHTS "Commodore" è un marchio di proprietà riservata della Commodore Italiana S.p.A. "Amiga" è un marchio protetto della Commodore Business Machines. Altri nomi e marchi protetti sono citati senza indicarne i relativi brevetti. Non è mia intenzione fare cattivo uso dei suddetti, ma chiunque abbia rivendicazioni da fare può comunicarmele direttamente scrivendomi o telefonandomi, in futuro avrò anche un e-mail. Ringrazio cortesemente tutti i proprietari dei prodotti usati o menzionati per aver permesso la creazione di questo pacchetto di pubblica utilità.