ULTIM'ORA. Sto studianndo WPF (Windows Presentation Manager) che in Visual Studio permette di creare finestre molto più multimediali rispetto alle Winndows Form. Questa mia creatura sviluppata in occasione dei Mondiali sudafricani sfrutta la griglia (Grid) WPF con caselle di testo disposte secondo lo schema a piramide rovescia, a partire dai QUARTI di finale. Secondo un algoritmo da me più volte sfruttato con Excel + VBA il primo pulsante avvia una simulazione basata su numeri randommizzati attorni ai VALORI stimati. I nomi delle squadre sono generici, i valori sono livellati sul 6 ma gli uni e gli altri si possono modificare prima del clic. Un'imperfezione (che un bel dì sanerò, ma non so quando...) impedisce di tener conto di  modifiche ai valori successive alla prima, comunque cliccando sul secondo pulsante ci si mette una pezza.

Scaricare da:

http://www.giannigiaccaglini.it/download/FinaliCampionato.zip

Tornando al Clock, si tratta di un trucco vergognoso, ma stavolta la vergogna mi pare pertinente a pur nobili produttori di software. Applicativi due tipi, principalmente, entrambi "a scadenza":

- versioni beta, inclusa l'ultima di Office;

- antivirus, perlomeno quello molto titolato che io uso (ma dico il peccato, non il peccatore).

Come si sa, gli uni e gli altri, dopo i due-tre mesi previsti si disattivano. Ma, a onta degli sviluppatori che non l'hanno previsto (!!) basta retrodatare l'orologio di sistema e tutto procede regolarmente! Il dirty trick testé rivelato forse esclude sì e no i bambini in tenera età... Per cui uno si chiede: possibile che programmatori superesperti non abbiano escogitato qualche misura più robusta ma semplice, come tenere sul LORO sito, un database degli utenti registrati con le rispettive scadenze?

Inconvenienti collaterali alla retrodatazione? Alemeno due:

- la posta in partenza con data sbagliata, per cui il destinatario la trova in fondo e non in cima all'Inbox;

- applicazioni Excel basate sulla data corrente giusta (tipicamente, usando la funzione =NOW() e simili e formule correlate).

Con un po' di pazienza il rimendio è presto trovato, basta rimettere a posto il Clock! Ma va? Ma sì. Nel primo caso l'antivirus non fa una piega, visto che la sua protesta si ha solo all'avvio di Windows. E con Excel? La risposta è quella che tutti si attendono: si deve PRIMA aprire Excel, POI aggiustare l'orologio.

Il post cui mi riferisco è quello in cui ho ideato una macro per Word in grado di salvare a intervalli dati un certo file .doc. Così il criminale che utilizzasse questo trucchetto potrebbe assentarsi per compiere il misfatto dichiarando: "Ma in quel frangente stavo lavorando a quel certo documento...".

Il post in parola è visitabile all'URL seguente:

http://blog.shareoffice.it/giannigiaccaglini/archive/2009/10/12/10256.aspx

Tempo fa ho avuto un ripensamento, anzi due:

• ma non sarebbe più comodo, per il ns. poco raccomandabile tipo (che magari è solo un/una adultero/adultera, non necessariamente un assassino) RETRODATARE il clock del PC semplicemente al rientro dal misfatto, continuando a lavorare per un  tempo pari a quello dell'assenza quindi ripristinando l'orologio, diciamo così fischiettando come se nulla fosse stato?
• ma siamo sicuri che ripetuti salvataggi lascino tracce in un (per me misterioso...) qualche file log del sistema operativo?

Dubito quin sul secondo punto. Al più la traccia potrebbe essere la data dell'ULTIMO salvataggio, un po' poco per un alibi serio, no? Quanto al primo non penso proprio che i famosi periti di un tuttora ben noto processo sarebbero stati in grado di accorgersi dell'inganno, che - si badi bene ! - potrebbe essere espletato anche da un utente di medio calibro, contrariamente all'altro sofisticato espediente VBA.

[Ripensandoci , il nostro cattivo soggetto potrebbe salvare file distinti , di vario tipo .doc oppure .xls ecc.]

In attesa di ricevere riscontri da esperti VERI di Windows mi permetto di dire che i sullodati periti non erano poi così ferrati: infatti non hanno preso in considerazione l'alternativa che a un distrattone come me non era passata per la capa. La quale vanifica le conclusioni loro come quelle, di segno contrario, dei periti precedenti. Forse era meglio tacere, dichiarando che in quella questione, come del "diman" della melanconica poesia di Lorenzo il Magnifico (*), "non si aveva certezza"...

(*) Promemoria per liceali falliti:

Quant'è bella giovinezza

che si fugge tuttavia.

Chi vuol esser lieto, sia.

Del diman non v'ha certezza.

Due trucchi per Userform

Si tratta di due sciocchezzuole, però del tipo “toh, chi ci avrebbe pensato?”...

Primo trucco: pulsanti “in cascata”

Questa ideuzza mi è venuta esaminando una soluzione implementata mediante le modernissime finestre WPF, ossia basate sulla spettacolare e multimediale tecnologia Windows Presentation Foundation. In quel caso si aveva una serie di pulsanti di cui di volta in volta veniva fatto emergere in primo piano quello richiesto dal contesto.

Ovviamente niente del genere è possibile con le normali Form, men che meno con le semplici UserForm che ci passa il convento VBA. Giusto? Non del tutto, almeno nell’esempietto che vado a illustrare. L’ipotesi è di aver a che fare con due (o più) pulsanti uno soltanto dei quali va sottoposto all’utente, di volta in volta. Il trucco è presto detto: rendere visibili, di volta in volta, soltanto quello che occorre, evitando così tediosi switch booleani.

Si tratta della proprietà Visible da porre =False o =True secondo necessità. L’alternativa, va ricordato, è l’attivazione o meno della proprietà Enabled, comunque nell’esempio che sto per proporre ho inoltre previsto di sovrapporre i pulsanti in guisa tale che uno soltanto (tra quelli che interessano) sia in vista, ergo concretamente a disposizione dell’utente.

Ed ecco le mosse da compiere:

1. Creare una Userform, dotandola di due pulsanti CommandButton1 e CommandButton2 di dimensioni identiche, aventi etichetta (Caption) “Primo” e, rispettivamente, “Secondo”;
2. Trascinarli facendo in modo che il primo si sovrapponga al secondo;
3. Aggiungere un controllo Label1 etichettato “FINE LAVORI”;
4. Inserire il codice macro seguente.

Private Sub CommandButton1_Click()

  If MsgBox("Vuoi eseguire il PRIMO lavoro?", vbQuestion + vbYesNo, "") = _

  vbNo Then Exit Sub

  PrimoLavoro

  CommandButton1.Visible = False

  CommandButton2.Visible = True

End Sub

Private Sub CommandButton2_Click()

  If MsgBox("Vuoi eseguire il SECONDO lavoro?", vbQuestion + vbYesNo, "") = _

  vbNo Then Exit Sub

  SecondoLavoro

  CommandButton2.Visible = False

  If MsgBox("Vuoi eseguire di nuovo il PRIMO lavoro?", vbQuestion + vbYesNo, "") = _

  vbYes Then

    CommandButton1.Visible = True

    Exit Sub

  End If

  Label1.Visible = True

End Sub

Le generiche routine PrimoLavoro e SecondoLavoro potrebbero essere del tipo seguente (mentre saranno ovviamente adattate ai casi singoli):

Sub PrimoLavoro()

  MsgBox "Ora eseguo il primo lavoro", vbInformation, ""

End Sub

Sub SecondoLavoro()

  MsgBox "Ora eseguo il secondo lavoro", vbInformation, ""

End Sub

Le varie routine parlano da sole e sono di agevolissima sperimentabilità pertanto mi limito a dire che, c.v.d., l’utente dispone inizialmente del solo pulsante “Primo”, cliccando il quale se a.d.r. (a domanda risponde, come nei verbali tribunalizi) Yes viene lanciata PrimoLavoro, al che il primo pulsante è occultato e, alla comparsa del secondo... A tutti sarà insomma palese che se si verifica il duplice assenso dell’utilizzatore a PrimoLavoro segue SecondoLavoro e la (quasi-farsa?) si conclude con la visualizzazione della scritta (Label1.Visible=True) “FINE LAVORI”.

Chicca finale. La nostra Userform potrebbe essere lanciata – in modo atipico e comunque poco noto – tramite un hyperlink come questo posto, diciamo, sul primo foglio di lavoro:

Il codice che si scatena cliccandovi sarà il seguente, relativo all’evento FollowHyperlink da inserire nel modulo Foglio1 dell’Editor VBA:

Private Sub Worksheet_FollowHyperlink(ByVal Target As Hyperlink)

   Load UserForm1

   UserForm1.Show

End Sub

Secondo trucco: controlli filtrati per nome

Si abbia una UserForm dall’aspetto, grossomodo, seguente:

In fondo ad essa, com’è ovvio, si trova un CommandButton1 etichettato “OK”, inoltre dei vari controlli sulla destra quelli contraddistinti  con “II” sono delle ComboBox e le due II imitano alla grossolana le relative frecciotte. Ciascuna di tali caselle a discesa è caratterizzata dalla proprietà RowSource, pari rispettivamente a “TabellaCat” e “TabellaTipoLav”. Si tratta di due intervalli del foglio di lavoro così pre-denominati contenenti intuibili codici di categoria e di tipo di lavoro. In tal modo nelle due combo box si può attingere a tali elenco scegliendo quel che si desidera.

Dimenticavo di dire che la nostra Userform è una maschera di input. Per semplicità si pensi che il pulsante OK ne inserisca i dati in una riga aggiuntiva di una certa Tabella1 del foglio, ma solo a patto che – come minimo – tutte le caselle di testo e i combo box non siano vuote. L’inghippo che nasceva derivava, tra l’altro, dal fatto che nelle UserForm non esiste un modo standard per selezionare controlli funzionalmente omogenei. Nel nostro caso la omogeneità “funzionale” accomuna caselle e combo box, escludendo invece le label e il commandbutton.

In altre occasioni me la cavavo con cose del genere:

For Each Ctrl In Me.Controls

  ' Esplora solo le caselle di testo

  If Left(Ctrl.Name,7) = "TextBox" Then

    MsgBox Ctrl.Name

  End If

Next

Nel caso in questione, inoltre, volevo segnalare all’utente il significato del dato, che di fatto viene indicato dalle varie etichette sulla sinistra (DATA, CLIENTE, ecc.). La soluzione è scaturita dalla nozione seguente, che facilmente si ignora o si dimentica:

i controlli di una UserForm si possono individuare non solo con l’indice (numero) ma anche mendiante il loro rispettivo nome.

Insomma se la casella di testo del cliente è il quarto controllo ed ha nome TextBox2 essa può essere indirizzata con Controls(4) o, indifferentemente, con Controls(“TextBox2”).

La soluzione. Consiste nell’adottare due vettori (Array) correlati e opportunamente riempiti, relativi l’uno ai (soli) controlli Textbox e Combobox, l’altro ai corrispettivi nomi di dato (espressi dalle etichette, peraltro indipendentemente da queste).

Senza ulteriori indugi ecco la macro dell’evento scatenato dal pulsante OK.

Private Sub CommandButton1_Click()

  ' Definisci NuovoRec la riga sotto l’ultima di Tabella1

  Dim NuovoRec As Range, CellaRec As Range

  With Range("Tabella1").End(xlDown).Offset(1)

    Set NuovoRec = Range(.Cells(1), .Cells(1, 7))

  End With

  ' Vettore nomi controlli di input

  NomiControlli = _

  Array("TextBox1", "TextBox2", "ComboBox1", "ComboBox2", "TextBox3")

  ' Vettore nomi dei corrispondenti dati di Tabella1

  NomiVariabili = _

  Array("DATA", "CLIENTE", "CATEGORIA", "TIPO LAVORO", "IMPORTO")

  Dim NomeCtrl As String, NomeVariab As String

  Dim i As Integer

  ' Verifica che tutti dati immessi non siano nulli

  For i = 0 To UBound(NomiControlli)

    NomeCtrl = NomiControlli(i)

    NomeVariab = NomiVariabili(i)

    If Controls(NomeCtrl).Text = "" Then

      MsgBox "Il campo " & NomeVariab & " DEVE essere riempito!"

      Exit Sub

    End If

  Next

  ' Trasferimento dei dati della maschera nel NuovoRec

  For i = 0 To UBound(NomiControlli)

    NomeCtrl = NomiControlli(i)

    NuovoRec(1, i + 1).Value = Controls(NomeCtrl).Text

  Next

End Sub

Commenti essenziali, per gli esperti cui mi rivolgo. Sul foglio di lavoro – quello in cui viene lanciata la nostra Userform, con un pulsante ivi incorporato o con l’hyperlink del primo trucco – si abbia una Tabella1 così denominata e dall’aspetto seguente:

Eccetera.

 Si tratta di un oggetto ListObjest ossia, per intenderci, del tipo che fa sì che inserendo nuovi dati nella riga immediatamente sottostante essa viene automaticamente “arruolata”, ergo inclusa nel nome “Tabella1” (la parte sotto le intestazioni, per la cronaca).

Qui giunti per il buon intenditore cui mi rivolgo non spendo altre chiacchiere salvo far notare che l’ultimo ciclo For i = 0 To Ubound(NomiControlli)... Next sostituisce, sinteticamente, le singole istruzioni in un primo tempo adottate:

NuovoRec(1, 1) = TextBox1.Text

NuovoRec(1, 2) = TextBox2.Text

NuovoRec(1, 3) = ComboBox1.Text

Eccetera 

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: