Technology Experience
Senza categoria

[Mercurial.4] Mercurial: icone dei files, cancellazione repository e plug-in per Visual Studio 2005/2008/2010

A cosa serve TortoiseHG Overlay Icon Server ?
Lavorando con Mercurial da un po’ di tempo, mi sono accorto di una cosa strana.

Riprendiamo un’immagine usata nel post precedente:

La cartella ConsoleApplicationMercurial è contrassegnata da un’icona di un tick verde, che indica il fatto che il repository è sincronizzato e non contiene files da committare e cose del genere. Se apro la solution con Visual Studio e faccio una semplice modifica al Program.cs, e magari faccio scrivere qualcosa nella Console e salva tutto, Mercurial ovviamente capisce che quel file è cambiato rispetto alla versione contenuta nel repository. Questo “capisce che quel file è cambiato” è evidente dall’icona che contraddistingue il file stesso:

mercurial_file_modified

Adesso c’è un punto esclamativo. Questa icona non cambia solo sul file, ma anche su tutte le cartelle superiori del repository, fino a raggiungere quella root del repository stesso, che nel nostro caso è X:DocumentiIgorVisual Studio 2010ProjectsConsoleApplicationMercurial.

Queste belle icone possono sparire!
Allora, se deciderete di usare Mercurial attivamente, probabilmente gestirete il tutto da Visual Studio, e quindi potrebbe non capitarvi di andare in Esplora Risorse e vedere lo stato di ogni singolo file. Ma se lo farete, sappiate che c’è un piccolo trabocchetto dietro l’angolo: queste belle icone possono sparire. Non ditemi perchè, ma TortoiseHG (e non tanto Mercurial) ha bisogno della presenza nella tray-bar di un piccolo applicativo, TortoiseHG Overlay Icon Server, che evidentemente si occupa di monitorare il sistema e di mettere le icone giuste sui files giusti. Se questo tool non è avviato, vedrete sempre un punto interrogativo.

Ora sia chiaro: quando installa TortoiseHG viene installato anche questo tool, e viene messo per giunta da qualche parte all’avvio del sistema. Se però siete pignoli come me e andate a toglierlo, potreste cadere in questo problema. Se vi interessa saperlo, l’exe è questo:

C:Program Files (x86)TortoiseHgTortoiseHgOverlayServer.exe

Tutto qua.

Cancellazione di un repository
Nei primi giorni in cui studiavo e sperimentavo Mercurial, mi capitava spesso di creare e di voler cancellare i repository. Si può fare? Assolutamente sì.

Supponiamo di aver creato un repository in X:DocumentiIgorVisual Studio 2010ProjectsConsoleApplicationMercurial, così come indicato in questa piccola mini-serie di post. Se vogliamo cancellarlo, è sufficiente:

  1. Entrare nella cartella ConsoleApplicationMercurial
  2. Cancellare la directory .hg
  3. Cancellare il file .hgignore

Ed il gioco è fatto. Ovviamente cancellare un repository non cancella i vostri sorgenti: cancella tutti i commit fatti, l’intero storico di tutte le modifiche fatte, etc. etc. Ma tutto il resto rimane: solution di Visual Studio, tutti i .cs: ma questo non c’è nemmeno bisogno di dirlo.

Installazione del plug-in per Visual Studio
Il plug-in è compatibile con Visual Studio 2005/2008/2010 ed è scaricabile dal progetto su Codeplex. L’indirizzo è il seguente: http://visualhg.codeplex.com/.

Non richiede particolari configurazioni. Dopo l’installazione basta aprire Visual Studio, andare su Tools –> Options –> SourceControl e dal plug-in selection selezionare la voce VisualHG.

Da questo momento in poi, quando aprite una solution gestita sotto Mercurial, i files verranno identificati dalle icone, come mostrato di seguito.

visualhg_solution_explorer

ed avrete un menù contestuale per le operazioni indispensabili…

visualhg_menu

ovverro Commit, Status, History, Synchronize ed Update.

Vedremo queste operazioni nei prossimi post.

Send to Kindle
Senza categoria

[Mercurial.3] Creazione di un repository Mercurial per gestire una solution Visual Studio 2010

Nel post precedente abbiamo dato solo una leggera infarinatura. Oggi facciamo un po’ più sul serio. Vediamo come creare un progetto Visual Studio 2010 e vediamo come versionare i sorgenti con Mercurial.

Al principio non dobbiamo fare nulla di particolare: apriamo VS2010 e creiamo una Console Application: lo facciamo solo per semplicità, ovviamente il tutto continua a valere con progetti WPF, Silverlight e ASP.Net. Creiamolo come al solito nella directory predefinita di Visual Studio, ottenendo un path ad esempio simile a questo:

X:DocumentiIgorVisual Studio 2010ProjectsConsoleApplicationMercurial

La cartella apparirà come tutte le altre normalissime cartelle.

A questo possiamo creare il repository, seguendo gli stessi passaggi indicati nel post precedente. Clicchiamo col destro sulla cartella ConsoleApplicationMercurial, andiamo su TortoiseHG e poi clicchiamo su Create Repository here.

Apparirà la seguente finestra:

Non toccate nulla e premete Create. Prima di farlo, però, date un’occhiata alla casella Add special files (.hgignore): questo è un file particolare, perchè può contenere un elenco di “filtri” per evitare di versionare determinati files, basandosi su estensioni/cartelle, etc. etc. E’ utile, come è facile intuire, per evitare di versionare exe, dll, files binari e così via.

Per adesso, ripeto, clicchiamo su Create e proseguiamo. A questo la cartella appare con un tick verde:

Questo perchè il repository in questo momento non contiene files modificati che richiedono il commit. E’ ovvio: il repository è ancora vuoto, per cui il passaggio seguente è quello di aggiungere i files. Clicchiamo col destro sulla cartella, andiamo su TortoiseHG e poi su Add files. Notare che siccome in questo momento stiamo lavorando su una cartella che è un repository Mercurial, il numero di voci disponibili è cresciuto a dismisura: possiamo esplorare il repository, possiamo aggiungere/rimuovere files, possiamo inviare ad un webserver il contenuto del repository, etc. etc.

Rimaniamo sul semplice, aggiungendo i files. La finestra di dialogo per questo task è la seguente:

Notare che ho spento le checkbox degli ultimi tre files, che sono files eseguibili o comunque files che non mi interessa versionare. Clicchiamo su Add ed il gioco è fatto.

A questo punto possiamo effettuare il commit vero e proprio. Clicchiamo col destro sulla cartella ed andiamo su HG Commit. La finestra di dialogo è la seguente:

Questo tool è più complesso di quello che sembra: c’è una casella di testo per inserire una descrizione relativa al nostro commit (“Primo commit”); sul lato sinistro c’è l’elenco dei files, mentre sul lato destro appare il contenuto del file correntemente selezionato sul lato sinistro. Se il file ha una history di qualche tipo (lo vedremo in seguito), sul lato destro vediamo le righe aggiunte/cancellate/modificate nel changeset corrente.

Inseriamo una descrizione e poi clicchiamo sul pulsante Commit nella toolbar.

A questo punto, possiamo tranquillamente lavorare con Visual Studio: aggiungiamo classi, scriviamo codice, aggiungiamo progetti e riferimenti. Ogni file che verrà aggiunto all’interno della cartella X:DocumentiIgorVisual Studio 2010ProjectsConsoleApplicationMercurial viene automaticamente preso in considerazione per l’inserimento nel repository. Ogni volta che fate il commit, l’elenco dei files sulla sinistra si aggiornerà: la colonna status (in breve ‘st’) vi dirà ‘A’ per quelli ‘added’ o ‘M’ per i files ‘modified’.

Questo se non vogliamo lavorare con il plug-in di Visual Studio, cosa che invece faremo dal prossimo post. La cosa è molto semplice: dentro il Solution Explorer ogni file verrà indicato con un’icona per indicare se è sincronizzato rispetto a quello nel repository, oppure se è stato modificato e così via. Possiamo committare, possiamo vedere lo stato corrente del repository, e un po’ di altre cose interessanti.

Alla prossima!

Send to Kindle
Senza categoria

[Mercurial.2] Mercurial: come creare il proprio repository

Ok, vediamo di entrare nel vivo del discorso. Creiamo il nostro repository Mercurial. Innanzitutto, cerchiamo di capire cos’è esattamente un repository Mercurial, altrimenti non si va da nessuna parte.

Un repository Mercurial è il repository dei nostri sorgenti, compresa l’intera storia di tutti i commit fatti. Semplice. E’ paragonabile solo in minima parte al Team Project di TFS (in realtà il Team Project contiene MOLTO di più).

Supponiamo per semplicità di lavorare da soli, e quindi di non dover scambiare con nessuno i nostri sorgenti. Anzi, vi dirò di più: evitiamo per adesso di dover per forza utilizzare Visual Studio: creiamo un repository qualsiasi, contenente semplicemente un file di testo che vogliamo versionare. Se avete installato Mercurial + TortoiseHG come indicato nel mio post precedente, non vi sarà difficile seguire i seguenti passaggi:

  1. Andate in una qualsiasi cartella del vostro PC (X:Documenti)
  2. Create una cartella (X:DocumentiNostroRepository)
  3. Cliccate col destro sulla cartella appena creata, andate su TortoiseHG e poi su Create repository here
  4. Appare il tool di TortoiseHG: non toccate nulla e cliccate semplicemente su Create

Ed il gioco è fatto. L’icona della cartella appare con un tick verde, ad indicare che il contenuto della cartella è sincronizzato. Bella fatica: è vuota!

A questo punto dentro la directory X:DocumentiNostroRepository possiamo creare o copiare tutto quello che vogliamo: ovviamente, il contenuto finirà nel repository.

  1. Creiamo un file prova.txt dentro X:DocumentiNostroRepository
  2. Scriveteci dentro qualcosa
  3. Clicchiamo col destro sulla cartella, andiamo su TortoiseHG e poi su Add Files
  4. Appare una piccola finestrella che elenca due files: .hgignore ed il nostro file di testo
  5. Lasciamoli selezionati e clicchiamo su Add
  6. Clicchiamo col destro sulla cartella e poi su HG Commit

Appare un tool che vi permette – guarda un po’ – di fare il commit. E qui c’è la grande differenza tra Mercurial e TFS:

In Mercurial l’operazione di commit è effettuata SEMPRE e COMUNQUE sul proprio repository locale. In TFS il commit è fatto verso il server. In entrambi i casi si parla di changeset (set di files inviati e marchiati con lo stesso numero di revisione).

Quindi, facciamo commit e di fatto aggiorniamo il nostro repository locale. Una cosa importante ed utile da sapere è che la cartella che fa da repository (X:DocumentiNostroRepository) è trasportabile da un PC all’altro e da una posizione all’altra. Il repository di fatto è tutto contenuto nella cartella stessa, e quindi si può farne il backup in modo semplice, posso mandarlo ad un collega in modo semplice, etc. etc. Non c’è un database, non ci sono assolutamente controindicazioni di alcun tipo.

Il repository – ricordiamolo – contiene i sorgenti e tutta la loro storia. Seguite questi passaggi tutte le volte che volete:

  1. Aprite il file di testo, modificatelo e salvatelo
  2. Committate

Come dicevo, ripetete a piacimento. Al termine, cliccando col destro sulla cartella e poi su HG Repository Explorer, vi si apre un tool che permette di “esplorare” e di vedere tutti i commit fatti su questo repository: per ogni changeset potete vedere i files modificati, e quali righe sono state modificate. Nel nostro esempio di questi post la questione è semplice, perchè il file è uno solo, ma se lo scenario è più complesso (e lo vedremo tra qualche post) il comportamento è il medesimo.

Per adesso chiudiamo qua. Vi lascio un po’ di link interessanti.

Mercurial su Wikipedia

Installare Mercurial (dal sito ufficiale)

Learning Mercurial in Workflows

Al prossimo appuntamento!

Send to Kindle
Senza categoria

[Mercurial.1] Utilizzo di Mercurial per versionare i propri sorgenti

Mercurial è uno strumento DCVS – Distributed Control Versioning System – per gestire i propri sorgenti. Per dirla breve – è un’alternativa al più complesso e sicuramente più potente/flessibile Team Foundation Server di Microsoft. Ma Mercurial:

  • è gratuito
  • è perfettamente utilizzabile 🙂
  • è più adatto a team distribuiti
  • non ha bisogno di un server vero e proprio: ogni PC del team fa da server e fa da client
  • è supportato da CodePlex
  • non richiede alcun database da nessuna parte per poter essere utilizzato
  • potete mettere sotto cvs qualsiasi cosa, e non solo soluzioni Visual Studio 2005/2008/2010, ma qualsiasi directory/files vi possa interessare: una directory piena di documenti Word o Excel, o mp3, o file di testo, o immagini: tutto e ancora di più.

Noi di Brain-Sys lo stiamo imparando ad utilizzare per gestire tutti i nostri sorgenti. Lo scopo di questa mia serie di post è quello di fornirvi le prime dritte, da dove cominciare e cosa fare per creare il vostro repository di sorgenti. Sia chiaro: basta googlare e si trova tutto, ma in italiano c’è sempre un po’ poco, e sono felice di fare la mia (piccola) parte.

Dove possibile, farò paragoni con TFS, strumento che ad oggi ho utilizzato maggiormente, e probabilmente la stessa cosa è successa a voi.

Cosa installare?
Una serie di punti importanti da sapere:

  1. Mercurial è principalmente un tool a linea di comando
  2. Mercurial è gestibile attraverso una GUI: TortoiseHG
  3. Mercurial non ha una componente server ed una client (come TFS)
  4. Mercurial esiste anche come anche plug-in per Visual Studio 2005/2008/2010

Il sito ufficiale di Mercurial è http://mercurial.selenic.com/.
Il link per il download è http://mercurial.selenic.com/downloads/.

Se utilizzate Windows – come credo – cliccate sulla voce Windows ed installate Mercurial. Cosa accade dopo l’installazione di questo pacchetto? Sono accadute due cose:

  1. Avete installato Mercurial in C:Program Files (x86)Mercurial (ovviamente se non avete modificato a mano il path di installazione)
  2. E’ stato inserito questo percorso nei path predefiniti di Windows

Detto questo, basta andare nel prompt di DOS e digitare il comando “hg” per eseguire il comando. Se parte…tutto ok, altrimenti c’è qualcosa che non va, e non vi so aiutare perchè a me sui tre PC che sto utilizzando non ho mai avuto problemi di questo tipo.

Posso immaginare che usare un tool a linea di comando nel 2010 possa sembrare assurdo ed anti-produttivo. Per questo è importante scaricare anche TortoiseHG for Windows 32 o 64 bit (a seconda del vostro sistema operativo). TortoiseHG vi dà tutta una serie di tool grafici per gestire i progetti Mercurial: vari tool raggiungibili dal menù contestuale di Windows, che si adatta in base al contenuto della directory corrente. Ne parleremo in seguito con maggior dettaglio, ovviamente.

Alla prossima!

Send to Kindle
Senza categoria

Sistemato il problema dell’allineamento menù

Vi ricordate il problema che avevo segnalato in questo post? Tutti i menù del sistema operativo, di qualsiasi programma, vi apparivano stranamente allineati verso sinistra, in un modo davvero scomodo.

Stamattina, preso dalla testardaggine di voler risolvere il problema, ho trovato questo link che spiega (finalmente!!) come risolvere la questione. La morale è:

  1. aprire regedit
  2. navigare fino a
    HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindows
  3. correggere il valore della chiave MenuDropAlignment da 1 a 0
  4. riavviare il PC

Finalmente i menù mi appaiono come dovrebbero apparire, e come hanno sempre fatto. Non ho idea di chi/cosa abbia cambiato questa impostazione nel registro di configurazione: sono ancora convinto del fatto che sia stato causato da qualche aggiornamento di Windows Update.

Comunque…tutto sistemato!

Send to Kindle
Senza categoria

Mantenere aggiornati i propri social network

Ingredienti per una persona:

  • un account Twitter
  • un account Facebook
  • un blog
  • plug-in Twitter Tools per WordPress (link)
  • plug-in Twitter per Facebook

Quando ho aperto il mio blog su UGIdotNET, ormai cinque anni fa, la mia presenza in rete era determinata fondamentalmente da due cose: il mio blog – appunto, e qualche forum.

Oggi, nel 2010, le cose sono diverse: già da qualche anno è esplosa la moda dei social network, quindi tutti noi abbiamo a che fare con Twitter, Facebook, Linked-In ed altri ancora, e spesso quello che vogliamo è cercare di gestire ed aggiornare tutto quanto da una sola applicazione, che sia TweetDeck o altro, web oppure no. Insomma, può essere un pochino complicato, e ciascuno di noi ha trovato la propria soluzione. La mia qual’è? Eccola qua:

  1. Ho installato il plug-in Twitter Tools per WordPress (il mio blog engine attuale), in modo tale che ogni volta che posto qualcosa (attraverso Windows Live Writer sui miei PC, oppure attraverso altri strumenti sul mio Nokia, o siti Web) viene automaticamente twitterato un qualcosa simile a Nuovo Post :: <titolo del post> <link del post>
  2. A questo punto, il mio blog ed il mio Twitter appaiono sempre sincronizzati: ovviamente posso comunque twitterare qualcosa senza scrivere un post sul blog 😉
  3. Su Twitter non possiamo installare alcun plug-in, ma su Facebook sì, quindi…
  4. …quindi, sul mio account Facebook ho installato il plug-in Twitter, che si occupa di aggiornare il mio stato, prendendo esattamente il contenuto del twitter ed impostandolo nello stato: nulla di che

Attenzione al plug-in che si installa sotto Facebook, perchè ci sono plug-in che lavorano solo sullo stato, e ci sono plug-in che invece importano l’intero contenuto del post: testi, immagini e links. Questo ultimo tipo non mi piace, per due motivi:

  1. perchè devo regalare il contenuto del mio post a Facebook?
  2. se ho il mio post in due posti diversi, i vostri visitatori tecnicamente possono mettere i loro commenti in due posti differenti: su Facebook (giammai!!) oppure sul vostro blog: secondo voi, cos’è meglio?

Il secondo punto è fondamentale: mi capita spesso di leggere post degli amici di community, sia sul loro blog, sia su Facebook e a seconda delle circostanze, rispondo da una parte o dall’altra. Davvero scomodo e brutto. Preferisco di gran lunga avere su Facebook una semplice notifica del fatto che qualcuno ha scritto qualcosa, ma non l’intero post. Ma i gusti son gusti.

Alla fine, inserite i vostri PC, i vostri blog e tutti i vostri account nel form, impostate i 180° e tenete dentro il tutto per circa 30 minuti. Servite bello caldo a tavola.

Send to Kindle
Senza categoria

Google, libertà e complicazioni per l’utente finale

A volte mi chiedo se ci sono o se ci fanno. Sono ultra-convinto che il Choice Screen che ci siamo ritrovati su Windows qualche settimana (mese?) fa non sia servito assolutamente a nulla. Gli utenti più preparati sanno benissimo che oltre ad Internet Explorer è possibile installare anche altri browser di terze parti, di tutti i tipi e in tutte le salse. Gli utenti più inesperti hanno strabuzzato gli occhi di fronte al Choice Screen: per loro Internet è la ‘e’ azzurra, punto e basta.

Ma non finisce qua. In nome della maggior libertà sul Web, secondo me si è solo complicata la vita all’utente finale. E per certi versi la si è “obbligata” in un modo davvero ignobile: vi spiego il perchè.

Per usare Google Wave sono costretto ad utilizzare FireFox o Chrome. Buuuu!
Per poter solo scaricare Google Earth sono costretto ad utilizzare Chrome. Buuuuuuuuu!
Ebbene sì, anche solo per scaricarlo ed installarlo sul proprio PC.
In nome della libertà sul Web.

Mio padre è uno sportivo che va in bicicletta, ed utilizza il suo Nokia con GPS integrato per salvare il percorso che percorre (scusate il gioco di parole) quotidianamente. Il percorso può essere esportato nel formato .kml, pubblicato su Endomondo.com, e da qui eventualemente condiviso al mondo attraverso Twitter o Facebook. Ma il più delle volte mio padre si limita a guardare il percorso aprendo il file .kml con Google Earth.

Stasera mio padre si siede su un PC senza Google Earth installato. Avvia Internet Explorer, cerca “google earth”, clicca sul primo link che trova e raggiunge il sito ufficiale. Clicca sul pulsantone azzurro/blu in alto a destra che dice “Installa Google Earth 5”, poi clicca su “Accetta e scarica” e poi aspetta. Con Internet Explorer viene ricaricata la stessa pagina, poi dopo qualche secondo appare la Barra Informazioni che avvisa che c’è un download: modalità che non mi è mai piaciuta, ma andiamo avanti.

Mio padre dà la conferma: la pagina viene caricata per la terza volta nel giro di pochi secondi, e finalmente cominciato il download del file googleupdatesetup.exe. Questo è un piccolo installer di 549Kbytes che non vi installa affatto Google Earth, ma Google Chrome. Provare per credere. Assurdo, mi ricorda tanto una cosa simile con Apple: se volete installarvi iTunes dovete per forza installarvi QuickTime. Perchè? Ma perchè? Per installare a tutti gli effetti Google Earth, ho dovuto ripetere la procedura con Chrome; al termine dell’installazione, non mi ha neppure messo l’icona sul desktop, ho dovuto crearla io a mano prendendo l’exe che c’è in C:ProgrammiGoogleEarth.

Ora, ho 34 anni e posso essere pure uno stupido, ma so benissimo che il mondo è un po’ più grande e complesso di come me lo posso immaginare: dietro una scelta apparentemente tecnica, ci sono motivazioni commerciali e chissà cosa. Ma allora – mi chiedo – perchè si ricorre a soluzioni tecniche come il Choice Screen per dare una maggior libertà all’utente, e poi lo si obbliga ad usare browser specifici per particolari task? Se devo sentirmi libero di poter installare 6 browser differenti, perchè non posso essere libero di usare solo Internet Explorer?

P.S. : per testare bene la cosa ho riprovato la stessa cosa sul mio notebook, e devo ammettere che non vale tutto ciò che ho scritto. Ho installato Google Earth da IE, ma l’obbligatorietà di avere comunque Chrome installato c’è comunque. Probabilmente dipende dalla configurazione software, anche se il sistema operativo è in entrambi i casi Windows 7. Mah!

Send to Kindle
Senza categoria

Pattern M-V-VM e facce della mamma

Per scrivere questo post ho bisogno di un piccolo preambolo tecnico.

Sto sviluppando un’applicazione Silverlight 4, facente uso dei RIA Services per l’accesso ai dati. Un po’ perchè sono nuovo di Silverlight, un po’ perchè comunque perchè non si finisce mai di imparare, questa mattina mi sono ritrovato a dover affrontare una nuova problematica che non sapevo bene come gestire.

La prima cosa che faccio in questi casi è partire da zero, se possibile: creo una nuova applicazione per isolare e studiare il problema a parte, poi lo isolo e pian piano lo caccio dentro (termine tecnico) l’applicazione vera che sto sviluppando. Così ho fatto questa mattina.

Quindi, nuova applicazione Silverlight 4, creo una classe BaseViewModel con il minimo indispensabile, poi un MainViewModel che eredita e via dicendo. Disegno quello che devo disegnare, imposto il DataContext, un po’ di TextBlock bindate a proprietà del ViewModel, ed un bel Button bindato ad una proprietà di tipo RelayCommand. Avvio il progetto, vedo i dati nella ListBox, quando seleziono un oggetto si popolano tutte le TextBlock.

Poi clicco sul pulsante e…boom…non succede nulla. Clicco e ri-clicco e non succede nulla. Controllo di qua e controllo di là: il pulsante non sembra scatenare l’execute del comando. E’ così che – tra le altre cose – arrivo all’ora di pranzo.

Scendo per pranzo verso le 12:30, pensieroso e con la faccia scura perchè – nonostante abbia di fronte un piatto di penne al ragù – continuo a pensare al problema. “Cavolo, l’ho già fatto un centinaio di volte ormai, perchè quel pulsante non va?”.

Ed è qui dove arriva la mamma che quando mi sente silenzioso e mi vede preoccupato, capisce subito che c’è qualcosa che non va. E cerco di spiegarle che non è nulla di serio, è solo un bottone che non ne vuol sapere di fare il suo sporco lavoro. E mentre mangio continuo a pensarci.

Mumble mumble.

Finito il pranzo, torno su e rimetto mano al codice. E con lo stomaco pieno si ragiona sempre meglio, ed ecco infatti che arriva la soluzione: vero che il bottone era correttamente bindato ad una proprietà di tipo RelayCommand del ViewModel, peccato però che la classe RelayCommand non stesse ereditando da ICommand, e quindi di fatto non c’era un vero comando associato al bottone.

Finale.

Ore 16:00 : sale mia madre in mansarda ad annaffiare la pianta grassa che c’è vicino al mio monitor e – premurosa – mi chiede: “Come va? Hai risolto quel problema?” E io bello tranquillo: “Sì sì, certo, il fatto è che il bottone ereditava giusto il DataContext dallo UserControl, la proprietà Command era bindata giusta, ma mi ero dimenticato di mettere nel codice il fatto che classe RelayCommand deve ereditare da ICommand.”, come stessi parlando con Omar o con un collega!

Insomma, avreste dovuto vedere che faccia ha fatto, manco avessi parlato aramaico antico!!!

Mamma, ti voglio bene!

Send to Kindle
Senza categoria

Snippet di codice per Silverlight & WPF

A questo indirizzo potete scaricare una bella quantità di snippet di codice da utilizzare quando si sviluppa con Silverlight e WPF. Permette fra le altre cose l’inserimento rapido di codice per:

  1. scrivere classi che implementino INotifyPropertyChanged
  2. inserimento di dependecy property, routed command, routed events, etc.
  3. observable properties, cioè tutte quelle proprietà che – all’interno del set – debbano notificare a qualcuno la propria modifica (va da sè che richieda INotifyPropertyChanged): e sono più intelligenti di quello che può sembrare, perchè ad esempio scatenano l’evento solo quando il valore della proprietà cambia veramente
  4. snippet di codice specifico per Silverlight (attached property, read-only properties, etc. etc.)
  5. e molto altro ancora

Davvero molto comodi!!! Tutti gli snippet sono disponibili per C# e VB.Net. L’installer è un semplice file zip, contenente un .vsi che basta semplicemente lanciare.

Unica nota dolente è proprio l’installazione…
…è proprio l’installazione. Ho installato solo le versioni C#, e ho dovuto spuntare a mano tutti quelli per VB.Net. Inoltre, li ha installati nel seguente path:

C:UsersIgorMy DocumentsVisual Studio 2005Code SnippetsVisual C#My Code Snippets

e quindi lanciando Visual Studio 2010 ed inserendo lo shortcut…non trovava alcun snippet da inserire. Ho dovuto copiare manualmente tutti i files *.snippet dal path qui sopra a:

X:DocumentiIgorVisual Studio 2010Code SnippetsVisual C#My Code Snippets

Notare che l’installer chiede esplicitamente su quali versioni di Visual Studio installare: io ho specificato VS2010, ma lui l’ha bellamente ignorato! Pazienza!

Send to Kindle