NeatCoding

Eh, non voglio fare pubblicità... ma alzi la mano chi lavora con ASP.NET e non ha sottoscritto il blog di scott!

Credo che a quest'uomo vada fatta una statua, o quanto meno vadano donate un congruo numero di sorelle (io purtroppo non ne posseggo!! :P)

Comunque, a parte i salamelecchi vari, vi consiglio veramente di farci un salto ogni... spesso, perchè c'è sempre qualcosa che vi può interessare, soprattutto se,  come me, siete curiosissimi verso le nuove tecnologie!

E... parlando di nuove tecnologie... ovviamente Silverlight mi viene in mente! :)

Quindi, pur essendo a Firenze e non avendo tempo per fare nulla, ho trovato comunque cinque minuti per segnalarvi questo interessante post sull'argomento che mi ero dimenticato di segnalare settimana scorsa... provate a scaricarvi gli esempi e buon divertimento :)

La vita di un consulente è tempestata da imprevisti.

Tralasciando quelli (sempre presenti) della vita personale, gli imprevisti lavorativi possono rappresentare un vero problema. Ultimamente (cioè ieri :P) mi è capitato di dover assecondare un cliente per andare a Firenze (sigh.. caldo...) giovedi e venerdi, quindi con pochissimo preavviso, ed ho dovuto spostare un appuntamento che avevo per venerdi ad un altro giorno.

Questo per fortuna mi è successo perchè non avevo altri impegni assolutamente improrogabili.... ma altrettanto per fortuna mi "scelgo" abbastanza accuratamente, quando posso,  i miei clienti per poter avere la possibilità di sapere come ragionano. Con alcune tipologie, mi sarebbe stato  quasi impossibile spostare una giornata senza improvvisare una malattia o un imprevisto, e mentire in certi casi non ha mai ripagato: le probabilità di essere beccati o di tradirsi in qualche modo sono troppo alte, ed aumentano esponenzialmente quando si butta la propria vita lavorativa su un blog pubblico :)

In certi casi, preferisco molto essere franco e dire al cliente che devo spostare la giornata per un urgenza su un altro cliente. se la persona dall'altro capo dal telefono è intelligente, capirà che se lo faccio per altri, in un futuro potrò farlo anche per lui, ed accetterà di buon grado!

Certo, se fosse successo in concomitanza per esempio con un rilascio in produzione di venerdi, sarebbe stata una tragedia... ma questo è il motivo per cui non pianifico MAI rilasci in produzione per il fine settimana :)

Voi? Come preferite comportarvi? Potete dirlo o preferite non farlo per evitare di spaventare i vostri clienti? :P

Oggi niente Daily Issue: ho una laurea tra poco (non la mia, tranquilli, non è successo niente di irreparabile :P ) e sono incasinato in altre faccende ....

Però, il mio classico giro mattutino me lo faccio, e tra i tanti blog che visito ce n'è uno veramente carino, http://worsethanfailure.com/ (per chi naviga da un pò, mi pare che prima fosse il Daily What The Fuck, poi rinominato). Praticamente, una raccolta di stupidate relative al mondo informatico, non solo dal punto di vista dello sviluppo.

Bellissimo il post di ieri: http://worsethanfailure.com/Articles/Which-Cable.aspx

:)

http://scottwater.com/blog/archive/12091/

Può sempre essere utile ricordare che con 2005 anche VB.NET può beneficiare dello using! :)

Ultimamente, parlando con alcuni colleghi e sui newsgroup, mi è capitato di incorrere in qualche incomprensione sul funzionamento della sezione authorization.

Visto che è capitato così tante volte nell'arco di una sola settimana, direi che a sto punto lo scrivo qui, così almeno se me lo richiedono... rimando al link sul mio blog :)

Allora come è scritto qui:

http://msdn2.microsoft.com/En-US/library/acsd09b0(VS.80).aspx

At run time, the authorization module iterates through the allow and deny elements, starting at the most local configuration file, until the authorization module finds the first access rule that fits a particular user account. Then, the authorization module grants or denies access to a URL resource depending on whether the first access rule found is an allow or a deny rule.

Questo vuol dire che cambiando l'ordine il risultato... cambia! (sapevo io che la matematica mi avrebbe portato fuori strada  :P)

Quando il framework incontra un elemento di autorizzazione che gli va bene, lui entra e tanti saluti a tutto il resto, anche se in fondo abbiamo uno splendido "deny *". Questo probabilmente per evitare configurazioni lacoontiche di accessi che creerebbero solo confusione e basta.

Quindi, se io voglio restringere l'accesso a solo particolari gruppi/utenti, devo fare attenzione a registringere gli accessi a tutti tranne quei gruppi/utenti, e devo anche fare attenzione a mettere il deny "*" come ultima riga di configurazione se non voglio che vengano buttati fuori tutti.

Quindi una riga così

<deny users="?" />
<allowroles="PippoGroup" />

Non va bene, perchè chiunque si autentica, sia membro di PippoGroup o meno, ottiene accesso alla risorsa perchè il framework non trova scritto diversamente!

La sintassi corretta è:

<allow roles="PippoGroup" />
<deny users="*" />

Che il framework traduce in "o sei di PippoGroup, oppure fuori :)

Attenzione, per quanto ho detto, a non mettere deny users PRIMA di allow... in questo caso, taglia fuori chiunque, anche se appartiene a PippoGroup.
Da notare che a questo punto deny users="?" non serve piu in quanto ha valore l'asterisco, nel caso uno non sia del gruppo PippoGroup!

P.S.: Un grazie particolare a Roberto che mi ha fatto notare quanto LiveWriter mi avesse scombinato il post :)
P.P.S.: Un altro grazie particolare a Mrkino che mi ha fatto notare che, probabilmente ubriaco, ho scambiato "Roles" con "groups". :)

Stavo paciugando in questi giorni con un piccolo programmino di statistiche... l'idea è tenere sotto controllo, senza troppe pretese, le solite cose che interessano in caso di statistiche, senza utilizzare un prodotto gratuito con immagini invasive ed assolutamente non-fashion (:P) e senza dover pagare per averlo. E ovviamente, essendo hostato su server non conosciuti, senza avere accesso ai log della macchina.

In se, creare un programma semplice è un lavoro veloce di una mezza giornata, per conteggiare le classiche cose: accessi unici, pagine visitate, useragent, browser, referrer, etc etc.

Preso dalla smania, ho deciso di customizzarlo un pochetto, sai mai che poi ci scappa qualcosa di riutilizzabile, quindi ho creato la mia solita pagina aspx, che renderizza un'immagine vuota, che chiamata da un qualsiasi sito si occupa di conteggiare le statistiche, settare eventuali cookie (*) per il riconoscimento dell'utente unico, etc etc. Successivamente, l'idea è creare un controllo che faccia tutto...

Il problema è che, con questa metodologia, il mio Request.UrlReferrer diventa inutile, in quanto il chiamante della mia pagina/immagine è effettivamente la pagina che l'utente sta navigando, quindi mi perdevo  il referrer vero, e mi sarei trovato la pagina chiamante uguale al referrer....

La soluzione che ho trovato? Il caro vecchio Javascript: il mio controllo renderizza insieme all'immagine uno script che prender il referrer (escape(document.referrer), attenzione che l'escape è importante per evitare casini) e lo passa in querystring alla mia pagina/immagine, che quindi può tranquillamente occuparsi del suo lavoro di conteggio con dati reali.

Si, è un problema banale... ma è sorprendente quanto possa passare inosservato finchè non ti serve :)

(*) ATTENZIONE: creare un programma di statistica "generico", cioè che possa essere usato da clienti diversi, ci espone a problemi di privacy. A partire da Internet Explorer 6, le impostazioni di default "bloccano" qualsasi cookie venga impostato da un sito esterno a quello che stiamo navigando (il classico occhio con il divieto di passaggio nella barra del vrowser) e questo da problemi nelcaso noi abbiamo uno sito di statistiche che si occupi di conteggiare le statistiche su differenti URL esterni.

Per fortuna, ci viene in aiuto il W3 che definisce, come al solito, gli standard per cui i browser possono accettare cookie anche provenienti da siti esterni a quello che stiamo navigando.

Tutto questo si traduce nel Platform for Privacy Preferences (P3P) Project (http://www.w3.org/P3P/) ... purtroppo i passi da fare non sono così immediati... in un prossimo post (se mi ricordo :P) spiegherò esattamente come procedere :)

Non è esattamente un Daily Issue.. ma ieri, per il progetto di cui parlavo tempo fa, mi sono ritrovato ad entrare nell'annosa questione del parametro Type dei famosi metodi dell'oggetto ClientScriptManager per iniettare codice JavaScript all'interno di una pagina, ed in particolare RegisterClientScriptBlock e RegisterStartupScript.

In questi due metodi, sono sempre stato abituato dagli esempi a mettere come tipo this.GetType(). Questo sia che lo mettessi in una pagina direttamente, che in un custom control.

Il dubbio mi è venuto ieri, quando ho sviluppato un CustomControl derivato da un mio CustomControl, ed ho notato che... lo script veniva duplicato!

Dopo qualche ricerca in giro, ho trovato conferma dei miei dubbi: l'utilità del tipo è evitare che per tipi simili venga ricreato lo stesso snippet piu volte, così se io incorporo dieci controlli tutti uguali non duplico dieci volte il JavaScript. Se però io ho un oggetto mioControllo, e ne sviluppo un altro che aggiunge poche cose, ma usa le funzionalità di base di mioControllo, e lo chiamo mioControlloDerivato, con il GetType() mi ritrovo due script se li uso entrambi, uno per mioControllo ed uno per mioControlloDerivato, in quanto GetType da due risultati  differenti.

Se per me questa cosa va bene, nel senso che è voluta, ok, altrimenti sono costretto ad utilizzare typeof(mioControllo)... in questo modo anche mioControlloDerivato avrà sempre come tipo mioControllo (che è anche corretto in quanto  deriva da esso) ed eviteremo inutili duplicazioni!

Stavo cercando in giro un piccolo tutorial per spiegare ad alcuni.. hem.. membri di un team per cui sviluppo come funzionano i progetti di setup, ed evitare di perdere un'ora a spiegarlo e trovarmi di fronte a espressioni di stupore come "gu" o simili ....

Per fortuna hanno inventato ScottGu che mi è venuto in contro qualche gg fa (sigh.. non ho letto i feed di ASP.NET per qualche giorno.. altrimenti l'avrei visto prima :))

http://weblogs.asp.net/scottgu/archive/2007/06/15/tip-trick-creating-packaged-asp-net-setup-programs-with-vs-2005.aspx

Ricominciando (mah... direi per fortuna? :)) ad avvicinarmi al mondo della grafica, ho ricominciato ad avere alcuni problemucci legati alle diverse implementazioni del motore di rendering dei CSS.

In particolare, i problemi si hanno quando, come usuale, si testa tutto l'applicativo sotto explorer, e poi lo si porta a fare un "giro di prova" su firefox, o viceversa ... di solito quello che succede è ... beh.. Kabooom... :)

In particolare, il caso che mi è successo era l'allineamento di un div all'interno di un altro div. Io avevo usato (erroneamente) text-align, credendo che se va bene per il test va bene anche per gli altri elementi. Explorer me ne aveva (galeotto) dato la conferma.... ma ovviamente, aprendo firefox, mi ritrovo tutto bello spiattellato a sinistra.

Non fidandomi per nulla di explorer, ho aperto il w3c ed ho visto che, appunto, explorer mentiva, in quanto assume che se vuoi l'allineamento del testo al centro, DEVI volere anche i div dello stesso container allineati centralmente... invece magari no.... sigh...
La soluzione che ho trovato in giro è abbastanza semplice:

margin-left: auto
margin-right: auto

E poi si setta il padding di conseguenza... ovviamente lo stile va applicato al box che volete sia centrato rispetto all'oggetto contenitore :)

Ebbene si, finalmente, dopo molte peripezie, sono riuscito a fare installare i validissimi ASP.NET 2.0 CSS Friendly Control Adapters che, per chi non li conoscesse, permettono di renderizzare la maggior parte dei controlli ASP.NET 2.0 con html compliant alle specifiche CSS.

Questo mi ha aiutato a prendere alcune delle applicazioni già scritte e "sfrondarle" di tutte quelle noiose tabelle per riportare allo splendore i DIV innati dentro di loro...

Risultato.. beh, sembra uno spot pubblicitario, ma le pagine sono _decisamente_ piu snelle e decisamente piu veloci nel rendering. Ed il cross platform non è neanche così distruttivo, se si prendono come assodate alcune differenze di redering (ma basta goooglare un pò per trovare quasi tutte le soluzioni, a volte anche piu di una).

L'unica cosa è che si può incorrere nel cosiddetto "Div Hell", ossia quando mettendo un sito già esistente sotto CSS, ci si ritrova ad avere DIV incrociati che si sovrappongono in maniera errata o si spostano con libero arbitrio. In questo caso, mi è venuto molto in contro creare un bordo colorato per ogni ID, in modo da poter capire subito che div stesse sforando e dove...

Certo, farlo a mano per ogni ID, soprattutto se si hanno molte classi, può essere problematico. Infatti mi sono creato un meccanismo di caricamento dei CSS apposta.... ma di questo ne parlerò in un altro Daily Issue :)

Non sempre i problemi tecnici sono quelli maggiori...

I problemi tecnici sono quasi sempre superabili, basta capire quanto tempo ci si vuole spendere e quante risorse....
... mentre invece quando si è davanti a problemi di attitudine, noia, routine... le cose si fanno complesse!

In questa settimana sto ricominciando a spolverare il mio lato "grafico" piu di quanto avessi fatto nell'ultimo tempo... tra le mie varie prove con Silverlight (si si presot ricomincerò con i Daily Issue.. sulla 1.0... sigh....), qualche veloce digressione su grafica e photoshop che mi ha fatto ricordare che peccato sia non poterci lavorare di piu, alcuni progetti con i video... e soprattutto con Silverlight mi sono accorto di quanto sia divertente vedere lo sviluppo da un altro lato, sotto altri aspetti e con altri problemi...

Detto da uno che fa gestionali finanziari da almeno 4 anni.... mah... l'importanza di cambiare è questa! Posso assicurarvi che erano anni che non lavoravo con tutta questa dedizione!

Il bello del consulente è anche questo! Ora cercherò, per quanto possibile, di non fossilizzarmi su una sola tipologia di applicazione (del tipo "sono nella finanza da anni, è ovvio che continui con gli applicativi finanziari) ma spaziare il piu possibile, per allargare le sfide, le motivazioni e per tenere allenato il mio cervello! Mai e poi mai vorrei che si sedimentasse su un argomento solo :)

Questo è un anticipo del Daily Issue di domani.. so già che non avrò tempo, visto che ne ho un po da rubare al sonno, anticipo :)

Capita spesso di dover fare in modo di servire contenuto diverso dalle pagine web in un'applicativo ASP.NET. Siano questi fogli excel, pdf, e via dicendo.Mi capita spesso di avere anche il problema di non voler caricare questi elementi nel visualizzatore del browser, soprattutto nel caso di PDF o Excel, ma di dare all'utente la scelta di aprirli o salvarli su disco.
Peccato che il browser sia abbastanza insistente e se viene servita direttamente una risorsa che lui sa di poter gestire.. lo fa, e se ne frega :)

La soluzione? Aggiungere un semplice header:

Response.AddHeader("Content-Disposition", "attachment; filename=Sigla.pdf");

... sembra inccredibile ma ancora molte volte non si conosce l'utilizzo di questo trucchetto... mi era sembrato giusto condividerlo :)

Questo è un daily issue piu strano del solito... ero salito qui per scrivere un piccolo issue su XML che ho avuto in questi giorni.... mi collego e dico "dai, che è da venerdi che non scrivo"... mi collego e vedo il mio ultimo Daily Issue... datato 6 giugno! Improvvisamente panico, controllo il Live Writer per controllare che non mi sia rimasto nessun fantasma nelle bozze... poi ricordo... ho passato giovedi e venerdi da un cliente fino a tardi (mooolto dopo mezzanotte :P) per buttare in produzione un programma rispettando scadenze che i nostri partner invece NON avevano rispettato... ed ancora ieri, sempre per mettere pezze ad errori di altre società, un'altra nottata in ufficio... ho praticamente perso un pezzo di vita! E non intendo le cose del tipo famiglia, amici, lavoro, sbronze, per quello ho  avuto il weekend, ma ero convinto di aver scritto l'ultimo Daily Issue qualche giorno prima invece è passata quasi una settimana!

Questo per dire... alzate gli occhi dallo schermo!! Non fate come me.... passare tre giorni interi a lavorare piu di 10 ore al giorno senza accorgersene non fa bene a nessun, men che meno a noi stessi!
.... domani vado a casa alle 7 di pomeriggio :P

Non è un segreto che non ho moltissima fiducia nel framework Ajax: lo ritengo ottimo e ben fatto, ma molto spesso utilizzato a sproposito e senza effettiva cognizione di causa.

Mi trovo spesso a ragionare sul suo utilizzo o meno, nel senso che vedendo come funziona la classe di base, il codice javascript ed il prototyping parecchio complesso che gestisce la base tutto il framework Ajax, mi chiedo in certi casi se sia veramente necessario o meno!

Per esempio, ieri (notte... sigh) mi stavo interrogando sull'utilizzo di Ajax in un'applicazione per una singola form che aveva bisogno delle classiche DropDownList fillanti. Ho rispolverato gli extender forniti con il toolkit, ne ho vista la quantità impressionante di logica per fare un passaggio tutto sommato semplice... e mi spiace dirlo, Ajax ha perso. Mi sono implementato il mio vecchio Javascript con XmlHttpRequest o Microsoft.HtmlHTTP, ho chiamato una pagina che mi renderizzava quello che volevo, ed ho avuto le Ddl autofillanti in 10 minuti, con la vecchia maniera... anche se con un pò di amarezza per non aver utilizzato ajax con il quale probabilmente avrei risparmiato 8 minuti su 10, ma lanciando sul client una quantità di codice JavaScript 20 volte superiore...

E voi? Sono io l'unico che si fa di simili problemi ed usate Ajax a profusione o lo assumete con cautela? :)

Eheheh ok ok chiedo già scusa in anticipo per il titolo....

Cmq per chi se lo fosse perso, sul blog di Michael Schwarz c'è questo interessantissimo post che riassume tutti i tutorial che hanno a che fare con silverlight, compreso quelli presi dalle sessioni del MIX...

Allora, siete ancora qui? Andate a scaricare tutto!! :)

Ebbene si.... il mio tentativo di iniziare una demo per un cliente in 1.1 è stata messa da parte a favore della 1.0, ritenuta piu matura. A ragione, probabilmente, ma la 1.1 era sicuramente più figa ... :)

Comunque, una volta messe le pive nel sacco, mi sono messo d'impegno per replicare tutto quello che avevo fatto in 1.1 con 1.0, ho ovviamente incontrato molti dei problemi già visti che sono stati risolti in maniera simile. Le attached properties, invece, si comportano in maniera lievemente differente da quello che avevo descritto nel precedente post

In 1.0, utilizzando Javascript quindi, si hanno due metodi di cambiare le attached properties: una è con il vecchio SetValue, soltanto che ovviamente non essendo  tipizzato accetta delle stringhe, e la proprietà non ha il suffisso "property" 

mioOggetto.SetValue("Canvas.Top", "200");

oppure interagendo direttamente con l'array degli attributi dell'oggetto mediante parentesi quadre

mioOggetto["Canvas.Top"] = 200;

Quale preferire? ... non saprei... mi piace di piu l'idea delle quadre, ma per coerenza con Silverlight 1.1 e per evitare di scrivere codice troppo differente tra le due versioni, prediligerei il SetValue!

In alcuni casi, mi sta succedendo di avere dei problemi con lo Streaming: probabilmente a causa della versione Alpha della release 1.1, alcuni video soprattutto quando ci sono effetto mirror o quando ce ne sono piu di due, ed i video sono troppo grandi e definiti, il mio PC schizza al 100% (ed il mio portatile non è proprio una schifezzina :P) ed il video perde sincronia con l'audio.

Questo è dovuto al fatto che comunque il codice in alpha gira sulla macchina client, non su quella server, e questo porta a problemi di performance di questo genere.

Questo può portare a non pochi problemi quando si sta cercando di convincere un cliente ad usare una tecnologia che oltretutto è in alpha e non matura, ma se si riesce a dimostrare che è comunque veloce ...

La soluzione che ho trovato è abbassare il framerate generico dell'applicazione SilverLight (non avendo trovato come configurare questo parametro a livello di singolo MediaElement... non credo che per ora sia possibile, spero nel futuro.....) aggiungendo

framerate: "3"

nell'array di proprietà passato alla chiamata createObjectEx

Daily Issue speciale della domenica :) Sto litigando da parecchi giorni con Silverlight (ma no? Ma dai? :P) come sicuramente chi legge anche solo ogni tanto il mio blog avrà capito.

A causa di questo amore/odio, sono dovuto scendere a patti con le AttachedProperties che, per chi non lo sapesse, sono proprietà che possono essere associate ad un figlio da un padre, senza che il figlio abbia conoscenza del padre stesso.

Sono vitali in Silverlight in quanto tutta la struttura è formata in termini di padre/figlio e la maggior parte degli oggetti deve interagire con le proprietà del canvas contenitore.

Cambiare queste proprietà modificando lo XAML è relativamente semplice, mentre cambiarle da codice per creare effetti dinamici può rivelarsi abbastanza complesso.
Per fortuna, basta cercare meglio nella (scarna) documentazione, e controllare bene gli oggetti  DependencyObject e DependencyProperty. DependencyObject è un qualsiasi oggetto che può essere sottoposto a questo genere di dipendenza, quindi piu o meno qualsiasi oggetto presente in Silverlight (MediaElement, Textblock, Image e compagnia danzante). DependencyProperty è appunto un'istanza di una proprietà "attaccata" da un padre sul figlio.

Cercando piu a fondo, e "dribblando" alcuni consigli errati sull'utilizzo degli Attributes in maniera diretta, si scropre che ogni DependencyObject espone due metodi SetValue e GetValue, per scrivere e leggere rispettivamente le nostre attachedProperty.

Quindi, avendo un MediaElement e volendo cambiare il Canvas.Top, si può usare

MediaElement m = new MediaElement();
m.SetValue(Canvas.TopProperty, 100);

In questo modo il mio MediaElement verrà renderizzato con 100 pixel di margine rispetto al margine superiore del mio canvas.

Volendo farne una questione di concetto, cmq questo approccio non è esattamente giusto: dovrebbe essere la classe Canvas ad esporre le giuste proprietà per cambiare le attached properties sui figli.
Ed infatti, è proprio così: la classe che gestisce le dipendenze _deve_ esporre dei metodi statici che permettano di cambiare le properties sui figli.

Quindi, volendo cambiare il nostro esempio, si avrebbe

MediaElement m = new MediaElement();
Canvas.SetTop(m, 100);

Più o meno la stessa cosa... ma più carino :)

Update: ho scoperto girovagando questo post che dice piu o meno le stesse cose che dico qui... dateci un occhio perchè va molto piu nel dettaglio rispetto a quanto sono andato io :)

Era stata segnalata qualche giorno fa la piattaforma di Live Streaming messa a disposizione da Microsoft per Silverlight: http://silverlight.live.com.

Basta il proprio Windows Live Id per avere a disposizione gratuitamente 4gb di spazio per far vedere al mondo quanto si è bravi con SilverLight, sia esso 1.0 o 1.1 (supporta entrambe le versioni).

Peccato che il meccanismo di upload sia un tantino ostico: il funzionamento si basa su file .zip, che devono avere una determinata struttura, un file manifest.xml che contiene i parametri (che vengono levati dal file html.js, che rimarrà sul proprio web server o su un qualsiasi server esposto su internet) e, nel caso di applicazioni scritte con 1.1, la directory ClientBin con all'interno _solo_ la dll (niente file .pdb o lo zip verrà clamorosamente rifiutato :))

Per fortuna, ho trovato un ottimo post che fa un pò di luce sulla complessita di questa organizzazione... certo potevano dargli un "tantino" piu di risalto, non è esattamente facile da trovare (oltretutto nno alle 3 e mezza di notte quando invece dovrei essere ad ubriacarmi da qualche parte :P)

http://blogs.msdn.com/dthorpe/archive/2007/05/08/hello-world-with-silverlight-amp-silverlight-streaming.aspx

Preoccupatevi principalmente di creare l'applicazione con il giusto manifest, mettetelo in uno zip con dentro lo xaml e la directory clientbin, fate l'upload... e sperate che non si interrompa :P
Una volta che lo zip è stato validato e l'applicazione creata, Silverlight Live vi dirà cosa fare per consumarla da remoto, con tanto di snippet e pagina di esempio....

Che dire... ora non avete piu scuse per non provarlo! Io (dopo quattro tentativi... sigh.. è un pò lento se dovete provare con dei video) sono riuscito a creare la mia applicazione di test... non posso ovviamente farvela vedere xke è top secret per ora, ma qualche altro esempio magari lo butto su... ora nanna :)

Mi scuso se sono stato lontao dai Blog per qualche gg.. gli eventi in Microsoft, la continua mancanza di una qualsiasi connessione ad internet in casa mia, ed i clienti che NON mi permettono di navigare se non sui siti interni hanno creato non pochi problemi :)

In questi giorni di follia, comunque, mi sono capitati come al solito parecchi problemi, ma l'ultimo piu insidioso è dovuto all'ottimo componennte iTextSharp che permette di creare PDF e salvarli o mandarli direttamente al client.

Questa seconda opzione, per quanto semplice sia, mi ha datto qualche problema in quanto ho trovato in giro degli esempi non completi: lo stesso esempio nel  tutorial (http://itextsharp.sourceforge.net/examples/Chap0105.cs) è incompleto in quando istanzia un PdfWriter senza valorizzarne le proprietà, lasciandolo quindi ai valori di Default. Il che andrebbe benissimo se non fosse che, non ho ben capito se èer un problema dell'ultima build (che è di aprile) o per una imprecisione, il PdfWriter ha una proprietà CloseStream che ha come valore di default "True". Ovviamente, questo va benissimo se si parla di FileStream, così il file viene finalizzato e scritto su disco, ma quando si parla di MemoryStream, per rispedirlo al client, la faccenda diventa brutta, perchè mi si chiude il MemoryStream e non riesco piu a prenderne i Byte per rimandarli al client. Oltretutto, lo stream viene chiuso quando io chiamo document.Close() (dove "document" è un istanza di iTextSharp.text.Document) e se non chiamo il Close, il documento non viene scritto correttamente nello stream. Quindi la mia prima idea di non chiudere il document per rispedire indietro lo stream è fallita miseramente!

Soluzione: istanziare il writer e cambiarne la proprietà CloseStream in questo modo

PdfWriter writer = PdfWriter.GetInstance(document, m);
writer.CloseStream = false;

Così si può chiamare il .Close() del documento, ed avere nel proprio memoryStream "m" il contenuto completo del file per mandarlo al client.