Ettől még jól használható, pláne, ha már a VS2005-höz is létezett VB-ben írt makró, ami becsukja a fát. Ennek volt kezdetleges változata, amely csak 1-1 szintet csukott be. És volt, ami már rekurzívan is működött. A tegnapi napig…

Egy VS2008 biztonsági frissítés feltelepítése óta nem működik. Lenne erőforrásunk debugolni, de csak-csak van más megoldás is, mondjuk egy ingyenes Microsoft tool!

A szoftverfejlesztő cégek mindegyike pénzért adja a termékeit. Bizonyos “kultúrákban” a termék ingyenes, a támogatás, ami által a tényleges előnyt szerzed, viszont fizetős, lásd Apache, Linux, MySql. Ebből kiindulva nem is keresgéltünk nagy tudású, de mégis ingyenes, “5 éve fejlesztjük, nagyon jó” termékek irányába, hiszen semmi nincs ingyen.

És találtunk egy tool-t, amely megfelel a céljainknak, hivatalos Microsoft termék, ingyenes, gyakorlatilag egy extension, amelyet minden bizonnyal a Microsoft is használ saját berkein belül. Talán a létrejötte is annak köszönhető, hogy valamelyik fejlesztő majdnem fellázadt a saját eszközük ellen.

Letölthető erről az oldalról.

PowerCommands for Visual Studio 2008

Régebbi programozási nyelvekben (Delphi, FoxPro) a hosszú műveletek automatikusan beállították a homokóra üzemmódot. Viszont nem kezelték jól a beágyazott műveleteket, azaz 10 darab SELECT végrehajtása egymás után 10 homokórás villogást eredményezett. Ez a mai világban inkább szégyenletes, mint felhasználóbarát.

Ezt a problémát oldottuk meg az alábbi kódrészlettel:

using System;
using System.Windows.Forms;

namespace SymbolTech.Common
{
    public class WaitCursor : IDisposable
    {
        private static int waitcursorlevel = 0;

        public WaitCursor()
        {
            waitcursorlevel++;
            if (waitcursorlevel > 0)
                Cursor.Current = Cursors.WaitCursor;
        }

        public void Dispose()
        {
            waitcursorlevel--;
            if (waitcursorlevel == 0)
                Cursor.Current = Cursors.Default;
        }
    }
}

Minden (hosszabb) műveletet beágyazunk egy using(new WaitCursor()) blokkba. Ezzel a következő előnyöket érjük el:

1. A műveletek minden esetben “homokórázni” fognak.
2. A beágyazott műveletek (külső blokk már homokórában dolgozik, a belső, mondjuk 100 iteráció is bekapcsolja a homkórát) nem fogják villogtatni a kurzort.
3. Véletlenül sem felejtjük el visszakapcsolni az alapértelmezett kurzort, amennyiben a műveletek végrehajtásra kerültek.

Lássunk egy példát, a használatára:

        private void DummyMethod()
        {
            using (new WaitCursor())
            {
                Thread.Sleep(100);
            }
        }

        private void button1_Click(object sender, EventArgs e)
        {
            using (new WaitCursor())
            {
                Thread.Sleep(500);
                for (int i = 0; i < 10; i++)
                    DummyMethod();
            }
        }

A példában egy beágyazott, többször (10x) végrehajtott műveletet látunk, amelyek összességében 1.5mp-re átkapcsolnak homokórára, de közben nem villog a kurzor.

Lássuk, mik ezek:

A fenti lista számos lehetőséget kínál a fejlesztőknek a megfelelő kivétel eldobásában. Ezek használata nagyban megkönnyíti a hibakezelést és hibakeresést, a metódus írója pedig publikálhatja, hogy mit várt és mit kapott.

A generic List<>-et lehet sorosítani, de előtte kell egy plusz származtatási szinten készíteni. Dictionary<T,U>-t nem lehet. De van megoldás. Csináljunk egy sorosítható Dictionary-t.

    [XmlRoot("Dictionary")]
    public class SerializableDictionary<TKey, TValue> : IXmlSerializable
    {
        public XmlSchema GetSchema()
        {
            return null;
        }

        public void ReadXml(XmlReader reader)
        {
            XmlSerializer keySerializer = new XmlSerializer(typeof(TKey));
            XmlSerializer valueSerializer = new XmlSerializer(typeof(TValue));

            bool wasEmpty = reader.IsEmptyElement;

            reader.Read();

            if (wasEmpty)
                return;

            while (reader.NodeType != XmlNodeType.EndElement)
                try
                {
                    reader.ReadStartElement("Item");
                    reader.ReadStartElement("Key");
                    TKey key = (TKey)keySerializer.Deserialize(reader);
                    reader.ReadEndElement();

                    reader.ReadStartElement("Value");
                    TValue value = (TValue)valueSerializer.Deserialize(reader);
                    reader.ReadEndElement();

                    reader.ReadEndElement();

                    reader.MoveToContent();

                    this.Add(key, value);
                }
                catch { }
            reader.ReadEndElement();
        }

        public void WriteXml(XmlWriter writer)
        {
            XmlSerializer keySerializer = new XmlSerializer(typeof(TKey));
            XmlSerializer valueSerializer = new XmlSerializer(typeof(TValue));

            foreach (TKey key in this.Keys)
            {
                writer.WriteStartElement("Item");
                writer.WriteStartElement("Key");
                keySerializer.Serialize(writer, key);
                writer.WriteEndElement();

                writer.WriteStartElement("Value");
                TValue value = this[key];
                valueSerializer.Serialize(writer, value);
                writer.WriteEndElement();

                writer.WriteEndElement();
            }
        }
    }

Ahogy látható, csak a saját szintünket kell megvalósítani, a TKey és TValue elemek sorosításával már a saját osztályuk foglalkozik. Extrém eset ha a TValue is egy sorosítható Dictionary (valós példát nem tudunk jelenleg mondani), ilyenkor ennek az objektumnak a sorosításakor szintén a fenti algoritmus fog lefutni.

Eddigi fejlesztési tapasztalataink alapján összeszedtük, hogy mikkel találkoztunk eddig. Nem titok és nem szégyen, velünk is előfordul, mi is mulasztottunk már:

Direkt lassítás. Nem károkozás, sokkal inkább professzionális munkamódszer, amikor lassabb számítógépet emulálva szándékos lassításokat helyezünk el a kódban. Nem célszerű ezt a kiadott verzióban is benne felejteni.
Megoldás: #warning pragma használata

Felugró ablakok. Hibakeresési céllal sok programozó használ felugró ablakokat, sőt – bár nem illik, de néha az átlagosnál durvább verbális kifejezéseket is. Mivel ezek hibafelderítési célokat szolgálnak, általában ott maradnak benne a kódban, ahol csak alapos tesztelés során talál rá az ember/tesztelő. A végfelhasználónál megjelenő, nem értelmezhető, oda nem illő üzenetek presztízsrombolók.
Megoldás: Üzenet megjelenítése Debug.WriteLine()-nal.

A bűvös new Random(). A végfelhasználó nem veszi észre mindig, de számos helyen alkalmazunk véletlen tesztadatokkal való feltöltést. Nem szerencsés, ha a végfelhasználónál történő új vevő rögzítéskor a vevő neve és címe már kitöltésre került tipikusan “Kovács Géza” és “Kiss János” nevekkel.
Megoldás: new Random() konstruktorok megkeresése a forráskódokban.
Saját tapasztalat: Nem minden ilyen konstruktor kell, hogy megszűntetésre kerüljön. Legutolsó projektünk a tisztítás után 7 helyen használta a Random konstruktort.

Ideiglenes fájlok írása. XML vagy bármilyen más adatátvitel implementálása közben gyakran mentjük az átvitt adatokat átmeneti fájlokba. Sok esetben ez a C:\tempfile.dat, amely azon kívül, hogy az ügyfél számítógépén furcsán mutat, rendes biztonsági házirendet tartalmazó környezetben (a fájlírás letiltása miatt) IOException-t eredményez.
Megoldás: if DEBUG direktíva használata fájl írásakor.

Takarításra fel!