Scoprire il tipo del documento attivo

Durante una sessione di lavoro con OpenOffice.org, in un istante qualsiasi può esistere un solo documento attivo che corrisponde al documento contenuto nella finestra di OpenOffice.org che ha il focus in quel dato momento.
Dato che, a differenza di MS Office, OpenOffice.org è un'applicazione monolitica, il documento attivo può essere di qualunque tipo: un foglio elettronico, un database, un documento di testo e altro ancora.
Per questo motivo, sviluppando macro, capita abbastanza spesso di avere la necessità di sapere il tipo di documento attivo per poter applicare i metodi appropriati.
In MS Office esiste un programma eseguibile associato a ciascun tipo di documento, in OpenOffice.org invece esiste un componente specifico associato a ciascun tipo di documento, perciò la questione si riduce a conoscere il componente attivo piuttosto che il documento attivo.
I componenti sono dei servizi UNOⁱ che hanno particolari caratteristiche. Senza volerci addentrare in dettagli, diciamo solo che i servizi UNO più complessi solitamente mettono a disposizione dei metodi specifici che permettono di identificare il servizio stesso e ottenere informazioni sulle caratteristiche supportate.
Vediamo ora i metodi più interessanti per il nostro utilizzo:

Nome	Descrizione
getSupportedServiceNames()	Restituisce un array con i nomi di tutti i servizi UNO supportati dall'oggetto, incluso il servizio UNO principale. Questo metodo non prende argomenti
supportsService( String: ServiceName)	Controlla se un particolare servizio è supportato dall'oggetto. Il metodo prende in argomento il nome del servizio che si vuole testare e restituisce Vero (True) se il servizio è supportato, Falso (False) se il servizio non è supportato dall'oggetto.

Vediamo ora come utilizzare quanto osservato fino ad ora per risolvere il problema iniziale, ovvero determinare il tipo di documento attivo.
Prima di tutto otteniamo un riferimento al documento attivo:

    oDoc = StarDesktop.getCurrentComponent()

Ora dobbiamo controllare se il componente attivo supporta alcuni servizi specifici che identificano univocamente il tipo di documento.
Per effettuare il test useremo il metodo supportsService
Ecco l'elenco dei nomi dei servizi UNO con il tipo di documento associato:

Servizio UNO	Tipo di documento
com.sun.star.text.TextDocument	Documento di testo (Writer)
com.sun.star.text.WebDocument	Documento HTML (Writer)
com.sun.star.text.GlobalDocument	Documento Master (Writer)
com.sun.star.sheet.SpreadsheetDocument	Foglio elettronico (Calc)
com.sun.star.presentation.PresentationDocument	Presentazione (Impress)
com.sun.star.drawing.DrawingDocument	Disegno (Draw)
com.sun.star.formula.FormularProperties	Formula matematica (Math)
com.sun.star.sdb.OfficeDatabaseDocument	Documento database (Base)

Non rimane altro che scrivere il codice che esegue materialmente il test:

REM  *****  BASIC  *****

Sub TestDocumentType()

    oDoc = StarDesktop.getCurrentComponent()

    If oDoc.supportsService("com.sun.star.text.TextDocument") Then
        MsgBox "Documento di testo OOo Writer"
    ElseIf oDoc.supportsService("com.sun.star.text.WebDocument") Then
        MsgBox "Documento HTML di OOo Writer"
    ElseIf oDoc.supportsService("com.sun.star.text.GlobalDocument") Then
        MsgBox "Documento Master di OOo Writer"
    ElseIf oDoc.supportsService("com.sun.star.sheet.SpreadsheetDocument") Then
        MsgBox "Foglio elettronico di OOo Calc"
    ElseIf oDoc.supportsService("com.sun.star.drawing.DrawingDocument") Then
        MsgBox "Disegno di OOo Draw"
    ElseIf oDoc.supportsService("com.sun.star.presentation.PresentationDocument") Then
        MsgBox "Presentazione di OOo Impress"
    ElseIf oDoc.supportsService("com.sun.star.formula.FormulaProperties") Then
        MsgBox "Formula matematica di OOo Math"
    ElseIf oDoc.supportsService("com.sun.star.sdb.OfficeDatabaseDocument") Then
        MsgBox "Documento database di OOo Base"
    End If
    
End Sub

Per testare il codice è sufficiente copiarlo in nuovo modulo nella libreria Standard del proprio utente, creare un nuovo documento di qualsiasi tipo, tornare nell ambiente di sviluppo (IDE) di StarBasic e lanciare la macro mediante l'apposito pulanste della barra degli strumenti oppure mediante il tasto
Per un uso più generalizzato sarebbe opportuno trasformare la routine dell'esempio in una funzione.
Effettivamente esiste già una funzione simile nella libreria Tools, modulo Misc:

Si tratta della funzione GetDocumentType().
Ecco come utilizzarla:

REM  *****  BASIC  *****

Sub TestToolsFunction()

    oDoc = StarDesktop.getCurrentComponent()
    
    'prima di utilizzar el efunzioi della libreria 
    'condivisa Tools occorre caricarla:
    BasicLibraries.loadLibrary.Tools
    
    'ora è possibile  richiamare la funzione
    sDocType = GetDocumentType(oDoc)
    MsgBox sDocType
    
End Sub

La funzione inclusa nella libreria Tools purtroppo non è molto aggiornata e non è in grado di riconoscere i documenti OOo Base, i documenti HTML e i documenti Master
Alla luce di quanto illustrato fino ad ora dovrebbe essere piuttosto facile modificare la funzione della libreria Tools aggiungendo i tipi di documento mancanti.

A presto
Paolo

Ecco il sito di un vero appassionato di MACRO e API !!

Ecco il sito di un vero appassionato di MACRO e API !!
Vi prego non fatemela spiegare ;-)
Comunque posso assicurare che Luca Mazzocchi, autore del sito, non solo è un grande esperto di macrofotografia e profondo conoscitore del mondo dell'apicoltura ma è anche un programmatore di Macro e API di OpenOffice.org. :-)

Conta cellule

Un utente del Newsgroup it-alt.comp.software.openoffice ha postato una domanda interessante (dal mio punto di vista ovviamente).

Ma vediamo in dettaglio cosa dice l'amico Torakiki78:

Sto cercando di fare un file con openoffice calc che mi serve per
contare delle cellule... ecco come dovrebbe essere:
la conta è di 100 cellule in tutto e di ciascuna devo segnalare se
è mobile, poco mobile o immobile. Premendo 1, la cellula è mobile.
Premendo 2 la cellula è poco mobile. Premendo 3 la cellula è
immobile.

Ho fatto un file (che se volete posto...) con openoffice calc in
cui segno per ogni cella (dalla A4 alla A104) premendo 1,2 oppure 3 e
poi invio per passare alla cella successiva (cioè quella sotto).

Le mie richieste sono:
Vorrei poter premere 1, 2 o 3 e SENZA dover premere invio poter
passare alla cella sotto. In più vorrei che quando arrivo alla
cella A54 poter sentire un suono che mi avvisa che sono arrivato a
contare 50 cellule.
Vorrei anche che, se premo 4 o 5 o 9 (o comunque un numero diverso
da 1,2,3), che non venisse segnalato....
Non so usare le macro, e un pochino le funzioni....

Mi potete aiutare?

E come no! Siamo qui per questo :-)

Dunque, prima di procedere però, cito la risposta di Roberto Montaruli:

Il tuo e' un problema di interfaccia, non di applicazione.
Tu vuoi una interfaccia utente su misura.
Richiesta rispettabilissima.
Ma Calc non e' una applicazione di interfaccia, e' un gestore di
foglio elettronico.
Gestisce i dati, non l'input degli stessi.

In effetti la risposta di Roberto è molto sensata, probabilmente con un piccolo programma standalone si potrebbe raccogliere l'input per poi salvarlo ad esempio in un file CSV.

In ogni caso, OpenOffice.org dispone di tutti i mezzi per costruire la piccola interfaccia di cui abbiamo bisogno in modo abbastanza pulito.

Per cominciare ci serve almeno una rudimentale specifica:

Specifica di progetto

L'idea a grandi linee è la seguente:

una finestra di dialogo modale con un campo di testo che riceverà l'input

ogni volta che l'utente premerà un tasto, se il tasto corrisponde a 1 o 2 o 3 il valore verrà “appeso” ad un vettore, diversamente il valore verrà rigettato

Una variabile numerica terrà il conto di quanti inserimenti sono stati fatti, il valore attuale verrà mostrato nel dialogo mediante un controllo “testo fisso”

Al cinquantesimo inserimento verrà emesso un beep mentre al centesimo, doppio beep e uscita dal dialogo.

All'uscita provvederemo a creare un nuovo documento Calc e a trasferire i valori conservati nel vettore.

Naturalmente tutto il progetto sarà impacchettato come extension. Nell extension verrà inserita anche una piccola barra degli strumenti con un solo pulsante che servirà per lanciare il dialogo.

Preparazione ambiente

Per prima cosa occorre creare una nuova libreria macro condivisa che chiameremo “ContaCellule”

Design del dialogo

Ora passiamo a disegnare il dialogo come segue:

Il dialogo si chiamerà DlgContaCellule

Il controllo in alto è un fixed text che ho chiamato lblCount, mentre quello sottostante è un text edit che ho chiamato txtInput

Per essere sicuri che all'apertura del dialogo il focus (e quindi l'input dell'utente) sia immediatamente dirottato su txtInput occorre impostare la proprietà sequenza = 0

Come ulteriore precauzione, tutti i rimanenti controlli avranno la proprietà Tabstop = No

Questo impedirà loro di ricevere il focus quando si preme il tasto tabulazione.

Altri accorgimenti:

Pulsante OK : impostare la proprietà Abilitato = No e la proprietà Tipo di pulsante = OK

Pulsante Annulla : impostare la proprietà Tipo di pulsante = Annulla

Eventi

Ora dobbiamo creare la procedura che verrà usata per intercettare l'input dell'utente.

Sub txtInput_KeyPressed(oEvt)

End Sub

Questa procedura dovrà essere collegata all'evento Tasto premuto del controllo txtInput

Mostrare il dialogo

Ora aggiungiamo il codice per mostrare il dialogo:

REM  *****  BASIC  *****

Private oDlg As Object

'_____________________________________________________________________________
Sub ShowDialog
DialogLibraries.loadLibrary("ContaCellule")
oDlg = CreateUnoDialog(DialogLibraries.ContaCellule.DlgContaCellule)

'initialize controls
oDlg.Model.txtInput.Text = ""
oDlg.Model.lblCount.Label = ""

IDlgResult = oDlg.execute()

If iDlgResult = 1 Then
'user pressed OK
'
'
'
'
End If

End Sub

Ovviamente il codice è ancora incompleto.

Manca infatti la gestione dell'evento key pressed ed inoltre occorre conservare i dati inseriti per poi riversarli opportunamente in un documento Calc

Codice completo

Ecco il codice completo:

REM  *****  BASIC  *****

Private oDlg As Object
Private iCount As Integer
Private mValues()


'_____________________________________________________________________________
Sub ShowDialog
DialogLibraries.loadLibrary("ContaCellule")
oDlg = CreateUnoDialog(DialogLibraries.ContaCellule.DlgContaCellule)

'initialize controls
oDlg.Model.txtInput.Text = ""
oDlg.Model.lblCount.Label = ""

IDlgResult = oDlg.execute()

If iDlgResult = 1 Then
'user pressed OK

'create a new Calc doc
sUrl = "private:factory/scalc"
oDoc = StarDesktop.LoadComponentFromURL(sUrl,"_default",0, Array())
oSheet = oDoc.Sheets(0)

'put the data in the column A starting from row 4
For I = LBound(mValues()) To UBound(mValues())
    iRow = I + 3
    oCell = oSheet.getCellByPosition(0, iRow)
    oCell.FormulaLocal = mValues(I)
Next I
End If

End Sub


'_____________________________________________________________________________
Sub txtInput_KeyPressed(oEvt)
Dim sChar As String

sChar = oEvt.KeyChar
If (sChar = "1") Or (sChar = "2") Or (sChar = "3") Then
If iCount < 100 Then
    'store the data
    AppendItem(mValues(), sChar)

    'update the control content
    Select Case sChar
            Case "1" : oEvt.Source.Text = "Mobile"
            Case "2" : oEvt.Source.Text = "Poco mobile"
            Case "3" : oEvt.Source.Text = "Immobile"
    End Select

    'beep when 50th data has been inserted
    If iCount = 49 Then
            Beep
    End If

    iCount = iCount + 1
    oDlg.Model.lblCount.Label = iCount

Else
    oEvt.Source.Text = "Fine!!"
   'enable the OK button and alert the user that the end is reached
    oDlg.Model.cmdOk.Enabled = True

    Beep
    Wait 200
    Beep
    Wait 200
    Beep

End If
Else
'invalid input
oEvt.Source.Text = "-N/A-"

End If

End Sub

'_____________________________________________________________________________
Sub AppendItem(mList(), vItem)
Dim iMax As Long

iMax = UBound(mList())
iMax = iMax + 1
Redim Preserve mList(iMax)
mList(iMax) = vItem

End Sub

Impacchettamento e distribuzione

Non rimane altro che confezionare la nostra mini applicazione.

Usando l'extension BasicAddonBuilder , in pochi passaggi è possibile esportare la libreria appena creata come extension:

Passaggio 1: Selezione libreria

Passaggio 2: Opzioni generali

Passaggio 3: Definizione della barra degli strumenti

Aggiungendo un nuovo pulsante nella barra, nel dialogo delle proprietà sarà possibile definire il comando assegnato (che nel nostro caso sarà la macro ShowDialog ) e altre caratteristiche come ad esempio l'icona, o il contesto che indica semplicemente in quali componenti di OpenOffice.org sarà visibile il nuovo pulsante.

Passaggi conclusivi

Nei passaggi successivi è possibile indicare ulteriori caratteristiche come ad esempio la licenza, il numero di versione, un testo descrittivo. Ecc.

In ultimo verrà chiesto di indicare un percorso per salvare la nuova extension nel proprio disco fisso.

L'extension così creata sarà installabile in qualsiasi PC ove sia presente OpenOffice.org

Per i più pigri, l'extension già assemblata è disponibile qui:

http://www.paolo-mantovani.org/downloads/ContaCellule/

A presto!

BasicAddonBuilder: problemi con OOo3.1 su Mac OS X

Dopo tanto tempo eccomi di nuovo qui.
Pare che BasicAddonBuilder abbia un problema con OpenOffice.org 3.1 su Mac OS X 10.5.7 (Intel)
Un utente tedesco mi segnala infatti che da quando ha aggiornato OpenOffice.org all'ultima versione 3.1, non riesce più ad utilizzare BasicAddonBuilder, ottenendo strani errori.

L'extension peraltro aveva sempre funzionato bene fino alla penultima 3.0
L'errore avviene in corrispondenza di questo codice:

Modulo: DlgWizard_main
-----------------------

Sub Dialog_Initialize
Dim oBasicProvider As Object
Dim oBasicLibrary As Object
Dim mNameList()
Dim sPkgDesc As String

'setup the objects in the dialog
 'general controls (step 0)
 'setup the Roadmap control
 '(the "navigation panel" on the left of the dialog)
 InitializeRoadmap
 
 'step 01 controls
 With g_oDlgWizardModel
  .lstBasicLibraryContainers.StringItemList = GetProviderUINames()
  .lstBasicLibraryContainers.SelectedItems = (Array(0))
 
  oBasicProvider = g_mBasicProviders(0).Provider

L'ultima linea è quella che solleva l'errore.
Ecco uno screenshot che mostra il messaggio di errore:

Beh, ora il difficile è scoprire il motivo. Purtroppo non ho a disposizione un Mac per fare delle prove, perciò si accettano idee :-)
Alla prossima.

Il PLIO rinnova il Consiglio Direttivo

Pochi giorni fa, il 14/03/2009, Il Progetto Linguistico Italiano OpenOffice.org (PLIO) ha rinnovato il proprio esecutivo.
Il nuovo presidente è Italo Vignoli, a cui vanno i miei auguri di buon lavoro.
Io sarò il vice-presidente e ... beh, cercherò di fare del mio meglio!
Gli altri membri del Consiglio Direttivo sono:
Francesca Beatrice Cice
Roberto Galoppini
Flavia Marzano
Andrea Pescetti
Paolo Pozzan
Un ringraziamento particolare e va al presidente uscente, Davide Dozza che negli ultimi anni, con il suo lavoro instancabile ha contribuito al successo di OpenOffice.org in Italia.

Tutti a Orvieto per la Conferenza 2009 di OpenOffice.org

Riporto il comunicato del PLIO (Progetto Linguistico Italiano OpenOffice.org):

Trieste, 4 marzo 2009 - PLIO e OrvietoLUG annunciano che la OpenOffice.org Conference 2009 si terrà a Orvieto nel mese di novembre. La proposta presentata dalle due associazioni insieme ad Assessorato all'Informatizzazione del Comune di Orvieto, Fondazione per il Centro Studi "Città di Orvieto", Consorzio SIR-Umbria e CCOS (Centro di Competenza sull'Open Source della Regione Umbria), ha ottenuto il 48% dei voti, e ha superato quelle di Budapest - che sarà la sede della conferenza nel 2010 - e di altre 5 città. Le proposte sono online all'indirizzo: http://marketing.openoffice.org/ooocon2009/cfl/

"L'assegnazione della conferenza 2009 a Orvieto è una conferma del ruolo assunto dalla comunità italiana all'interno dell'ecosistema di OpenOffice.org", commenta Davide Dozza, Presidente dell'Associazione PLIO. "Un'importanza che non sta solo nei numeri che continuano a crescere - i download della versione italiana, che a febbraio sono stati quasi 800.000, e il traffico verso il sito internazionale, che è superiore a 25.000 accessi al giorno - ma anche nella partecipazione dei singoli: Giuseppe Castagno e Paolo Mantovani nell'area dello sviluppo, e Italo Vignoli in quella del marketing. La comunità italiana, inoltre, è tra le poche a svolgere tutte le attività di localizzazione e quality assurance al proprio interno, grazie al lavoro dei volontari".

Le date definitive e il programma della conferenza verranno annunciati nel corso delle prossime settimane. Per la prima volta nella storia della conferenza, ci sarà una sessione parallela nella lingua locale - l'italiano - durante tutta la durata dell'evento. Nella tradizione della comunità, sarà possibile seguire le discussioni sulla mailing list della conferenza, a cui è possibile aderire inviando un email a ooocon2009_discuss-subscribe@marketing.openoffice.org.

Link Utili

Associazione PLIO: http://www.plio.it

OpenOffice.org 3.0 in italiano: http://it.openoffice.org/download/

Guida a OOo 3.0 in inglese (PDF): http://tinyurl.com/GuideOOo30

Modelli in Italiano: http://wiki.services.openoffice.org/wiki/IT/Modelli

FAQ su OOo dal Newsgroup Italiano: http://tinyurl.com/OOoITFAQ

OpenOffice.org nelle altre lingue: http://download.openoffice.org

Estensioni per OOo: http://extensions.services.openoffice.org

L’Associazione PLIO, Progetto Linguistico Italiano OOo, raggruppa la comunità italiana dei volontari che sviluppano, supportano e promuovono la principale suite libera e open source per la produttività negli uffici: OpenOffice.org. Il software usa il formato dei file Open Document Format (standard ISO/IEC 26300), legge e scrive i più diffusi tra i formati proprietari, ed è disponibile per i principali sistemi operativi in circa 100 lingue e dialetti, tanto da poter essere usato nella propria lingua madre da più del 90% della popolazione mondiale. OpenOffice.org viene fornito con la licenza GNU LGPL (Lesser General Public Licence) e può essere utilizzato gratuitamente per ogni scopo, sia privato che commerciale.

PLIO, Progetto Linguistico Italiano OpenOffice.org: http://www.plio.it. Vola e fai volare con i gabbiani di OpenOffice.org: usalo, copialo e regalalo, è legale!

OpenOffice.org API: Evoluzione o Stabilità?

In questi mesi, nel pentolone del progetto API ribollono parecchie novità, come l'adozione dell'ereditarietà multipla e un nuovo modello di constructor per i servizi UNO.

Le novità comportano sempre dei cambiamenti, perciò l'eterna discussione sulla dicotomia (vera o presunta) tra evoluzione e stabilità si è riaccesa in modo vivace, alimentata anche dal contributo autorevole di sviluppatori indipendenti come Ariel Constenla-Haile.

La stabilità in questo contesto non va però intesa come l'attitudine di un programma a non andare in crash ogni qualvolta che un raggio cosmico dovesse passare nelle vicinanze.

La trave portante dell'API infatti, non è tanto l'implementazione quanto l'insieme delle specifiche che definiscono e regolano l'interazione tra un programma client e il programma host (OpenOffice.org)

Background

In termini molto generali, si può immaginare l'API come una sorta di vocabolario predefinito, con tanto di convenzioni grammaticali e lessicali, che il programma client deve utilizzare per poter controllare OpenOffice.org.

Il programma client è generalmente sviluppato da terze parti, siano esse semplici utenti che utilizzano le macro o sviluppatori professionisti che integrano OpenOffice.org nelle loro soluzioni software.

Per questo motivo è molto importante che, una volta che gli sviluppatori API abbiano stabilito il “vocabolario” e la “ grammatica” per comunicare non ci siano stravolgimenti ad ogni nuova versione di OpenOffice.org.

Pros&Cons

La politica del progetto API, fortemente difesa da Jürgen Schmidt attuale leader del progetto, è sempre stata coerente, anzi direi granitica su un punto: ciò che è pubblicato non deve essere modificato.

In altre parole, la definizione di un sevizio o di un interfaccia vengono considerati come un contratto vero e proprio tra lo sviluppatore API e i suoi utenti ovvero gli sviluppatori esterni che utilizzano i servizi e le interfacce.

Agli inizi del progetto questa fermezza di propositi venne giudicata indispensabile per creare un clima di fiducia negli sviluppatori esterni, che guardavano con interesse e valutavano se valeva la pena di investire risorse nell'adozione di questa nuova piattaforma.

Tale politica ha indubbiamente pagato. La comunità degli sviluppatori esterni in questi anni è cresciuta enormemente non solo quantitativamente ma anche qualitativamente, raggiungendo livelli di competenza molto elevati.

Per contro, ci sono stati anche dei costi in termini di difficoltà evolutive, basti pensare al difficilissimo parto del componente Base, introdotto con la versione 2.0

Bisogna ricordare che OpenOffice.org era dotato un componente database fin dalla prima versione. Tale componente non aveva una propria interfaccia grafica separata. In pratica il componente base, in background, forniva a tutti gli altri componenti la capacità di interagire con i database.

Nel passaggio alla versione 2.0 questo approccio “pervasivo” venne trasformato in quello basato su documenti che vediamo attualmente.

Questa trasformazione richiese complessi adattamenti se non addirittura veri e propri contorsionismi a livello di API proprio perché la scelta fu quella di mantenere il più possibile la compatibilità con il codice di terze parti preesistente.

Il ciclo di sviluppo API

In altri casi il “costo” per mantenere la compatibilità con il codice preesistente si manifesta in modi più subdoli.

Il ciclo di sviluppo dell'API prevede che un servizi o un interfaccia di nuova creazione siano immediatamente resi pubblici, ma etichettati inizialmente come unpublished.

Questo significa che possono essere utilizzati ma che potrebbero essere soggetti a modifiche e correzioni incompatibili con il codice preesistente.

Trascorso un certo periodo e dopo aver ottenuto qualche feedback da parte dell'utenza il servizio o l'interfaccia vengono ri-etichettati come published e da questo momento non potranno più subire modifiche.

Questo meccanismo ha fatto si che gli sviluppatori tendessero a non documentare pubblicamente i nuovi servizi e comunque, una volta documentati venivano marcati come unpublished per un tempo lunghissimo proprio per non vedersi congelare il proprio lavoro e per tenere sempre aperta la possibilità di correzioni.

Di fatto, questo atteggiamento riluttante rischiava, e rischia tuttora, di vanificare il contratto con gli utilizzatori.

(se ogni nuova interfaccia rimane unpublished a tempo indeterminato la stabilità non sarà mai garantita)

Per questo motivo i mantainer del progetto API hanno comunque obbiettato in più casi che, se un servizio o un'interfaccia sono rimasti disponibili per lungo tempo verranno comunque considerati non modificabili, indipendentemente dallo stato di pubblicazione.

Questo è in palese contraddizione con le regole di pubblicazione volute dagli stessi mantainer, ma, l'orientamento generale è chiaro, si tende a preservare (e con giustissima ragione, aggiungo io) la compatibilità e il contratto con l'utenza ad ogni costo.