Bejegyzés

PowerCommands – azaz ne hiányozzon semmi a VS2008-ból

Visual Studio 2008 remek eszköz. Számunkra egy dolog hiányzik belőle, mégpedig az, hogy a szépen, névterekben elhelyezett osztályok, ablakok, usercontrol-ok ugyanilyen szép mélységű könyvtárfát hoznak létre, amit ha egyszer kinyitottunk, sok kattintással tudjuk összecsukni.

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…

 

collapseproject

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

Ha várni kell a Windowsban – A jó öreg homokóra

Gyakran fordul elő, hogy homokórát kell megjelenítenünk, mert valamilyen művelet hosszabb időt vehet igénybe. A felhasználó pedig várakozzon, ahelyett, hogy a beviteli mezőket próbálja szerkeszteni vagy a gombokat működésre bírni.

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.

Kivételek típusai – melyiket dobjam?

A kivételkezelés alatt sok fejlesztő a catch ág megvalósítását gondolja, de ugyanolyan fontos a kivételek eldobása is. Nem szabad azzal megelégedni, hogy dobunk egy ApplicationException-t, sokkal precízebb, ha a típusos esetekben (rossz paraméter, nem jó képformátum) a beépített kivételosztályokat használjuk.

Lássuk, mik ezek:

Kivétel osztály Kiváltás oka
SystemException Futásidejű hiba, a kivételes ősosztálya
AccessException Egy típus elemeléréseinek hibája (metódus, mező, property)
ArgumentException Metódushívás esetén hibás paraméter
ArgumentNullException Metódushívás esetén null paraméter, ha azt a metódus nem tudja kezelni
ArgumentOutOfRangeException Paraméter értéke adott határokon kívül esik
ArithmeticException “Matematikai” hiba
ArrayTypeMismatchException Típusos tömbön végzett művelet egy idegen típussal
BadImageFormatException Rossz képformátum
CoreException Futásidejű kivételes ősosztálya
DivideByZeroException Nullával való osztás
FormatException Argumentum formátuma nem helyes (pl: String.Format)
IndexOutOfRangeException Tömb indexelése túlmutat a határokon
InvalidCastExpression Futásidejű Cast művelet nem hajtható végre
InvalidOperationException Nem megfelelő (idejű?) művelet hívása
MissingMemberException DLL verziószám ütközés, eltérés metódushívás közben
NotFiniteNumberException Nem valós szám (decimal, float; NaN, Infinity)
NotSupportedException Nem létező metódus hívása (reflection?)
NullReferenceException NULL értékű változó által hivatkozott objektum elérése
OutOfMemoryException Memória elfogyás
StackOverflowException Verem műveletek memória elfogyása (rekurízió)

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.

Egyedi sorosítás – IXMLSerializable megvalósítás

C#, remek nyelv. Szinte mindent lehet sorosítani, XML-be menteni. Nem is kell kézzel ezeket megírni, összerakni. De egy pár dolog kimaradt. Talán oka is van, hogy miért, de ez nem lényeg. A lényeg, hogy meg lehet valósítani.

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.

Takarítás szoftverkiadás előtt

Szoftvertermék kiadása előtt mindenképp ajánlott a kódot revizionálni. Több hónapos, több fejlesztővel folyó fejlesztés során számos olyan dolog “marad” a forráskódban, amely nem maradhat benne a kiadás előtt.

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:

wrongway

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! 

sweep