Alle 11:06, domenica 13 maggio 2007, Renato Ferrari ha scritto:
> Il 00:03, domenica 13 maggio 2007, Paolo Mantovani ha scritto:
> > > ad esempio, se ho un foglio di calcolo con due o tre finestre di
> > > dialogo, devo sempre creare-dichiarare nella macro le finestre di
> > > dialogo?
> >
> > Non ho ben capito, puoi essere più specifico?
>
> per esempio, da questo foglio e relativa macro scritta da Mario Lodi
> Rizzini: --------------------------
> oDialog = LoadDialog("Standard", "UserFormInputDati", DialogLibraries)
[...]
> oDialog.Execute()
> --------------------------------------------------------------
> ogni singolo componente di una finestra di dialogo viene ridichiarata.
> in staroffice5.2 era semplicemente così:
>
> ENUS.Show
>
> se non dovevo reimpostare i valori dei singoli campi della finestra di
> dialogo.
Ok ore è chiaro.
Si, devi istanziare il dialogo in modo esplicito.
Attenzione:
il codice che hai riportato usa una funzione "LoadDialog" per creare l'istanza
di un dialogo.
Questa funzione è contenuta nella libreria Tools perciò dovrai aver cura di
caricare questa libreria prima di chiamare la funzione
In realtà questa funzione non fa nulla di complicato perciò si potrebbe pure
evitare:
oDialog = createUnoDialog( DialogLibraries.Standard.UserFormInputDati )
createUnoDialog è una funzione runtime di starbasic e converte un descrittore
di dialogo in un dialogo runtime (eseguibile).
> > > (ActiveWindow.JumpToTable(3) mi permette di attivare la terza tabella
> > > di un foglio elettronico d'acchito)
> >
> > Hai provato con il registratore di macro?
>
> quale?
> quello fornito con OOo registra tramite "dispatcher" che mi da' l'idea di
> essere una specie di traduttore dei comandi di staroffice5.2,
Infatti lo avevo suggerito proprio perchè genera codice in qualche modo simile
a quello di StarOffice 5.x
> genera una
> marea di variabili passate poi come argomento ai vari comandi e non mi
> permette di capire realmente quale sia l'equivalente "nativo"
> dell'istruzione che mi serve.
Si, il codice basato su dispatcher è un po dispersivo ma alla fine è
ripetitivo e perciò non difficile da capire.
Però, parlando di cosa è "nativo" e cosa non lo è, bisogna anche dire che il
DispatchHelper è un normale servizio API, perciò tecnicamente parlando non è
meno "nativo" di qualunque altro servizio API.
Io direi piuttosto che il DispatchHelper è un servizio API che consente un
accesso *generico* (ma limitato) alle funzionalità di OpenOffice,
Dall'altra parte esistono i servizi API *dedicati* o *specializzati* che
consentono un accesso completo alle funzionalità della suite (e anche altro)
Speculazioni a parte, il limite principale del codice basato su DispatchHelper
è che risulta difficile da "generalizzare", perciò poco utile anche a fini
didattici.
Te lo avevo suggerito perchè non sapevo quale era il tuo livello di esperienza
e non volevo confonderti le idee.
Visto però che su questo punto hai le idee piuttosto chiare vediamo come si
procede usando le API "specializzate" anzichè il dispatchHelper.
Per attivare una tabella:
oSheet = ThisComponent.Sheets(2)
ThisComponent.CurrentController.setActiveSheet(oSheet)
Ricorda che gli indici nell'API partono sempre da 0 perciò l'indice 2
corrisponde alla terza tabella.
Per le altre domande io aprirei un thread specifico, giusto per non seppellire
le informazioni utili e favorire future ricerche in archivio.
> Devo dire che, purtroppo, da questo punto di
> vista il VBA è molto superiore!
Assolutamente. VB/VBA sono prodotti bellissimi, ci ho programmato per anni con
grande soddisfazione. Poi però con il passare degli anni mi rendevo conto che
le cose che conoscevo cambiavano continuamente di nome, un po come quelle
discoteche che per sembrare nuove cambiano il cartello ogni stagione.
E di nome in nome, la mia conoscenza svaniva.
Il mio investimento di tempo e capacità si deprezzava a ogni nuovo stupido
acronimo (bisogna dire che quelli della Microsoft in quanto ad acronimi sono
anche più prolifici delle Giovani Marmotte)
E così un giorno ho mi sono reso conto che VB non era un buon investimento per
il mio tempo, anzi era un pessimo investimento, un pozzo senza fondo, e me ne
sono liberato.
> (ciò nonostante, resto attaccato con le
> unghie e i denti, sia a casa sia, e con ancor maggior difficoltà, in
> ufficio, a linux e OOo)
Certo ci sono difficoltà.
Passando da VBA a StarBasic devi fare i conti con l'API di Openoffice.org
Il problema principale qui è che la complessità non viene nascosta.
In VBA l'esercizio principale del produttore è quello di nascondere la
complessità di quello che gira "sotto".
Lodevole intento, anche se a me fa venire in mente lo sforzo del genitore che
cerca di rispondere a certe domande del figlio piccolo:
Il poveretto cerca disperatamente le parole più elementari e innocue per non
dover spiegare il mondo che sottende a quella parolona di cui il piccolo vuol
sapere il significato, e alla fine invece di una spiegazione semplice viene
fuori una spiegazioni stupida, che naturalmente produrrà altre mille domande.
Beh magari può non piacere a chiunque, ma l'API di OOo ti tratta da pari a
pari.
Il vantaggio è che quando hai capito come funziona, nessuno potrà azzerare la
tua conoscenza cambiando un'interfaccia o una sigletta.
Tanto per tornare dalla filosofia alla pratica, per affrontare l'automazione
di OOo senza traumi occorrono alcuni strumentini a portata di mano:
Xray
SDK
Manuali di Andrew Pitonyak
Manuale di Sun (ti ho dato il link nel post precedente)
Hai già tutte queste cose? le usi? quali sono i problemi?
> quello che avevi scritto tu va molto meglio, da questo punto di vista, ma è
> da molto tempo che non lo provo, perchè quando c'ho provato avevo le idee
> ancora più confuse di adesso!!!
Io di registratori ne ho scritti due, il primo sotto forma di documento Calc è
ormai arcaico, anche se forse funziona ancora.
Lo scrissi quando in OpenOffice non esisteva ancora il registratore di macro
(erano i tempi della 1.0 ovviamente)
Attualmente ti consiglio di provare questo:
http://www.paolo-mantovani.org/downloads/DispatchToApiRecorder/
Si tratta di un registratore alternativo che una volta installato "rimpiazza"
il registratore di macro "ufficiale" della suite.
Questo registratore alternativo scrive codice basato sulle api "specializzate"
(o "native" come le chiami tu) invece del solito codice basato su
DispatchHelper.
Perchè possa funzionare correttamente è necessario installare anche almeno
un "transformer".
Il Transformer è la parte che materialemnte produce il codice registrato.
A tutt'oggi ho scritto solo un Transformer per Calc:
http://www.paolo-mantovani.org/downloads/DispatchToApiRecorder/transformers/Calc/
ciao
Paolo M
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
