\nuovoarticolo{Rocco Coluccelli}{The OLE System v1.0}{%
Rocco Coluccelli \\
Via F.~Orsoni 8 \\
I-40135 Bologna BO \\
Tel.:~(051)6142479
}{}{italian}{
{\em The lesser-known programming languages \#18: C-} \\
This language was named for the grade received by its creator when he
submitted it as a class project in a graduate programming class.  C- is
best described as a ``low-level'' programming language.  In fact, the
language generally requires more C- statements than machine-code
statements to execute a given task.  In this respect, it is very
similar to COBOL.}{}

\sez{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.

E arriviamo finalmente all'anello mancante, qualcosa che fosse
sufficientemente potente, flessibile e assolutamente semplice.

\sez{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 tra le più diverse, con estrema
semplicità.

\sez{Il concetto}

L'idea nacque osservando le OLE di Windows, ricordando le hot-link 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 Ed, provai il programma
FinalWriter 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 FinalWriter grazie ad ARexx mi
spinse verso un progetto più ambizioso: uno script per importare una
tabella da Professional Calc all'interno di FinalWriter 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 nacque quando cominciai a pensare a 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 a 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 a
una standardizzazione nella scrittura di nuovi moduli che di fatto
conservano la medesima struttura interna.



\sez{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 propria interfaccia usando
un comune editor di testi.

I file 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} (il catalogo sorgente per il
programma ¶{OLE.rexx} sarà quindi ¶{OLE.rexx.ct}). Questi file 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 file, 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 a 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.
%


\sez{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 e inizializzando alcuni parametri fondamentali che
serviranno a tutti gli altri moduli. A ogni chiamata, OLE Server
assegna dei nomi indicizzati per ciascun ``oggetto'' che sarà ``scambiato''
o farà da ``collegamento'' tra esso stesso e 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}.


\sez{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 e 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 e 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 FinalWriter) 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
impostato, 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 file 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.



\sez{Configurazione di OLE System}

Ho scritto anche un programma di configurazione generale di OLE System.
Nel momento in cui scrivo, esso permette all'utente di editare e
compilare i cataloghi e aggiustare alcuni parametri necessari alla GUI.
Anche se è stato pensato per stare nel cassetto ¶{Prefs}, può trovarsi
ovunque (è uno script come quelli descritti che lancia l'utente).

Altri particolari, come la discussione dettagliata della struttura di
OLE System, li rimando alla documentazione per gli sviluppatori.

Ringrazio cortesemente quanti siano giunti alla fine di questo articolo.


%\sez{Copyright}
%
%``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à.

\finearticolo