dicembre 2003 Blog Posts
A quanto pare MS ha deciso di abbandonarli (ma qualcuno ci ha mai creduto?)
Conoscere tutti i dettagli relativi ad una determinata unita' (removibile, totalspace,freespace, label...) richiede l'uso delle Win32 API, con Whidbey questo non sara' piu' necessario grazie alla classe System.IO.DriveInfo
Stanchi di utilizzare sn.exe e di tutta la procedura necessaria per firmare digitalmente le vostre assemblies?, ecco un interessante add-in (free of course!) per Visual Studio 2003
Ho gia trattato l'accesso thread-safe a controlli windows form ma spesso non ci rende conto che ci troviamo in un identica situazione anche utilizzando alcune classi del framework le quali utilizzano threads presi dal threadpoll per gestire la loro funzionalita'.Prendete ad esempio il timer presente in System.Timers
using System.Timers;
System.Timers.Timer tim=new System.Timers.Timer();tim.Interval=500;tim.AutoReset=true;tim.Elapsed+=new ElapsedEventHandler(tim_Elapsed);tim.Start();
private void tim_Elapsed(object sender, ElapsedEventArgs e){System.Diagnostics.Debug.Assert(label1.InvokeRequired==false);label1.Text=DateTime.Now.ToString();}
Lanciando questo esempio noterete che il debugger si fermera' sulla Debug.Assert in quanto l'evento Elapsed viene servito in un thread diverso.
Per far si che l'evento venga generato nello stesso thread e' possibile associare la proprieta' SynchronizingObject dell'oggetto Timer al controllo che vogliamo utilizzare nell'evento, in questo modo...
E' appena uscita la beta..
Quindi avremo anche gli orologi con .NET...Avete "programmato" la sveglia?
Microsoft ha recentemente pubblicato i dettagli relativi al nuovo SP2 per Windows XP (ora in beta)
Brad Abrams segnala due interessanti novita' presenti nel Garbage Collector di Whidbey.La prima e' GC.AddMemoryPressure / RemoveMemoryPressure ed e' legata a 'piccoli oggetti' i quali pero' referenziano grandi quantita' di memoria (magari unmanaged)AddMemoryPressure e la relativa Remove non fanno altro che informare il GC della 'vera' occupazione di memoria dell'oggetto in modo che, se ncessario, lo rimuova della Heap liberando percio' piu' memoria di quanta 'normalmente' attesa.La seconda e' legata a risorse unmanaged quali Handles,Connessioni a Databases.Usando GC.HandleCollector a i relativi metodi Add/Remove e' possibile forzare l'intervento del GC quando il numero di handles utilizzati supera un range prestabilito in modo...
A qualcuno è piaciuta la mia idea... :-)
Se siete confusi dalle varie sigle che circondano LongHorn (WinFX,Avalon,WinFS,Indigo...) ecco delle interessanti FAQ
Per chi smanetta con XAML ecco un patch per Whidbey... :-)
Con .NET capire per quale motivo un form sta per essere chiuso non e' cosa da poco, mentre in VB6 era banale (basta testare UnloadMode).Giocando con l'object browser di Whidbey ho trovato un enigmatico FormCancelEventArgs il quale tra i vari parametri ha un enumerato CloseReason che vale:FormOwnerClosingMdiFormClosingNoneTaskManagerClosingUserClosingWindowsShutDown
Questo mi fa supporre che i forms di Whidbey avranno un evento FormClosing(sender as Object, e as FormCancelEventArgs) :-)