Mindenki nagyon várja. Marketingre sokat költ a Microsoft. A fejlesztői portálok tele vannak vele, mert remek eszköz. Nem a megjelenítést szolgálja, azaz nem GUI. Mindenki használja. Mindenki meg van vele elégedve. Mindenki szidja. Mindenki mondja, hogy nem baj, a következő releaseben megoldják. Nagyon gyorsan, akár félévente jön ki belőle új release. Adatbázissal kapcsolatos. Adatbázist érünk el vele.

Igen, kitalálhattátok, hogy EntityFramework. Témánál vagyunk.

Megjelent a 4.0 béta és az alábbi bejegyzést döbbenten olvastam. Itt kell tartani egy termék 4.0-s verziójával? Ezek a nagy előrelépések a 3.0-hoz képest? A cikk itt olvasható.

Nézzük megy egy kicsit jobban, mire is gondoltam, amikor a döbbenet szót használtam. Kollégáim már tudják mire gondolok, de tudja meg más is!

• Egy ilyen készültségi szinten lévő projektben kell olyan optimalizációs lépéseket megtenni, minthogy nem hoz le minden oszlopot egy subselect, csak ami kell nekünk?
• COUNT(1) nyelvi elem direkt használata, amikor az a célszerű.
• A legnagyobb, az IN SELECT. Komolyan gondolja valaki, hogy a 4.0-ig kell várni egy kliens oldalon is jelenlévő adatstruktúra (tömb) és SQL oldalon is elérhető nyelvi konstrukció (WHERE xx IN (x,y,z…)) összekapcsolására?

Igen, emiatt van tele minden fejlesztői portál olyan jellegű kérdésekkel, hogy “Hogy tudok két táblát összekapcsolni LINQ-ban, EntityFramework-kel?” Ezek szerint nem segítség, hanem csak egy hozzászoktató eszköz, ami függőséget okoz és ha függő lettél, akkor minden fejlesztéshez a megrendelővel vetetni fogsz MsSQL Server 2010-et, supporttal, majd kell még 5 profi kolléga, aki natív SQL-hez nem ért, de kiválóan függő EntityFramework-kel.

A saját, fentihez hasonlító dolgokat megvalósító keretrendszserünk első bétája ennél sokkal több dolgot valósított meg. Mert a való életre próbáltuk alkalmazni és a tervezéskor használt use-case-ek a tapasztalatból táplálkoztak.

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.

A GridControl volt a hibás, ugyanis furcsa működéséből adódóan egy táblázatban is lehet tabbal lépkedni, vagy a sorok vagy a cellák között és amikor a végére érünk, nem tudunk merre menni. Nem is tudom, hogy miért ez az alapértelmezett működés, de kikapcsoltuk. Sok dolgunk nem volt, 2 (!!!) sort kellett a megfelelő helyen adaptálni és az összes termékünk következő kiadásában megjelenik a TabCsapda elleni megoldás.

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.

Az üzletkötőink, ügyviteli szakembereink sem értették, hogy mit akarunk ezzel, miért nem jó szerintünk a sima kis lista. Csak a végén értették meg, hogy mit is akartunk.

Ezt:

Hogyan is jött létre ez a – joggal innovációnak nevezhető – modul, amely minden ügyviteli termékünkben megjelenik és sok pozitív felhasználói visszajelzést indukált? A bizonylatok és egyéb adatelemek közti reláció, adatkapcsolat adott, erre épül maga az alkalmazás. No de ezt hogy jelenítsük meg egy gráfban, hogy  felhasználó is kedvet kapjon és használja?

Csapatunk 3 napon keresztül tervezett, brainstormingolt. Számos ötlet jelent meg a fejekben és a nagy prezentációs falon, ezen ötletek kb. 50% bele is került a megvalósult rendszerbe. Az elvárások tisztázása után kezdődött a fejlesztés. Programnyelv C#, ennek GDI és GDI+ lehetőségei kiváló kiaknázásra való területet jelentettek számunkra.

Lépések:

• Építsünk egy saját controlt.
• Bármilyen megjelenni kívánó objektum feleljen megy egy IDiagramDrawItem interfésznek, amely egy metódust definiál void Draw() és információt szolgáltat arról, hogy melyik rétegben jelenik meg a kirajzolandó adatelem int ZOrder { get; }.
• Rajzolás megvalósítása
  • override Paint()
  • void ClearAndDrawBackground()
  • void SortByZOrder()
  • foreach(... item.Draw()...)

Már a tervezési fázisban is láthatóvá vált, hogy lesznek optimalizálási kérdések, problémák, amelyek a témakör izgalmasabb részét jelentik.

Repository, hogy ne szaggasson a kép. Egyedileg rajzoló eljárások rákfenéje a sok GDI objektum, amely memóriában és időben is költséges. A memóriabeli költségeket, mivel IDisposasble, meg lehet oldani, de sokáig tart minden OnPaintben Font-os, Pen-t és Brush-t létrehozni. Erre született megoldásként, hogy a diagram ezeket publikálja, tárolja, elérhetővé teszi eg példányban, egy alkalommal való létrehozással a rajzolni képes objektumok felé. Performancia mérést végeztünk, egy átlagos diagram 740 alkalommal tud kirajzolódni egy másodperc alatt. Nem rossz, megfelel.

GraphicsPath, hogy lekerekített sarkú legyen a doboz. A C# GDI+ lehetőséget kínál arra, hogy vonalak és görbék segítségével egy “utat” hozzunk létre, amely felhasználható rajzolásra és kitöltésre egyaránt. Megvalósítottuk. Mivel ez is költséges, minden objektum a mérete alapján (amely nem állítható megjelenítés közben) első felhasználáskor (late-init) létrehozza a GraphicsPath objektumot.

LinearGradientBrush, hogy átmenetes legyen a dobozok háttere. A legnagyobb kihívás a színátmenetes doboz volt, amely egy pontoktól függő GradientBrush lett. Ennek szintén elég egy példányban léteznie, de a doboz pozíciójának függvényében kell felparaméterezni. A (rendszer által) mozgatható dobozok pedig ezen tulajdonságukat gyakran változtatják, de erre is született megoldás: late-init és re-init-by-move.

És ekkor még nem ért véget a gondolkodás, a dobozok esztétikus elhelyezésének algoritmusa felér egy komolyabb diplomamunka témakörével, erről egy következő cikkben.

Az alábbi linken pár információval szolgálnak arról, mik is ezek az újítások. Én csak a tálca újdonságait emelném ki. Ezidáig a felhasználót a jobb alsó sarokban lévő úgynevezett értesítési területen lehetett informáli dolgokról. Milyen folyamatok futnak, mennyi ideig tart még a DVD megírása, a fájl letöltése.

Ezt most egy kicsit megbolondították és elérhetővé tették folyamatjelzők és ikonok megjelenítését a tálcán, ahol eddig a program főablakának címe szerepelt és jobb esetben az alkalmazás ikonja (számos fejlesztő felejt el ikont adni). A lehetőségek között szerepel:

• Véges folyamatjelző
• Végtelen folyamatjelző (nem kiszámítható befejezési idővel)
• Hibajelző (piros)

És ehhez elég lesz a .Net framework 4.0?

Elég, sőt 3.5-tel is működni fog, le kell hozzá tölteni a WindowsApiCodecPack-et (4MB, súgóval együtt 19MB), amely forrásfájlokat szolgáltat számunkra, hogy a Windows7 fenti szolgáltatásait elérjük. DirectX is kell hozzá a leírás szerint, de ez valószinüleg akkor szükséges, ha a CodecPack DirectX-es szolgáltatásait is szeretnénk használni.

Lehetőségünk lesz elérni a ITaskBarList3 interfész SetOverlayIcon, SetProgressState és SetProgressValue metódusait, amivel lehetőségünk van a felhasználóinkat informálni egy hosszabb programfolyamat állapotáról.

Referenciaként a Core és Shell szerelvényeket kell a projekthez hozzáadni, ezen névterekben pedig megtalálhatóak a szükséges osztályok:

• Microsoft.WindowsAPICodePack.Shell.Taskbar
• Microsoft.WindowsAPICodePack.Shell.Taskbar.ProgressBar
• Microsoft.WindowsAPICodePack.Shell.Taskbar.OverlayIcon

Ezen kívül a ProgressBarExt és OverlayIconExt osztályok segítségével a Windows XP óta, a sok ablak megjelenítésekor összecsoportosuló programablakok mindegyike külön folyamatjelzővel látható el.

Tesztelés folyamatban…