LEGGETE ANCHE GLI ARTICOLI!!! L’ultimo al link:

http://blog.shareoffice.it/giannigiaccaglini/articles/10324.aspx

I bachi inattesi? Colpa della Semantica, signori miei...

Questo post, frivolo nell’esemplificazione che darò, pretende in modo alquanto serioso di discutere su un problema che affligge l’Informatica e non solo. Parlo della Semantica, disciplina linguistica che si occupa del significato di un testo, meaning in inglese. Di sfuggita cito solo un interrogativo provocatorio (che riprendo – se non ricordo male - dal ponderoso trattato di Semiotica generale di Umberto Eco): The meaning of the meaning che diavolo è?

In due parole, alla buona, la faccenda ha a che fare - nella vita o peggio ancora nella giurisprudenza - coi molti fraintendimenti derivanti dalla più o meno evitabile divaricazione fra i significati letterali e quelli intenzionali (cosiddetti). In gergo semiotico si tenta una distinzione fra denotazione e connotazione di un messaggio.

Venendo allo specifico dell’Informatica sono noti i fallimenti di certi settori avanzati. Tipicamente l’Intelligenza Artificiale (IA) o un suo figliolo, la traduzione automatica. L’IA ogni tanto viene ri-chiamata in ballo ma oggi dei tanto celebrati Sistemi Esperti quasi nessuno parla più. La seconda da qualche tempo partorisce qualche topolino non del tutto privo di utilità, però ognuno di noi ha quotidianamente modo di ridacchiare di fronte a certi risultati del pur potente traduttore di Google...

Il frivolo esempio: ruotine eliminare cifre da una stringa

Appartiene all’autobiografia recente. Volevo una routinetta volta a eliminare i caratteri numerici da una stringa. Ed ecco una serie di tentativi infruttuosi di specifiche Sub, prima in VBA poi in Visual Basic 2008, che ho corredato con istruzioni messaggistiche opportune per facilitarne l’esecuzione passo dopo passo a chi legge.

Prima versione

Sub EliminaCifre()

    Dim MiaStr As String, Car As String, i As Integer

    MiaStr = "Amba12raba2345cicci178"

    For i = 1 To Len(MiaStr)

        Car = Mid(MiaStr, i, 1)

        If IsNumeric(Car) Then

            MiaStr = Replace(MiaStr, Car, "")

        End If

        MsgBox("i = " & i & vbLf & "Car = " _

        & Car & vbLf & "MiaStr = " & MiaStr)

    Next

    MsgBox(("Stringa finale: " & MiaStr)

End Sub

Lanciando la procedurina si notano due stranezze inattese (per gente ingenua come molti di noi siamo):

• non tutte le cifre vengono eliminate e l’MsgBox conclusivo proclama “Stringa finale:  ambaraba34cicci8”;
• il ciclo va avanti fino a i = 22 (la Len iniziale della stringa), indicando caratteri vuoti (blank) negli ultimi passaggi.

Dopo riflessione mi sono reso conto che il guaio deriva dal fatto che lunghezza della MiaStr diminuisce di un’unità ad ogni rimpiazzo di una cifra con “” (Replace(MiaStr, Car, “”). La pezza (patch) è presto trovata.

Seconda versione

Sub EliminaCifreBIS()

    Dim MiaStr As String, Car As String, i As Integer

    MiaStr = "Amba12raba2345cicci178"

    For i = 1 To Len(MiaStr)

        Car = Mid(MiaStr, i, 1)

        If IsNumeric(Car) Then

            MiaStr = Replace(MiaStr, Car, "")

            i = i - 1

        End If

        MsgBox ("i = " & i & vbLf & "Car = " _

        & Car & vbLf & "MiaStr = " & MiaStr)

    Next

    MsgBox ("Stringa finale: " & MiaStr)

End Sub

L’aggiunta, evidenziata in giallo, è semplicemente la correzione i = i - 1 ogni volta che una cifra è rimpiazzata. Ci potremmo accontentare, visto che il risultato ora è corretto, anche se resta la seconda anomalia.

Da queste come da altre esperienza si evince facilmente il principio enunciato in apertura, che nel caso del software, tradurrei nella legge seguente:

In Informatica è la Semantica lo scoglio in cui s’infrangono molti prodotti, a causa della discrasia non sempre evitabile fra l’intenzionalità dell’uomo e la fredda, inesorabile logica letterale della macchina.

Visual Studio 2008: mondo nuovo, altra sorpresa

In tale ambiente ho poi testato il precedente programmetto. Funzionava, ma poi pur non essendo un benpensante ho... ben pensato di sostituire Car As String con Car As Char (non supportato in VBA o VB6) più moderno e logico, visto che si tratta di un singolo carattere. Già che c’ero, ho approfittato della possibilità di accedere con un indice a ciascun carattere di una stringa, con Car = MiaStr(i).

Terza versione (VB 2008)

Sub EliminaCifre()

    Dim MiaStr As String, Car As Char, i As Integer

    MiaStr = "Amba12raba2345cicci178"

    For i = 0 To Len(MiaStr) - 1

        Car = MiaStr(i)

        If IsNumeric(Car) Then

            Mid(MiaStr, i, 1) = Replace(MiaStr, Car, "")

            i -= 1

        End If

        MessageBox.Show("i = " & i & vbLf & "Car = " _

        & Car & vbLf & "MiaStr = " & MiaStr)

    Next

    MessageBox.Show("Stringa finale: " & MiaStr)

End Sub

Tutto bene? Macché. L’illusione semantica stavolta naufraga in modo, come sempre, inatteso. Infatti non si procede con tutti i 22 giri del loop For i = 0 To Len(MiaStr) ... Next in quanto ahimè il programma si arresta per errore a run-time sulla tanto ammirata istruzione moderna Car = MiaStr(i), con indicazione di indice fuori dai limiti.

Riflettendo adeguatamente comprendiamo che:

• il ciclo For... To Next del Visual Basic (a differenza di altri linguaggi, credo) valuta una tantum l’espressione all’inizio e ne mantiene il valore in tutto il suo corso (in altri casi questa è una virtù, ma qui ci crea un guaio);
• Mid(MiaStr, i, 1) è permissivo al punto di non dare errore se l’indice va fuori della stringa (semplicemente restituisce un blank); al contrario di Car(i), che invece considera la stringa come un vettore di caratteri.

Soluzione finale

Ne riporto il nocciolo, astenendomi dal commentare altre varianti “moderne”, dicendo solo che alla fine ho adottato un ciclo While ... End While (While... Wend in VBA/VB6) che è immune dalla persistenza della lunghezza imputabile a For... Next e, pertanto, fa sì che MiaStr.Length muti dinamicamente ad ogni giro dell’anello.

   Dim i = 0

   While i < MiaStr.Length

       Car = MiaStr(i)

       CodCar = Char.ConvertToUtf32(Car, 0)

       If Not (CodCar < 48 Or CodCar > 57) Then

           MiaStr = MiaStr.Replace(Car, "")

           i -= 1

       End If

       i += 1

   End While

Il Ribbon personalizzabile di Office 2010

Questa interessante novità si offre come alternativa per utenti “normali” rispetto al sistema di personalizzazione avanzata della barra multifunzione, che, ricordiamo, richiede la creazione a parte di appositi file customUI.xml.

Per consentirne lo studio ho preparato un file PDF, che si può scaricare da:

http://www.giannigiaccaglini.it/download/Nuovo%20Ribbon2010Personalizzabile.pdf

Buona lettura.

Considerazioni fuori programma (rispetto alle macro e all'IT)

Sperando di non disturbare la suscettibilità o la commiserazione di chicchessia, mi permetto alcune osservazioni spicciole su tre celebri antinomie (senza pretesa di essere esaustivo né di aver fatto scoperte originali o peggio di non commettere errori).

Premetto che i vari casi mi paiono afflitti da un limite della logica, almeno “normale” (ossia degli Enunciati) quando pretende di considerare il tempo...

ACHILLE E LA TARTARUGA

Considerare unità di tempo piccole a piacere è legittimo, ma non lo è aggiungerne di sempre più piccole concludendo con MAI. Infatti nel primo caso, per quanto piccoli siano gl’intervalli temporali Achille supererà di certo la tartaruga in un numero finito di essi.

IL CRETESE

Non è possibile, per coerenza, che un perfetto mentitore dica “tutto quel che dico è falso”, potrà semmai affermare “tutto quel che dico è vero”. Dopo di che, sospettato ingiustamente di un  delitto capitale risponderà sì alla domanda “Sei tu il colpevole?”, senza la soddisfazione di poter affermare, sul patibolo, “Muoio per amore della Menzogna!”. [O forse “Muoio per amore della verità” è un’antinomia? Boh].

IL BARBIERE

L’editto “Il barbiere deve radere tutti quelli che non si fanno la barba da soli” presenta almeno un’ambiguità: è lecito farsi radere da un altro? Immaginiamo che alla specifica richiesta di chiarimento – come sempre accade nelle norme giuridiche o assimilabili che richiedono interpretazioni “autentiche” sullo spirito di una legge – il Sovrano cambi la dizione in “Tutti gli abitanti si debbono radere da soli o farsi radere dal barbiere”, che, senza chiarire esplicitamente che cosa deve fare il barbiere,  esclude la possibilità di ricorrere ad altri che non sia il barbiere. A parte il fatto che resta oscura e comunque ardua la possibilità di sanzione, esclusa la fragranza (ma se uno è sbarbato che si fa?), e tralasciando l’ipotesi di un barbiere eunuco o femmina, il punto a mio avviso è che il barbiere ha un duplice ruolo: cittadino e funzionario-barbitonsore (senza essere schizofrenico: tutti hanno ruoli molteplici in un consesso sociale). E scegliendo di radersi da solo, come cittadino, subito DOPO toglie a se stesso, cioè al barbiere, il compito di farlo.

CIRCUITI LOGICI SEQUENZIALI

Mi permetto di insistere coi Logici puri (che finora non mi hanno dato retta...). I circuiti logici sequenziali (elettronici o, persino, implementati con relè e contatti) hanno un comportamento che varia nel tempo, presentando cioè una isteresi appunto temporale. Ne sono esempi noti anche a chi ne ignora le connessioni (di tipo feedback) i circuiti memoria (come i flip-flop) o gli oscillatori. I tecnici per descriverli e progettarli adottano una particolare – ma semplice nei casi elementari - Algebra booleana, in cui sono in gioco NEGAZIONI delle uscite riportate in input. Ad esempio con un X  = not Y ove X e Y sono, rispettivamente l’input e l’output si ottiene sulla carta ma anche di fatto un oscillatore di periodo pari al tempo che separa Y e X.

Dunque “in natura” le antinomie sono di fatto risolte. O no?

Buon 2010 !

P.S. – Aggiungo che l’astrattezza della logica rispetto alla lebenswelt (mondo della vita) si fa sentire anche in altri contesti ove siano in gioco verbi riflessivi. Provare per ridere, con “sputarsi” o, peggio, con “masturbarsi”. O, in genere, con verbi che ammettono solo forma riflessiva...

ANNUNCIO AI LETTORI CHE NON LO TROVAVANO PIU':

Il libro EXCEL E OFFICE VBA è stato ristampato: http://www.hoepli.it/libro/excel-office-vba.asp?ib=9788820335373&pc=00002200

Novità Office 2010 su VBA e Ribbon personalizzabile

E ahimè perdura il BUG di FileSearch (v. in fondo al post)

Una domanda un po’ angosciante che ci poniamo tutti noi che amiamo le macro è la seguente: il linguaggio VBA verrà mantenuto? La risposta, a quanto ho potuto constatare sulla BETA che ho scaricat, è affermativa, garantendo così la compatibilità con gli attuali modelli dotati di macro. Invece si direbbe dubbia l’idea che il VBA possa essere migliorato e potenziato, magari in accordo col Visual Basic .NET...

In attesa di notizie più precise riferisco qui la curiosa avventura di un beta tester di Office 2010 (inglese), che inizia con una scoperta preoccupante, che però poi termina con un lieto fine. In due parole, il nostro amico dapprima non riesce a trovare la scheda (tab in inglese) relativa alle macro (Sviluppo, in Office 2007, peraltro anch’essa da visualizzare esplicitamente anche nel vecchio mondo) né a zompare nell’Editor Visual Basic con la familiare scorciatoia Alt+F11 [Ma qui il ns. amico si sbaglia! G.G.].

Ma niente paura!, la buona notizia è che ora la barra multifunzione (Ribbon) è personalizzabile con semplici mosse direttamente dal Ribbon stesso, col lieto fine di riscoprire la tab relativa alle macro.

Ed ecco le manovre necessarie:

1. Clic destro in qualunque punto del Ribbon, che apre varie opzioni come le precedenti Aggiungi alla barra di Accesso rapido, Riduci a icona la barra multifunzione ecc. più la nuova Personalizza la barra mutifunzione (Customize the Ribbon);
2. Scegliere quest’ultima, che a sua volta apre un elenco che comprende tutte le tab standar e pulsanti vari tra cui quelli per Aggiungere una nuova Tab, Aggiungere un nuovo Gruppo, Rinominare;
3. Le tab vecchie e nuove sono raffigurate in modo gerarchico (arborescente con icone “+“, cliccando sulle quali si aprono altri sottomenu relativi ai singoli comandi;
4. In particolare l’opzione che più interessa l’autore (e molti di noi) è Sviluppo (Developer).

Scegliendolo si ottiene, perlomeno in prima battuta, la visualizzazione della scheda Sviluppo solo un po’ diversa da quella attuale.

A questo punto qualcuno dirà “niente di nuovo sotto il sole Office...”. Così descritta la storia infatti rassomiglia molto a quella che si vive in Office 2007, agendo nelle Opzioni di Word o di Excel > Personalizzazioni... per cui la novità sembra consistere solo nella comodità del clic destro direttamente sul Ribbon. Non mi sbilancio del tutto, ma sono propenso a scommettere che si tratti di inedite possibilità di modifica in precedenza scomode se non impossibili.

La questione si può dirimere dal vivo, per farsene un’idea diretta, sulla beta di Office 2010 pro, scaricabile dai link seguenti, entrambi finora relativi all'edizione inglese:

www.microsoft.com/office/2010/en/default.aspx

www.microsoft.com/italy/office2010/index.aspx

Aggiungo ora una MIA impressione iniziale sulla beta testè caricata. Il layout del Ribbon è un po' cambiato, direi razionalizzato. In particolare l'icona Office è sparita e al suo posto si ha un (più classico) menu File. Per il resto, i comandi sembrano identici anche se a volte diversamente dislocati e raffigurati. Anche nel resto non si riscontrano innovazioni, a parte un accresciuto numero di librerie in VBA (quelle attivabili con Strumenti > Riferimenti...) quelle che, diciamolo francamente, solo utenti ultraesperti adottano. Le opzioni classiche sembrerebbero immutate - tabelle, font, cornici, forme e clipArt, classi e numero di funzioni - tutto (o quasi?) come prima... 

Ma è presto per parlare di delusione, anzi penso di sbagliare.

IL PERDURANTE BUG DI FILESEARCH 

L'ho subito segnalato su http://connect.microsoft.com scoprendo di averlo già fatto un paio di anni fa (ve n'è traccia su tale sito, con risposte che rimandano la palla a un altro team...). Non è successo nulla, visto che tale bug rimane pure in Office 2010. Ma ecco di che si tratta:

L’utile comando VBA Application.FileSearch per la ricerca di archivi, presente in Office 2003, è scomparso in Office 2007 e 2010 (beta). Con aspetti imbarazzanti se non grotteschi:

- Se si digita “Application.” “FileSearch” non compare nella lista dell’intelliusense;

- se si insiste con Application.FileSearch e relativi metodi/proprietà tutto sembra accettato ma a run-time si ha ERRORE, pertanto FileSearch non si può utilizzare e falliscono precedenti modelli creati con Office 2003.

Ecco un esempio del genere:

Sub Cercafiles()

  cartella = Range("A1").Value

  nome = Range("B1").Value

  este = Range("C1").Value

  Dim nomefile As String

  With Application.FileSearch

    .NewSearch

    .LookIn = cartella & ""

    .SearchSubFolders = True

    .Filename = "" & nome & "." & este & ""

    If .Execute(SortBy:=msoSortByFileName, _

    SortOrder:=msoSortOrderAscending) > 0 Then

      MsgBox "Ci sono " & .FoundFiles.Count & " file(s) trovati."

      For i = 1 To .FoundFiles.Count

        nomefile = .FoundFiles(I)

        ActiveCell(i) = nomefile

      Next i

    Else

      MsgBox "File(s) non trovato."

    End If

  End With

End Sub

Utile, no? Però funziona solo con Office 2003.

La cosa imbarazzante...

 ... se non ridicola è che non solo tutte le keyword predette vengono regolarmente tradotte con le maiuscole al posto giusto (es. “fiLesEArCH” => “FileSearch”, “neWseaRCh” => “NewSearch”) ma la Guida riporta una gran copia di esempi specifici, NESSUNO dei quali funziona, dopo Office 2003.

L’utile comando VBA Application.FileSearch per la ricerca di archivi, presente in Office 2003, è scomparso in Office 2007 e 2010 (beta). Con aspetti imbarazzanti se non grotteschi:

- Se si digita “Application.” “FileSearch” non compare nella lista dell’intelliusense;

- se si insiste con Application.FileSearch e relativi metodi/proprietà tutto sembra accettato ma a run-time si ha ERRORE, pertanto FileSearch non si può utilizzare e falliscono precedenti modelli creati con Office 2003.

Ecco un esempio del genere:

Sub Cercafiles()

  cartella = Range("A1").Value

  nome = Range("B1").Value

  este = Range("C1").Value

  Dim nomefile As String

  With Application.FileSearch

    .NewSearch

    .LookIn = cartella & ""

    .SearchSubFolders = True

    .Filename = "" & nome & "." & este & ""

    If .Execute(SortBy:=msoSortByFileName, _

    SortOrder:=msoSortOrderAscending) > 0 Then

      MsgBox "Ci sono " & .FoundFiles.Count & " file(s) trovati."

      For i = 1 To .FoundFiles.Count

        nomefile = .FoundFiles(I)

        ActiveCell(i) = nomefile

      Next i

    Else

      MsgBox "File(s) non trovato."

    End If

  End With

End Sub

Utile, no? Però funziona solo con Office 2003.

La cosa imbarazzante...

 ... se non ridicola è che non solo tutte le keyword predette vengono regolarmente tradotte con le maiuscole al posto giusto (es. “fiLesEArCH” => “FileSearch”, “neWseaRCh” => “NewSearch”) ma la Guida riporta una gran copia di esempi specifici, NESSUNO dei quali funziona, dopo Office 2003.

Un alibi (quasi?) perfetto con una macro Word [ + una chicca Excel ]

Questa ipotesi audace trae ispirazione da un noto caso giudiziario attuale, ove i periti, informatici, hanno scagionato l’indagato avendo constatato che un documento al quale stava lavorando  risultava ripetutamente salvato nel periodo in cui il crimine fu perpetrato.

La mia opinione è che tale perizia costituisca un alibi inoppugnabile... E tuttavia, lavorando di fantasia, ipotizzo una possibilità alternativa, beninteso da parte di una mente diabolica-ma-non-troppo. Dicendo “ma-non-troppo” ho in mente l’ideatore di un delitto perfetto o quasi basato sulla macro VBA seguente, incorporata nel documento .doc in questione:

Sub Alibi()

  ' k = 1 'Usato per debug

  While True

    MsgBox "Passaggio numero " & k 'Usato per debug

    ' k = k + 1 'Usato per debug

    With Selection.Find

      .Text = "Rossini"

      .Replacement.Text = "####"

      .Execute Replace:=wdReplaceAll

    End With

    ' Pausa... (soluzione rudimentale)

    ' For i = 1 To 200000000

    ' Next

    Attesa t:=Rnd * 50 ' In fase debug: 10 o 5

    With Selection.Find

      .Text = "####"

      .Replacement.Text = "Rossini"

      .Execute Replace:=wdReplaceAll

    End With

    ThisDocument.Save

  Wend

End Sub

Sub Attesa(t As Double)

  Dim QuestiSec As Double

  QuestiSec = Timer

  While Timer < QuestiSec + t

  Wend

End Sub

Tale macro per ipotesi lavora in un documento che inizia come segue:

Tesi con alibi

By Gioacchino Rossini

ecc. ecc.

Inizialmente ho previsto 4 passaggi (con indice k), ciascuno composto di due fasi che prevedono la sostituzione di “Rossini” con 4 cancelletti e, rispettivamente, il ripristino di “Rossini”, quindi il salvataggio del file (di fatto immutato, ma – si badi bene – non credo che ciò non lasci traccia). Ogni ciclo di indice k termina con una pausa rozzamente emulata con un i che varia da 1 a 200000000.

Successivamente ho sostituito il (rozzo) ciclo di indice k con un loop senza fine While True... Wend inserendo un ritardo di durata casuale che sfrutta la routine Attesa a sua volta basata sul codice Timer. In tal modo si evita che i periti si insospettiscano constatando salvataggi a periodi fissi.

La macro non merita altri commenti se non quelli inseriti, comunque funziona. L’ipotetico criminale per sfruttarla dovrebbe:

1.       Lanciarla prima di uscire;

2.       Compiere la nefandezza (non cruenta, si spera!);

3.       Tornare a casa;

4.       Bloccare la macro con Ctrl+Break;

5.       Eliminarla (!!!);

6.       Proseguire con modifiche e salvataggi manuali per un tempo adeguato.

Un amico cui ho sottoposto la cosa mi ha obiettato che forse cancellando la macro, ne resterebbe traccia, chiedendomi se c'e un modo per far girare la macro su chiavetta USB.

Ecco cosa gli ho risposto:

Sulla seconda ipotesi non ho al momento elementi (ci penserò); comunque, ripeto, la macro fa parte del documento ma si trova nell'Editor Visual Basic, inoltre non penso che le tracce sul disco contengano le versioni integrali precedenti ma solo, appunto, tracce sintetiche del documento (che ovviamente è salvato come .doc in conformità all'ultimo salvataggio effettuato). Se ora, al ritorno dal delitto il delinquente non solo elimina la macro nell'Editor VBA ma compie ripetuti salvataggi a mano del documento, è perlomeno difficile che periti non dotati di qualità extrasensoriali possano recuperare il codice criminale...

Se qualcuno s’intende di tracce si faccia vivo.

La chicca per Excel (un modellino didattico)

Tutti o quasi conoscono la serie dei conigli immortali dell’estroso matematico pisano Fibonacci, perciò mi limito a ricordare che partendo con una coppia di ... conigli, pardon!, numeri 1 e 1 ogni successivo numero si ricava sommando i due precedenti. Ottenerla con formule su un foglio elettronico è un gioco da ragazzi.

Forse però non tutti sanno che dividendo ciascun membro della serie per il successivo si ottiene un’approssimazione sempre più precisa della sezione aura, un numero “magico” che a sua volta ricorre in molti campi (v. Wikipedia) espresso dalla formula che do senz’altro in stile excelliano:

=(RADQ(5)-1)/2

In soldoni, limitandosi alle cifre significative che Excel fornisce, trattasi di
0,618033988749895

Nel modellino didattico che propongo si scelgano due celle a piacere ma diciamo in cima alle colonne D ed E denominandole SezioneAura e, rispettivamente, Epsilon. Va da sé che la prima conterrà la formula o il valore omonimi, mentre nella seconda ospiterà un numero molto piccolo, diciamo 0,00000000001 (stiamo sempre, per forza di cose, nei limiti imposti da Excel).

Ciò fatto, inseriamo nelle colonne A, B e C formulette opportune, ottenendo risultati del genere seguente:

	A	B	C
1	1
2	1
3	2	0,5	FALSO
4	3	0,666666667	FALSO
5	5	0,6	FALSO
6	8	0,625	FALSO
7	13	0,615384615	FALSO
8	21	0,619047619	FALSO
9	34	0,617647059	FALSO
10	55	0,618181818	FALSO
11	89	0,617977528	FALSO
12	144	0,618055556	FALSO
13	233	0,618025751	FALSO
14	377	0,618037135	FALSO
15	610	0,618032787	FALSO
16	987	0,618034448	FALSO
17	1597	0,618033813	FALSO
18	2584	0,618034056	FALSO
19	4181	0,618033963	FALSO
20	6765	0,618033999	FALSO
21	10946	0,618033985	FALSO
22	17711	0,61803399	FALSO
23	28657	0,618033988	FALSO
24	46368	0,618033989	FALSO

Le formule nelle prime due colonne, ovviamente da introdurre a partire dalla riga 3 sono a questo punto scontate, comunque fornisco la prima coppia, che va more solito ricopiata verso il basso:

A3: =A1+A2

B3: =A2/A3

E la formula che parte in C3? I più accorti se ne saranno... accorti da soli. Ad ogni buon conto mi voglio rovinare, offrendo le prime tre:

C3: =ASS(B3-SezioneAura) <=Epsilon

C4: =ASS(B4-SezioneAura) <=Epsilon

C5: =ASS(B5-SezioneAura) <=Epsilon

Palesemente, danno una sfilza di valori logici FALSO nelle prime 27 celle, ma a partire dalla 28.ma comincia a spuntare il sospirato VERO:

	A	B	C
24	46368	0,618033989	FALSO
25	75025	0,618033989	FALSO
26	121393	0,618033989	FALSO
27	196418	0,618033989	FALSO
28	317811	0,618033989	VERO
29	514229	0,618033989	VERO
30	832040	0,618033989	VERO

Formattazione condizionale

Sicuramente tutti avranno notato gli sfondi colorati che evidenziano viepiù l’agognato raggiungimento dell’approssimazione della dorata sezione. Sono stati ottenuti sfruttando la formattazione indicata nel titolo. Lascio per esercizio l’impostazione de formato condizionato di colonna C, mentre descrivo i passi per ottenere quella in colonna B.

1.       Selezionare l’intero intervallo, diciamo C3:C40 (ex abundantia);

2.       Attivare il comando Formattazione condizionali;

3.       Opzione Nuova regola poi Utilizza una formula;

4.       Nella susseguente casella ad hoc inserire la seguente formula:
=ASS($B3-$D$2)<=$E$2

5.       Meditare, gente...

 ?>

SEGNALAZIONE UTILE. L'amico Emanuele (Mattei! chi altro potrebbe essere?) ha varato il sito professionale www.donetromacesta.org al quale ho pensato di offrire un piccolo contributo su Excel + VBA. Eccone il link:

Controlli e ActionPanes nei VSTO di Word

Incorporare controlli su un foglio di lavoro è una pratica accettabile, che tra l’altro ha il pregio dell’immediatezza, laddove sono posti accanto ai dati da elaborare con la macro (o il codice “managed” in ambiente VSTO, Visual Studio Tools per Office). Una controindicazione è, parlando in generale, il fatto che i controlli di tipo ActiveX e assimilati compaiono anche in stampa, né sembra possibile occultarli anche solo pro tempore. Si provi infatti la seguente macro, che ipotizza la presenza sul foglio di lavoro sia di controlli “classici” di Excel che di tipo ActiveX:

Sub NascondiSvela(Vis As Boolean)

   For Each Sh In Me.Shapes

    Sh.Visible = Vis

  Next

End Sub

Sub Stampa()

  NascondiSvela False

  Me.PrintPreview

  NascondiSvela True

End Sub

Come non ci vuol molto a capire la prima Sub al primo richiamo con Vis = False nasconde tutte le forme, inclusi i controlli ActiveX, anch’essi assimilati a Shapes e inclusi in tale insieme, mentre con Vis = True li visualizza tutti di nuovo. Pertanto l’istruzione centrale di anteprima (o di stampa tout court) dovrebbe essere corretta, giusto? Sbagliato. I controlli classici non sono stampati ma quelli ActiveX anche se messi fuori vista vengono di fatto stampati.

Tuttavia l’inconveniente può essere ovviato (o inesistente) in Excel, dove esistono più fogli di lavoro, basta che i dati da stampare si trovino su un foglio (ad esempio riepilogativo) esente da controlli incorporati.

Il caso Word (con difficoltà iniziali varie)

La situazione è meno felice in Word, ove il documento è unico, soprattutto perché qui non esistono i controlli-classici di Excel, ma soltanto gli ActiveX. Non occultabili a monte della stampa, come già visto con Excel. La situazione appare imbarazzante quando si lavora nel mondo VSTO. Una soluzione brutale l’avrei anche trovata e la riporto in fondo al presente post, ma non pare troppo soddisfacente. Prima di proseguire trovo importante una premessa. I VSTO tradiscono diverse aspettative per chi pensa di ottenerne una sorta di applicativi office-oriented. Ecco i punti più imbarazzanti:

• In Excel, il mancato supporto di funzioni d’utente (UDF, User Defined Function) implementate con codice .NET;
• In Word, all’impossibilità di associare a routine scorciatoie di tastiera – comode e “naturali” visto che la digitazione qui regna sovrana - si unisce l’assenza di tali routine nel modulo Normal.dot, che ne consente l’utilizzo con qualunque documento.

In questi casi (e altri di cui non mi sovviene) l’imbarazzo deriva dal fatto che tali preziose funzionalità restano possibili con il buon vecchio sistema di macro VBA anche con un “applicativo” VSTO. Ma in tal modo la security del managed code va un poco a farsi benedire. O no?

Rimanendo a quel che passa il convento Word VSTO, che strumenti ci offre per ottenere un qualche MioDoc.xlx che abbia un minino di valenza applicativa, magari “dedicata” e semichiusa? A dire il vero, le possibilità sono notevolissime, basti pensare al trattamento di archivi Open XML su disco con la specifica API SDK 1.0 + LINQ o la nuova SDK 2.0 “strongly typed”. Prossimamente conto di offrirne almeno un esempio, in cui un intervallo o una tabella Excel vengono importati nel documento Word. Ma la domanda cruciale è la seguente:

Come lanciare in modo semplice funzionalità del genere?

Confesso che all'inizio non ho avuto modo né tempo per esaminare soluzioni avanzate, in primo luogo un Ribbon opportunamente personalizzato. Fra le “semplici” evocate testé dalla domanda comincio con l'annoverare due possibilità:

Ø  Controlli ActiveX incorporati in cima al documento, tipicamente un paio di pulsanti, Button1 e Button2;

Ø  La finestra Azione documenti (Actions pane).

Il secondo metodo si presenta più allettante, in quanto tale pannello si colloca alla destra del documento e promette di scatenare le azioni da noi desiderate evitando di incorporare alcunché nel documento. Ma qui cominciano le dolenti note, almeno in prima battuta (per fortuna, in fondo al post c'è il lieto fine):

1)      Non è possibile caricare l’Actions pane nell’IDE VSTO di Word, lo si può fare solo con il Word “normale”;

2)      esso non viene in alcun modo “visto” da macro VBA, contrariamente a quel che avviene nel mondo VSTO.

3)      Nel Word normale non c’è alcun verso di inserire controlli nell’Actions pane, mentre l’operazione si direbbe consentita in ambiente VSTO, perché all'inizio non si riesce a farlo (ma il modo esiste, v. alla fine!)

Le operazioni di cui al primo punto sono tediose e per pigrizia non le riporto in dettaglio. Dico solo che si parte col pulsante Office, attivando Opzioni di Word... quindi Componenti aggiuntivi ecc. Dopo di che per visualizzare il sospirato pannello si agisce sulla scheda Sviluppo seguita da Pacchetti di espansione e via di seguito, operazioni queste fattibili pure nei VSTO (ma che confusione, non è vero?).

Un po’ di codice managed

Nei VSTO di Word tutte le routine, di regola, sono racchiuse nella classe ThisDocument. Per non scontentare impazienti e frettolosi riporto subito i miei primi tentativi esplorativi, riusciti.

Public Class ThisDocument

    Private Sub ThisDocument_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

        If MessageBox.Show("Cucù, sono " & Me.Name & _

         vbLf & "Due più due = quattro?", , MessageBoxButtons.YesNo) _

         = DialogResult.Yes Then

            MsgBox("Bravo! Sette più")

        End If

        ActiveWindow.ActivePane.View.Zoom.Percentage = 100

        ActionsPane.Show()

    End Sub

    Private Sub ThisDocument_Shutdown(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Shutdown

    End Sub

    Private Sub ActionsPane_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles ActionsPane. Click

      MsgBox("Action pan cliccato!")

    End Sub

    Private Sub ActionsPane_DoubleClick(ByVal sender As Object, ByVal e As System.EventArgs) Handles ActionsPane.DoubleClick

        MsgBox("Hai dato un doppio clic sull'ActionsPane. Bravo!")

    End Sub

    Private Sub ActionsPane_MouseDoubleClick(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles ActionsPane.MouseDoubleClick

        MsgBox("Hai dato un doppio clic. Bravo!")

    End Sub

    Private Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click

        MsgBox("Bubbusette!")

    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click

        MsgBox("Bubbuotto!")

    End Sub

End Class

Premesso che in testa al documento erano stati inseriti due controlli Button (scegliere nella sezione Controlli comuni o anche Windows Form), le routine messaggistiche ad essi abbinate sono banali, anzi ridicole. Più interessante la Sub dell’evento ThisDocument_Startup ovviamente equivalente alla Document_Open di Word normale entrambe scatenantesi al caricamento del documento. Interessanti e, come ripeto, possibili solo coi VSTO non tanto le prime istruzioni di squallido umorismo bensì le ultime due, entrambe richieste per visualizzare il sospirato riquadro di cui si parla. Richieste e, direi, indispensabili affinché abbiano concreto utilizzo le altre, relative a due degli eventi dell’oggetto ActionsPane. Questi sono una vera caterva, come è facile scoprire.

Io mi sono limitato ai tre più semplici, abbinando a ciascuno stupidissimi messaggi. Mi sarei anche accontentato di surrogare con essi –nell’incapacità autolesionisticamente ammessa di inserire controlli nel fatidico pannello – un paio di funzionalità magari anche potenti & evolute. Purtroppo si incappa in altre due non del tutto piacevoli sorprese:

• L’evento Click predomina sugli altri due, e li “oscura”per cui, volendoli usare occorre rinunciare al Click;
• In compenso gli altri due sono sinonimi per cui una doppia cliccata li scatena entrambi, uno di seguito all’altro (questo punto non è grave né del tutto inatteso, resta solo la domanda sul motivo per cui un medesimo evento abbia due nomi distinti, sottigliezza che non sono in grado di comprendere...).

Rimanendo nel quadro dei tentativi iniziali ecco poi, sotto forma di macro VBA, il codice brute-force per evitare di stampare i due pulsanti ipotizzati in cima al documento, nelle sue prime due righe:

Sub MiaStampa()

  Selection.HomeKey Unit:=wdStory

  Selection.MoveDown Unit:=wdLine, Count:=2, Extend:=wdExtend

  Selection.Cut

  MsgBox "Adesso stampo!"

  . . .  istruzioni di Stampa . . .

  Selection.Paste

End Sub

La brutalità dipende dal taglio (Cut) delle prime due righe, previa selezione delle medesime e, con esse, dei due bottoni. Niente paura, perché a valle della stampa essi vengono re-incollati (Paste)assieme alle due righe. Addirittura la routine funziona anche se evocata da uno dei pulsanti. Provare per credere con:

Private Sub CommandButton1_Click()

  MiaStampa

End Sub