C# Winform/WPF wrapper
2012-12-06T14:44:04+01:00
2012-12-08T10:07:35+01:00
2022-07-23T18:11:22+02:00
  • Valahogy az az érzésem, hogy hamar össze tudnák dobni egy alkalmazást WinRT-re is, csak kevés olyan asztali alkalmazást tudok elképzelni, ahol ez a jobb választás.


    Mint valaki bölcsen megjegyezte, "mindig minden sokkal bonyolultabb, mint amilyennek látszik, vagy amilyennek képzeljük".

    Tessék, egy példa, hogy milyen triviális elmenteni egy bitmap streamet PNG-be.

    Az a gond a WinRT-vel, hogy nincsenek meg a megszokott helper class-ok, szinte mindent elölről kell felfedezni. Sok minden egyszerűbb lett (összességében pedig egy ilyen bonyolultságú felületet nyilvánvalóan bonyolultabb lenne hagyományos .NET alapokon megírni), de teljesen újra kell tanulni.
    Mutasd a teljes hozzászólást!
  • Konstruktívabb vizekre evezve (lehetne inkább a mondanivalóra reagálni és nem azzal foglalkozni, aki mondja) még mindig nem láttam érdemi választ a felvetéseimre.

    Készséggel elfogadom, ha nincs igazam, de ez esetben jó lenne valami érvelést látni.

    Tételesen a tények:

    - Nem minden feladat igényli, hogy az örökkévalóságig elfussanak, sőt ezek a ritkábbak. Ezeknél valóban nagyon gondosan kell eljárni (számítani kell rá, hogy már az oprendszer sem lesz támogatott a software életciklusán belül).

    - A Microsoft sokáig támogatja a technológiáit. Attól, hogy jön egy új technológia (WPF, WinRT) a régiek változatlanul futnak tovább. Erre példák: WinForms gond nélkül fut máig (Windows 98-ra, 10 éve .NET 1.0-ra írt kód minimális változtatással vagy anélkül újrafordítható .NET 4.5-re, Windows 8 alá), a kidobott Silverlight 2021-ig támogatva van. Innen kezdve értelmezhetetlen arra hivatkozni, hogy ki kell dobni bármit, mert itt az új. A meglévő támogatva van, zöldmezős projecteket pedig az új technológiával érdemes létrehozni.

    - Megfelelő software-tervezéssel (moduláris ill. többrétegű felépítés) az esetlegesen kidobásra ítélt rész önmagában lecserélhető, nem kell egy technológiai váltás miatt az egész rendszert kidobni (MS technológiákról beszélünk, ugye, nem platform-váltásról).


    Akkor most vissza az eredeti kérdéshez: miért kell wrappereket írni? Szerinted bármelyik projected hosszabb életű lesz, mint a Windows Forms támogatása?
    Mutasd a teljes hozzászólást!
  • egy év alatt elavulttá válik, mert a MS-nél kitört az aktuális forradalom. Ha mondjuk egy év múlva kukázzák a winrt-t, és helyette jön egy újabb világmegváltó, akkor akik most winrt-znek megszívják.


    Igen, ezt ismételgeted, de a kérdésre még mindig nem válaszoltál.

    Mi a probléma a meglévő WinForms appok futtatásával? Nem futnak? Miért kell őket kukázni?
    Mutasd a teljes hozzászólást!
  • Ez esetben a megjelenítés nem valós megjelenítés, a MessageBox egy user interaction felület, amiben üzenetet adsz és választ kaphatsz.


    szvsz. ez is megjelenítés.
    Ha mindez egy interfaceból indult volna, akkor nagy vonalakban lenne egy ShowYesNoDialog függvényed, ami a háttérben mindent csendben elintéz. Ezek után, hogy milyen technológiához implementálod már teljesen lényegtelen.
    Mutasd a teljes hozzászólást!
  • "a WinRT egyenesen szívrohammal fenyeget"

    Hát nem kaptam.

    A DevPortál Win8 előadását végigültem és megállapítottam, hogy nem egy nagy szám, ismerve a WP7 programozást.

    Az elvek hihetetlenül leegyszerüsödtek az egy képernyő, egy adatlap, viszzaléphetsz, eldobhatod, továbbléphetsz, a WinRT-n keresztül kérsz szolgáltatásokat stb. világban.

    Valahogy az az érzésem, hogy hamar össze tudnák dobni egy alkalmazást WinRT-re is, csak kevés olyan asztali alkalmazást tudok elképzelni, ahol ez a jobb választás.

    A WPF-el meg csak a tapsztalat hiánya a gond.
    Egyrészt hülye szokásom, hogy mindent elolvasok, így mielőtt az első kódsort leírtam volna, már a működési elveket, főbb ismérveket és számtalan technikai trükköt ismertem (mert le szokom' jegyzetelni az olyan infókat, amelyek várhatóan érdekelni fognak a jövőben).

    Általában tudom hogy mit és hogyan kéne csinálni, csak az eszköz tés a szintaxist nem ismerem, amivel azt meg lehet oldani.
    Ugyanis a dolgok értelémét, lényegét és célját kell felismerni, aztán a technikai problémák már majdcsak megoldódnak valahogy

    Abban igazad van, hogy nem szeretek alapvető ismeretek hiányával belekapni dolgokba, de azért már vagy tucat(!) környezetet (amiknek gyakran közük sem volt egymáshoz) láttam és még mindig túléltem valahogy
    Mutasd a teljes hozzászólást!
  • Bocs, próbáltam jelezni már a bejegyzésemben "szívózás" visszatetsző módját. Nem jellemző rám.
    De nem lehetett kihagyni.

    Nem a szakmai képességedet vitatom (azt nem ismerem), de a válaszod (és valahol egy másik "wpf mindenek felett, a winform már szemét, ki lehet dobni" bejegyzésed) azt mutatja, hogy tapasztalatlan vagy.

    Ha nem érted, mi a másik problémája a szituációval, várj még pár választ és próbálj elmélyedni.

    Egy örök tanács a "vén rókától": mindig minden sokkal bonyolultabb, mint amilyennek látszik, vagy amilyennek képzeljük.
    Vagy egy másik: az egyszerű és gyors megoldások általában rossz megoldások.

    Vannak még ilyen bölcseleteim, de nem terhellek.
    Mutasd a teljes hozzászólást!
  • "ilyenkor derül ki,hogy a megjelenítés mennyire nem különül el a kód többi részétől, hanem szerves része."

    Ebben a szituációban nem ez a gond.
    Én általában igyekszem különválasztani (amennyire megengedi az idő, mert adott a lehetőség a körültekintő tervezésre és kicsit bonnyibb kódösszerakásra )

    Ez a helyzet annyiban más, hogy az ősrégi problémára nincs más válasz.
    Arról, hogy mikor adjunk vissza exceptiont és mikor hibakódot, legyen-e user interaction a kódban vagy dobjunk exceptiont/adjunk hibakódot vissza, illetve hogy ha nincs user interaction, akkor menjen-e tovább valamiképp (oldja fel magának a problémát) vagy lépjen ki a kódból: na ezek egyenként is akár egy-egy doktorit megérnek.

    Ez esetben a megjelenítés nem valós megjelenítés, a MessageBox egy user interaction felület, amiben üzenetet adsz és választ kaphatsz.
    De technikailag leszakítható a GUI felületről és akár SMS-ben is kiküldheti az üzenet szöveget és visszakaphatja a választ. Vagyis egy teljesen leválasztható 'izé'.
    Annyit "tanultam" az esetből, hogy "ne bízz senkiben", és minden kétséges helyzetre csináljak wrappert. Nem mellesleg pl. a MessageBox használata kényelmesebbé is válik vele, sok a tipushelyzet, amikor rutinparaméterek vannak.
    És ha van wrapper, akkor akár megvalósítható a GUI-tól teljesen független használat is vele, pl. az említett más csatornába beterelés, a helyzetek naplózása stb.

    Nem véletlen, hogy a WPF alá is (ugyan teljesen felesleges szintaxis váltással!), de (ahogy nézem) változatlan működéssel és tartalommal áthozták.
    Mert ez valójában nem része a WPF-nek és nem része a WinForm-nak sem. Ez technikailag teljesen GUI független, speciális esetekre van kitalálva.

    Ebben az esetben a "rendkívüli helyzet" lekezelésére szolgál egy kérdés feltétele a user-nak.
    Nem tökéletes a megoldás, mert a helyes eljárás az lenne, hogy a hibás állapotban (pl. ellentmondó bejövő adat), amikor a futó folyamatnak döntenie kell, nem bízik az egybites userben, hanem eldobja magát és kéri, hogy egy rendszergazda tegye rendbe a dolgokat.

    Ez szép és jó, csak akkor meg a felhasználó megy a falnak dühében!

    Így felteszek neki egy kérdést és az ő felelőssége, hogy jól döntsön.
    Ha dönt, akkor nem akad le a munka, megy tovább minden. [és még mindig hívhatja telefonon a rendszergazdát, ha kell]

    Na de van pl. engedélyező biztonsági kérdés is. Előre kérdezzek meg dolgokat a GUI-n, amikor még nem is tudok róla (mi is vár a kódra majd)? Vagy ne kérdezzek, csak "intézkedjek"?

    Nem! Jó ez így. Ez nem GUI kérdés. Ez egy dühítő programtervezői slendriánság (vagy marketinges blődség) kérdése.
    Csak nem ér ennyit, pillanatok alatt feloldható. Csak dühítő, amikor egy milliárdos költségvetésű cégben alap hibákat követnek el. Elvi kérdés csupán, ezért szívóztam vele.
    Mutasd a teljes hozzászólást!
  • "javaslom a Conditional attributum megismerését."

    Köszi, ilyen alakban már használom.

    [Conditional("DEBUG")] [DebuggerStepThrough]

    Azt nem látom, hogy az én példámnál mit segítene, hiszen egyetlen függvényen belül akarok eltérő dolgot csinálni, attól függően, hogy WinForm-os assemblyhez vagy WPF-es assemblyhez teszem hozzá a forrást.

    Mutasd a teljes hozzászólást!
  • Semmi a világon azon túl, hogy ha csináltál egy több tíz-száz emberéves projektet akkor egy év alatt elavulttá válik, mert a MS-nél kitört az aktuális forradalom. Ha mondjuk egy év múlva kukázzák a winrt-t, és helyette jön egy újabb világmegváltó, akkor akik most winrt-znek megszívják.

    A programokat pedig általában nem úgy fejlesztik, hogy ha bejön egy új jogszabály akkor nulláról újraírjuk a programot. Minél nagyobb és komplexebb a progi, annál kevésbé. A helló világ újraírása persze nem téma, de egy nagy projektet ritkán kukáznak. Lásd anno az y2k probléma, amikor a sírból húzták elő az öreg COBOL-os programozókat, hogy a 70-es évek óta futkározó nagy rendszereket megmentsék. És szerintem azok a progik ma is futnak...
    Mutasd a teljes hozzászólást!
  • Akkor már jobb példa egy DOS-os egészségügyi rendszer.




    Nem jó példa. Az egészségügyi rendszerek szerves részét képező pl. OENO kódrendszere kb. havonta változik. Nem feltételnül a kódok, hanem az azokra adott elszámolási szabályok (mennyiségi korlátok, forint értékek, egymást megengedő vagy kizáró eljárások, stb). Ez alapján a kódolás alapján fizetik a szakrendeléseket és fekvőbeteg ellátásokat.

    Persze ezek nagy részét elég lenne csak a letölthető adatbázisokból importálni, de mivel a fejlesztő nem hülye, így saját frissítében oldja meg ezt ezért is külön díjat kérve vagy jobb esetben szimpla biztosítékként a havi díjába bekalkulálva.
    Mutasd a teljes hozzászólást!
  • Ez rendben van, de mi a probléma a meglévő WinForms appok futtatásával?

    DOS-os rendszerek: mint írtam, változatlanul és jól működő, meglévő rendszereket gond nélkül lehet akár emulálni. Mondjuk nem biztos, hogy részemről egy olyan könyvelőirodához fordulnék, amely ilyeneket használ, mivel az adószabályok változása tipikusan elég gyakori jelenség.

    Akkor már jobb példa egy DOS-os egészségügyi rendszer.
    Mutasd a teljes hozzászólást!
  • Ez tisztára a cégmérettől függ. Egy igazán nagy multi nem fogja csak úgy kidobni a kódbázisát amit tizenéve fejleszt, csak mert a winforms nem trendy. És nem is azért, mert nem lenne pénze újat fejleszteni, hanem mert nem akarja felvállalni a váltással való költségeket és főleg bizonytalanságot.

    Amúgy pár éve még elég sok könyvelő dolgozott DOS-os rendszerekben, ami azt jelenti, hogy ott sem feltétlenül a vedd meg és dobd el dolgot szeretik a userek.
    Mutasd a teljes hozzászólást!


  • Ezt be kéne keretezni.
    Mutasd a teljes hozzászólást!
  • A legtöbb, ideírt felvetésedre már válaszoltam a másik topicban.
    Mutasd a teljes hozzászólást!
  • Én kérek elnézést, amiért hobbiprogramozóként beleszólok emelhu, a profi programozó témájába, de néhány gondolat.

    Mivel én csak egy hobbiprogramozó vagyok, meglehetősen ritkán írok olyan kódot, amelyre 20-25 év után még szükség van, hallottam a profiktól ugyanis egy furcsa fogalmat, úgy hívják,
    software életciklus
    .

    Nálunk, hobbiprogramozóknál ugyanis elég ritkák azok a feladatok, amelyek pontosan ugyanolyan feldolgozást igényelnének negyed évszázaddal később. Ez a fránya világ már csak ilyen, nekem is nagyon furcsa, de folyton változik szinte minden területen, és a különböző software megoldásokat bizony folyton ezekhez a változó igényekhez kell igazítani. Általában negyed évszázad alatt többször is eljöhet az a pont, amikor a leggondosabban megtervezett rendszer sem alkalmas önmagában további bővítésre ill. változtatásra, ekkor húzni kell egy vonalat, és érdemes teljesen újratervezni, figyelembevéve a legfrissebb igényeket, és természetesen az akkor elérhető, legújabb technológiát használni.

    Így amikor Kukipapa, a hobbiprogramozó felméri egy feladat erőforrásigényét, belekalkulálja azt a plusz munkát, amit még érdemes belefektetni, hogy az adott program a jövőben is futtatható legyen. Ugyanis létezik az a mértékű pluszmunka, ami már nem feltétlenül kifizetődő, mivel nem biztos, hogy akár 5 év múlva még szükség lesz az adott megoldásra. Ez a nehéz ebben a szakmában, pardon, hobbiban, hogy az ember megtalálja azt az egyensúlyi állapotot, ami lehetővé teszi a jövőbeli változások lekövetését, azonban nem visz el feleslegesen belefektetett munkaidőt, ez utóbbit ugyanis inkább érdemes máshova fektetni. Azt hallottam a profiktól, hogy neve is van annak a jelenségnek, amikor valaki átesik a ló túloldalára, úgy hívják,
    over-engineering
    .

    Egy másik, furcsa nevű fogalom alkalmazása is segít néha a munkámban, akarom mondani, hobbimban, neve:
    többrétegű architektúra
    . Mivel csak egy hobbiprogramozó vagyok, nem tudom, pontosan mire jó, mindenesetre elég hatékonyan elválasztja a megjelenítést a működéstől, így általában nem szokott túl nagy kihívást jelenteni, ha a meglévőtől gyökeresen eltérő megjelenítési technológiát kíván a megrendelő (pl. a desktop kliens mellé egy webes interface-t, vagy Forms helyett WPF-et). Nyilván van vele feladat, de nem jelenti a megoldás teljes újraírását, a korábbi kódbázis kidobását.

    Az igazán bonyolult, és nem triviális programkódok általában eleve általánosan megírt libekben vannak, így szépen újrafelhasználhatók. Azoknak eleve nem szabadna valamilyen technológiához kötődniük, így szépen túlélhetik a változtatásokat. Ha mégsem, hát szépen lecserélődnek egy ugyanolyan interface-t használó újabb libre.

    Azt már csak félve merem megjegyezni, hogy nem nagyon ajánlom a betekintést a WinRT használatába, mert ha a profi programozó úr hátast dobott a Forms -> WPF váltástól, akkor a WinRT egyenesen szívrohammal fenyeget, hiszen ott a nyelvi alapokon túl teljesen új class libeket lehet csak használni (más nevek, más működés), ami a fentiek alapján szokatlan lehet majd az olyan profiknak is, mint amilyen Ön. Szerencsére a WinRT kliens oldalra készül.

    Mindezeken túl, mint már el lett mondva, a Microsoft kedveskedik 20 év elteltével is támogatást nyújtani, így azokban az esetekben, amikor valóban változtatás nélkül van szükség az adott megoldásra, sokszor gond nélkül lehet azokat futtatni a legújabb platformon is (a Forms programok még mindig szépen futnak Win 8 alatt is, ugye).

    Legvégső esetben pedig még mindig ott az emuláció.


    Üdvözlettel,

    Kukipapa, a hobbiprogramozó
    Mutasd a teljes hozzászólást!
  • Nekem pedig egy sok éve jól muzsikáló kódomban az összes üzenetküldést át kell írnom (vagy egy wrappert írni, de az is ugyanaz, tételesen módosítani kell - legfeljebb a jövő biztosabb a MS t_ketlenkedései ellen).


    ilyenkor derül ki,hogy a megjelenítés mennyire nem különül el a kód többi részétől, hanem szerves része. Ezért ha bármilyen apró változás történik, akkor borul(hat) a bili.

    Az összes ugyanezen sémára épülő kód átírása is egyszerűnek tűnik egy find/replace használatával ami képes végigszáguldani az egész solution-on, hogy meghívhasd a SAJÁT függvényedet ami eldönti, hogy az wpf vagy form vagy akármi a jövőben keletkező, még ki nem talált UI létforma.
    Tény, hogy ezt most hirtelen statikussá kell tenned, de ez a későbbiekben a rendszer méretétől függően X időegység alatt refactorálható.


    továbbá
    ezen szerkezet helyett
    #if
    #else
    #endif
    javaslom a Conditional attributum megismerését. Nagyban segítheti a munkádat.
    Mutasd a teljes hozzászólást!
  • Új kódot meg már évek óta nem javasolt Forms-ban írni. De ettől még működik.


    Ez azért nem ennyire egyszerű történet. Kezdetben volt a winforms, mint a .NET-es UI. Arról volt szó akkor még, hogy ez lesz az új windows API, és hogy milyen jó hogy a programoknak nem kell mindenféle MFC, VCL, stb könyvtárakkal szenvedni, mert ezt már közvetlenül is tudja használni a program.

    Aztán jött a WPF, a jövő. Igaz, hogy XP-n tetűlassú, igaz hogy nem csak ott, igaz hogy nincs benne datagrid (legalábbis akkor még nem volt), igaz hogy a mai napig sincs normális designer support, de ez a jövő. Aztán, ha az ember túlteszi magát az ilyen dolgokon, és örül hogy azért lassan a MS csak adott datagridet, igaz hogy kicsi, sárga, savanyú de legalább oszlopok és sorok vannak, csak ne akarj olyan hülyeséget hogy az oszlop tartalmát balra igazítod, mert az 3 oldal xaml kód. Azért tegyük hozzá, vannak benne iszonyú jó dolgok is, Pl. databinding, mmvc, skálázhatóság, transzformációk, xaml style triggerek.
    Na, mire megszokta volna a nép a WPF-t, akkorra elkiáltotta magát a MS, hogy emberek, hagyjátok a WPF-et, az elavult, jön a Silverlight. Ez a jövő, új kódot WPF-ben nem javasolt írni, és amúgy is milyen jó már, hogy browserben is fut a dolog. csak várd ki amíg betöltődik. Aztán most szegín ezüstfény is ki lett kukázva, és jött a winRt ahol a böngészőt leváltja a kvarcjáték. Ami leginkább azért vicces, mert jelenleg a MS-nak nincs olyan GUI API-ja desktopra amiben javasolt lenne új kódot írni. Persze nekiállhatsz metrózni, de az egyrészt csak win8-on fut (=win7-es, XP-s userek kitiltva a vevők közül), másrészt desktopon elég fájó élmény userként ilyesmit használni. Arra pedig, hogy a win8 nem ismétli meg a kb. hasonló kvalitásokkal felvértezett WP7 pályáját a kvarcjáték piacon, semmi garancia nincs. Arra pedig végképp nincs, hogy nem jön egy év múlva a MS, hogy ez a kvarcjáték dolog nem jött be, ezért a WinRt-ben már nem javasolt fejleszteni, de figyusz, van itt egy újabb API ami már tuti a jövő, mert nem csak javasriptben és C++-ban, de BrainFuck-ban is lehet rá fejleszteni, és lesz hozzá vadiúj XAML amibe bemelünk egy-két dolgot a postscriptből, a z80 assemblyből és a forth-ból hogy még több programozó tudja használni. És ez már karórán is tud majd futni, igaz annyi megkötés lesz a rendszerben, hogy csak számokat tud megjelenítei, de azt analóg módon is. Viszont már megvan az új karóra hardver követelménye: kell bele legalább 1 giga RAM, 64 gigás flash, és legalább két magos processzor.
    Mutasd a teljes hozzászólást!
  • Ilyen csak a wine van, az pedig nem egyszerű történet ha deploymentről van szó, lásd Kylix.

    A WPF és a winforms alapvetően más. Lehet hogy van egy-két függvény amit implementálhattak volna ugyanúgy, de alapvetően a két rendszer koncepciója nagyjából ég és föld. Sokkal nagyobb az eltérés, mint Pl. a GTK és a Qt esetében.
    Mutasd a teljes hozzászólást!
  • "Komolyan nem értem, miről beszélsz."

    Talán olvasd el a témanyitó bejegyzést.

    Én írtam már kódot, ami Z80-as C-től a mai napig futkározik, bár sok-sok váltás volt közben.
    ...és alig kellett "igazítani" valamit rajta az idők folyamán.

    Egy cég kódvagyona évtizedek alatt gyűlik össze és egy jó cég ügyel arra, hogy ne kelljen minden 5 évben technologia váltás címen újraírni mindent. És szereti ha a technologia birtokosok (jelen esetben MS) ezt acceptálják

    De hogy visszatérjek a nyitó bejegyzéshez:

    A mellékelt kódrészletet most tettem feltételessé.
    Eredetileg egy nagy és sok soros osztályt képeztek, amelyik WinForm alatt dolgozott régóta.
    Most egy az egyben(!) áttettem a kódot (link-ként hozzáadtam az új projectemhez - merthogy attól még a WinForm-os projectek nem haltak meg, hogy belekezdtem egy WPF-es be, a "köztes" kód meg muzsikálhat tovább, WPF alatt is; ugyanazt csinálja, sőt továbbfejlődget akár WinForm akár a WPF project miatt; de mint kiderült a message kezelés kicsit más.)

    Ami engem zavar, hogy feleslegesen változott meg valami.
    Nekem pedig egy sok éve jól muzsikáló kódomban az összes üzenetküldést át kell írnom (vagy egy wrappert írni, de az is ugyanaz, tételesen módosítani kell - legfeljebb a jövő biztosabb a MS t_ketlenkedései ellen).

    Ha a MS-nál valaki belefutott volna ebbe (vagy ha belefutott és jelezte a főnökének, akkor az meghallgatta volna, vagy a marketingesek valami sz__r dumával nem dobják vissza a dolgot), akkor a CS file változtatás nélkül túlél egy technologia váltást!

    Ha ennek fontosságát nem érted, akkor csak hobby-programozó vagy Bocs. [Leszegett fej, bűnbánó arc és makogás, de télllleg bocs ezt ki kellett mondani]
    Mutasd a teljes hozzászólást!
  • Komolyan nem értem, miről beszélsz. Eddig azt hittem, új kódról beszélünk, arra vonatkozott a kérdésem, hogy azt minek Forms-ban írni.

    A Forms az MS által támogatott, meglévő kódok remekül elfutkároznak a legújabb Windows 8 rendszeren is.

    Nem kell dollár milliárdokat kidobni.

    Új kódot meg már évek óta nem javasolt Forms-ban írni. De ettől még működik.

    Szóval akkor most miről van szó?
    Mutasd a teljes hozzászólást!
  • "Mire kell Forms support?"

    Talán annak a "pár" programfejlesztő cégnek fontos, akik dollár milliárdokat(!) öltek forráskódok létrehozására és hirtelenjében nem akrnak elővenni mégegyszer ennyi milliárdocskát meg évecskét.

    De személy szerint én sem szeretem, ha a befektetett energiáim lesz_*_rják és arra kérnek, hogy mert nekik ez üzlet én veszítsek sok pénzt. Arra már nem fussa.
    Évekbe telt, amíg a MS magához csábított, hogy használjam a technologiáját, akkor meg ne adjon olyan jeleket, mint egy infantilis marketinges, hogy az én hasznom a lényeges, pénztártól távozás után gebedj meg, a pénzed már úgyis nálam van. A jövő meg le van...
    Egy komoly (de kicsi) fejlesztő(cég) nem engedheti meg magának, hogy pár évente mindent újraírjon, mert csak.
    Egy nagy meg ugyancsak nem, bár más okokból

    Ha észrevetted én nem arról beszélek, hogy ne fejlesszenek tovább, hanem arról, hogy ésszel kell ezt megtenni! (odafigyelve a vevőikre)

    Csak egy futó példa: a Phil Katz (aki gondolkodott mielőtt kódolt) olyan fejlécet (verzió infóval) tett a ZIP formátumba, hogy a későbbi verzióval készült tömörített állományokat egy korábbi verzióval megnyitva értelmes üzenetet kaptunk.

    Ha jól emlékszem a WinWord6-os DOC-ot egy WinWord2-vel megnyitva meg lefagyott a rendszer.

    Ez csak egy példa, semmi odafigyeléssel sokat lehet megtakarítani.

    Mutasd a teljes hozzászólást!
  • No de ha találtál volna egy Linux alatti framework-öt, ami forrásszinten biztosította volna a kompatibilitást egy csomó WinApi hívásra (mert ugye a mögötte futó kód, akár még a wrapperrel kezelt libek tartalma is [akár szemléletében is] de jelentősen eltérhet), na akkor közelebb lenné.

    De nem ennyire elvonatkoztatva a jó példa.

    Ha nem komplett felület cseréről van szó, hanem az alapjaiban egységes dologról pl. adatbázis/adatfile elérésről és írsz egy teljesen új környezetet, akkor akár ügyelhetsz is arra, hogy a legtöbb kódod kompatibilis maradjon az új elérési rétegedhez.

    De a fenti példa a legfontosabb.

    Felületet (koncepciót) vált.
    De van egy azonos funkciójú, paraméterezésű, értelmezásű, visszatérési értékű függvénye amit úgy implementál az új rendszerben, hogy a többi sokezer programkódsor (.Net) kompatibilis marad, csak ez a néhány sor válik érvénytelenné, mert új neveket vezet be (különösen a többesszám tetszik, meg hogy mekkora különbség az ikon meg az imédzs jelen esetben).

    Na de ha beleszaladtak, akkor miért is nem vezettek be (a C#5-re legalább) egy régies #define megoldást (vagy annak syntax érzékenységgel kibővített változatát, pl. csak adott típus propertijeire csinálja meg, meg ilyenek).

    Tudom ellenjavalt a define, mert bekavarhat rendesen (volt pár kalandom C alatt ilyesmivel), de hát akkor is: megoldás.

    Csak a régi bölcseletet kell idéznem: "A zseni átlát a káoszon"

    Mutasd a teljes hozzászólást!
  • Mire kell Forms support?

    XP-nek kevesebb, mint 500 napja van, Vista óta a rendszer része a WPF.

    Ha valami Mono-támogatás az ok, akkor azon meg kár keseregni, hogy az MS-nek nem érdeke, hogy Windows-on kívül futtatsd a programod. Ez egy profitorientált cég, nem Róbert bácsi nyílt forráskódú ingyenkonyhája.
    Mutasd a teljes hozzászólást!
  • Egyszer volt, holnem volt, hogy egy jó kis win32 API-t intenzíven használó C-s progit kellett volna átírni linux alá. Előzőleg csináltam egy helyzetfelmérést, hogy kb. mekkora meló - és úgy három hónap után megálltam - ennyit nem ért volna meg az a 2-3 százezer amit az ügyfél fizetett volna a dologért.
    Mutasd a teljes hozzászólást!
  • No ennek mi értelme volt?

    #if WINFORM ok = MessageBox.Show(msg, prog, MessageBoxButtons.YesNo, MessageBoxIcon.Exclamation) == DialogResult.Yes; #else // WPF ok = MessageBox.Show(msg, prog, MessageBoxButton.YesNo, MessageBoxImage.Exclamation) == MessageBoxResult.Yes; #endif

    Minden zseniális húzásuk mellett sokszor kételkedem, hogy a MS-nál "valódi" programozók dolgoznak?

    Használják a "fejlesztéseiket" bármilyen hobby/éles munkára, azon kívül, hogy egymásnak kódokat írnak és kitalálnak könyvtárokat?

    Aki dolgozott kicsit is nagyobb projecten C/C++ alatt, az tudja, hogy a világ legnagyobb találmánya, hogy forrásszinten kompatibilis kódokkal akár az egész az alatti világ kicserélésével, akár komplett paradigma váltásokkal működő (vagyis értékörző, nem kidobandó vagy újraírandó) marad a sok melóval kiszenvedett forrás.
    [Különösen, ha az azóta "elfeledett" preprocesszor technikát is be lehetett vetni ]

    Most ilyen primitív dolgokhoz is írjon mindenki wrappereket?

    Ennyire semmibe nézik a felhasználóik munkáját, hogy nem figyelnek ennyire egyszerű kis apróságokra sem?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd