Ügyvitel és számlázás 64 bites operációs rendszeren

Ma már nehéz nem 64bites processzort vásárolni, mégis elvétve találkoztunk csak 64bites operációs rendszerrel Magyarországon. És ők sem az ügyvitel vagy a számlázás miatt választották ezt a technológiát. Mi mégis fontosnak tartottuk, hogy az x64-es operációs rendszereken is működjön a termékünk.

Jópár hónapja, aki számítógépet vásárol és a neves gyártók termékét választja vagy egyszerűen saját maga rakja össze a számítógépét, nehezen tud olyan processzort választani, amely ne lenne 64bites üzemmódra képes. A 32bit és 64bit közti átállás még jónéhány évig el fog tartani, jelenleg az a trend bizonyult tartósnak, mely szerint a processzorok belső felépítése 64bites, de a rajtuk futó operációs rendszer 32bites.

Miért így használjuk?

A számítógépek gyártói, akik OEM operációs rendszerrel telepítve értékesítik termékeiket, nem véletlenül választották ezt a kombinációt. A 64bit kihasználásához legalább 4GB ram vagy több szükséges és a teljes funkcionalitást csak olyan szerverekben lehet kihasználni, ahol 1-nél (sőt 8-nál is) több processzor végzi a dolgát. Ez egyelőre nem jellemző az asztali munkaállomásokra vagy notebookokra.

A Microsoft a Windows XP 64bites változatát nem is jelentette meg magyarul, ezzel is jelezve, hogy úgysem érdemes az operációs rendszereket egyelőre ennyire átalakítani. A szoftverek sincsenek még felkészítve rá (Office, Photoshop, Nero, stb.) Használjon mindenki 32bites XP-t, Vista-t a számítógépén, legyen az akárhány bites processzorral felszerelve.

A régi ügyviteli és számlázó rendszeremmel mi lesz?

A korábbi fejlesztőeszközökkel készült termékek (Delphi, FoxPro) hallgatólagosan működnek a Windows XP 64bites változatán is, hála a processzorok azon kiegészítésének, amely a 32 bites programok működését támogatja. Ezek az alkalmazások egy 32 bites számítógépet látnak, maximum 2GB rammal. Ezen kívül számos probléma adódik abból, hogy a szükséges szoftverkomponensek (Jet driver, ActiveX könyvtárak) nem állnak rendelkezésre 64bites verzióban.

Mi a helyzet a Symbol Ügyvitellel?

A Symbol Ügyvitel már a tervezésekor arra készült, hogy futtatható legyen 64bites operációs rendszeren is, sőt a program futtatható állományai ilyen esetben 64bites működésre optimalizáltak. Minden összetevőjének (adatbázis szerver, kliens könyvtárak) létezik 64bites változata. A telepítő a környezetnek megfelelő komponenseket telepíti és ha kell, kihasználhatja a 4GB-nál több memóriát is.

cdsmall

Hogy a telepítőkészlet méretét minimalizáljuk, a ritkán használt, 64bites összetevők telepítéskor az internetről töltődnek le.

A 64bites processzorokról olvasható egy részletes leírás itt: https://en.wikipedia.org/wiki/X86-64

További 64bites információk magyarul: https://www.start64.hu

Web2, Twitter, kövess minket Te is!

Kihasználva a Web 2.0 előnyeit, megjelentünk a Twitteren: SymbolTech on Twitter

A LAB oldalon megjelenő információknál több, kevésbé szakmai hirdetményeket jelenítünk meg.

twitter

Kövess minket Te is itt: SymbolTech on Twitter

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

HashList – Dictionary többszörös kulccsal

A pascal-os időszámításhoz képest a modern framework-ökben számos segédeszköz rendelkezésre áll, sok adattároló szerkezetet használhatunk, sőt a nagy ugrás, a generikus adattípusokra az ember úgy gondol, mint a netovábbra, a végtelenre. De volt, amit nem találtunk meg…

KeyValue párokat szerettünk volna tárolni, Key szerint keresni, Value-kat kinyerni. Jött az ötlet Dictionary<Key, Value>. Specifikáció szerint viszont ennek egy Key-je egyszer szerepelhet a gyűjteményben, minden további értékeadás felülírja az előzőt. Azaz a Key-eknek egyedinek kell lenniük. Pár éve már sejtettük ezt.

Nekünk viszont irányítószámokat kell tárolnunk és hála a magyar közigazgatásnak nem minden település kap saját számot, előfordul, hogy egynél több település fut ugyanolyan “kód” (irányítószám) alatt. Az ötlet, mely szerint Dictionary<int, List<string>> adatszerkezetbe rakjuk az információkat, jónak tűnt, de hátha ezt már valaki kidolgozta.

És ekkor találtuk meg többedszerre az NGenerics családot, amely számos, C#-ból kimaradt, bonyolultságuk és sokrétűségük miatt speciális tudást igénylő generikus típussal engedi bővíteni a készletet. Ennek HashList osztályát használtuk, amely az alábbi nyelvi konstrukcióban engedte feltölteni ZIP (IRSZ) törzsünket.

 

citylist.Add(2066, "Szár");
citylist.Add(2066, "Újbarok");

 

Az osztálygyűjtemény nagyon nagy. Szerettük volna kerülni az irányítószám kezelés miatt akár 30-40 másodperccel is megnövekedett fordítási időt. Ezért csak bizonyos részeket használtunk fel belőle. Matematikusok tervezték, tele van interfésszel, látogató termintával és minden szépséggel, emiatt az általunk használt osztályhoz a következő fájlok mindegyikére szükség volt:

 

HashList.cs
IVisitable.cs
IVisitableCollection.cs
IVisitableDictionary.cs
IVisitor.cs
VisitableHashtable.cs

 

Projektünk sikeresen kiadásra került, a projektben résztvevő személyek mindegyike sikeresnek értékelte a megoldást. Köszönjük NGenerics!

Diagram engine – miért C#

Ügyviteli rendszereknél ritka, hogy diagramot jelenítünk meg valamit, hiszen minden adat táblákban van, azok megjelenítéséhez pedig ideális valamiféle grid. Néha szoktak beépített grafikon segítségével felhasználókat elképráztatni, de az egyedi rajzolásos digram nem mindennapos.

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:

voucherdiagram

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.