sabato 10 ottobre 2009

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!


martedì 9 giugno 2009

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.

martedì 17 marzo 2009

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.

venerdì 6 marzo 2009

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!



domenica 22 febbraio 2009

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.