A hibakód már sok helyen megbukott, konkrétan a Windows API-ban is. Ráadául a felhasználónak az sem mondana semmit. Meg általában teljesen mindegy, hogy hibakód vagy exception, mindkettőt kezelni kell a programban (ebbe beletartozik a felhasználó értesítése is érthető módon - és igen, ez munkával jár).
Egyébként van hibakód, csak nem numerikus, hanem az exception típusa az. A típusok egyediek tehát nem kell központilag menedzselni a kiosztást. Ha mindenki betartja a szabályokat (pl. normális saját namespace) akkor nem lesz ütközés.
Persze, ezt mind meg lehetett volna előzni, ha kitalálnak a szöveg mellé egy hibakódot, ami marad ugyanaz minden nyelven. Csak, persze, arra figyelni kell, hogy ki micsodát osztott már ki, és ilyenek.
99,9% tizedesvessző, csak hogy kötözködjek tovább... :-)
Van egy-két olyan üzenet ami valóban informatív a júzer számára, de a 99.9%-áról lefordítva sem tudja hogy mit jelent. És ami rosszabb: lefordítva én sem tudom, mivel a keretrendszer egyes elemeit a fordítón kívül a világon senki nem emlegeti magyar nyelven.
Mivel a .NET keretrendszere elsősorban nem fejlesztői, hanem futtatókörnyezet, attól tartok, ez így biztosan nem igaz. Számos olyan üzenet van, amelyet nincs értelme szűrni (nincs elég memória, nincs meg a fájl, nem jó a webcím, satöbbi; ráadásul gondolj arra, ha valaki soknyelvű programot ír, akkor az ilyen üzenetek tulajdonképpen teljesen felesleges újrafordításával időt, energiát, programméretet is elpazarol).
Egyébként abban sem látok semmi kivetnivalót, ha a fejlesztőrendszer üzenetei le vannak fordítva (gondolj csak például a hatalmas kínai piacra, sok programozó sok felhasználónak fejleszthet úgy, hogy nincs alapvetően szükségük az angolra). Én is jobban szeretem angolul, tehát angol operációs rendszeren, nem magyarított eszközökkel dolgozom, de ez saját döntésem, elfogadom, hogy másnak más lehet a komfortosabb.
"A .NET hibaüzenetei félig szólnak a felhasználónak is" A .NET Framework (és általában a fejlesztői környezetek) üzenetei nem igazán (kivétel természetesen lehet). A programoknak naplózni kellene az eredeti hibát és valami értelmeset kellene megjeleníteni a felhasználónak (pl. hívd az ügyfélszolgálatot/rendszergazdát, ellenőrizd, hogy a fájl írható/olvasható/van hozzáférési jogosultságod, stb, attól függően kik a felhasználók).
Nem, ha valami angol betűszó, akkor attól még nem kell angolul ejteni. Nyilván más egy konkrét szó, nem lenne különösebben szerencsés Nevjorknak hívni a várost, ámbár az is igaz, hogy magyar beszédben nem a pontos amerikai kiejtést szokás használni, hanem egy briten alapuló, és hangzóiban is elmagyarosodott ejtést.
Arról már nem is beszélve, hogy a C# vagy a C++ nem is angolul van. Szimbolikus jellegű elnevezések ezek, hasonlóképpen a matematikai szimbólumokhoz. A Pascalt, Adát és társait már nem is említve, mert azok szintúgy nem angolul vannak.
Minden nyelv természetes törekvése, hogy mind szakmai, mind egyéb beszédelemeit magához igazítsa. Van olyan is, amelyet teljesen befogad (bájt, fájl), van, ami helyett saját megfelelőt talál. Nyilvánvalóan akkor jársz el értelmesen és helyesen, ha elfogadod a nyelvnek ezt a módszerét (mellesleg, ha nem fogadod el, akkor sincs nagy baj, legfeljebb magadra maradsz, mert a nyelv és a nyelvhasználók nagy tömege akkor is erősebb lesz nálad), és nem írsz 'file-t' és 'byte-os' csúnyaságokat, mert egyrészt kikacagnak, másrészt csak azt mutatod meg vele, hogy nem ismered a magyar helyesírást.
A .NET hibaüzenetei félig szólnak a felhasználónak is, én magyar felhasználók számára (is) szoktam felhasználói programokat fejleszteni, és ott előny, hogy a szerencsétlen érti, hogy a program mit akar vele közölni. Nem mindegyik üzenettel tud mit kezdeni, az biztos, de van, amelyikkel igen.
Persze, az is igaz, hogy én nemcsak programok üzenetében szoktam angollal találkozni, sokat fordítottam (szakcikkeket is, sőt, zömében azt), tolmácsoltam, írtam terjedelmesebb szövegeket mindkét irányban; talán kicsit más perspektívából nézem a dolgot.
Ha valami angol akkor azt angolul kell ejteni. Majd ha a magyarok kifejlesztenek magyarországon egy programnyelvet és magyarul nevezik el, akkor teljesen jogos lesz a magyar kiejtés igénye. Amúgy is hülyeség szakmai dolgokat magyarítani. A legszebb ebben a .NET hibaüzeneteinek magyarítása: annak akinek szól tökéletesen megérti angolul is, ugyanakkor az külön sport hogy az ember visszafordítsa angolra, mert a google magyarul nemigen fog választ dobni az adott problémára. A másik "kedvencem" az excel makrók honosított függvénynevei. Szóval, én számtech vonalon nagyon nem erőltetném a magyarkodást.
Az nem tudom, micsoda, de magyar beszédben az angolul ejtett rövidítések (éjcsbíó, ájendzsi, satöbbi) röhejesek. Időnként valamelyik felhív telefonon, hogy ajánlgassa magát, akkor először kijavítom az illetőt, utána közlöm, hogy kösz, nincs rá szükségem...
A cisz vicc volt, ha véletlenül nem tűnt fel mögötte az egyezményes jel...
Ha felveszel egy adatbázisfájlt a projektedbe akkor a fejlesztőeszköz minden fordítás után csinál belőle egy másolatod a bin-be, és azt használja. Megoldás: a adatbázisfájl valahol másütt, és az app.configban simán bedrótozni hogy ott keresse. Az mdf esetén azért nincs ilyen gondod (már ha nem fájlként kezeled mert akkor van) mert ekkor szintén a fix helyen, az adatbázisszerveren keresi a gép és nem a bin könyvtáradban.
Viszonylag új vagyok a C#-ban, és most találkoztam valamivel, ami kicsit szokatlan a számomra:
Ha a projectemhez adok egy compact database-t (vagy service based database-t), és abban létrehozok egy táblát, ami Form-ról töltenék fel adatokkal, akkor ha visszanézem a database explorerben (View table data), akkor ott nem jelennek meg a formról hozzáadott rekordok.
Következő indításkor ugyan az az üres tábla fogad, mint előtte volt. De ha formról töltök be rekordot, viszont nem nyitom meg a view table data menüpontra kattintva a tábla tartalmát megjelenítő ablakot, akkor ha a programot újra futtatom, akkor látszanak a sorok.
Tehát miért van az, hogy ha megnyitom a database explorerben a feljebb emlegetett menüpontot, akkor elvesznek az adataim?
(MDF -nél nincs ilyen gond, ott simán megy minden, csak az meg az expressben nem hozható létre, csak kapcsolható.)
Eredeti neve C sharp, tehát így, /si: ʃɑ:p/, de magyar szövegben ez kicsit affektálóan bután hangzik, akárcsak a cépluszplusz helyett lenne a szíplászplász. Cékereszt, mondjuk, az teljesen rendjén van és természetes magyar szövegben is.
Én azért döntöttem egy hasonló szituációban az SQLite mellett, mert hiába kerestem végig az egész netet, sehol nem találtam valami .mdf fájlokat szerkesztő kis alkalmazást (Accesszel lehetne, persze, de nincs MS Office-om, nem is lesz). Ami pedig a VS-ben van ilyen célokra, attól meg a hideg kirázott. SQLite-hoz viszont van nagyon helyre kis nézegető-szerkesztgető, amivel fejlesztés-tesztelés közben nagyszerűen lehet kézzel is kezelni az adatbázist.
Ja, és még valami, ha jól emlékszem, a beépített nem tud adatbázist létrehozni, külön le kell gyártanod egy üreset, és vinned magaddal a programod telepítésekor. SQLite meg simán, programból csinál adatbázist, ha kéred, csak egy szimpla CREATE TABLE. Ezt sokkal civilizáltabbnak tartottam.
És mindemellett érezhetően gyorsabb, valamint Monón is van, ha ez szempont adott esetben.
"Ez az adatkotes annyi (...)" Ezt szokták nagyon hamar lecserélni. A gond az vele, hogy nehéz beavatkozni a folyamatba és rávenni, hogy ne azt csinálja amit a gyártó elképzelt, hanem amit a fejlesztő szeretne.
Egyébként DataSource, DataMember property, BindingSource és tsai. osztály fejlesztőeszköztől függetlenül van, tehát legrosszabb esetben is annyi lenne az eltérés, hogy 2-3 sorral több kódot kell írni.
A 2005-re nem emlékszem, de 2008-ban biztosan lehet egérrel is programozni a bindingot (azaz ott vannak az osztályok a Toolbox-ban).
"dotfuscator es tudtommal csak abban van, kulon nem lehet letolteni." A teljes, fizetős verziót le lehet tölteni.
"es meg csak nem is ugyanazt olvasa vissza, mint amit beirtam" Mert teljesen mást olvasol mint amit írsz. Ha karaktert írsz akkor azt is olvass, lásd a 466-ban ajánlott ReadChar, ReadChars metódusokat. Ha byte-ot olvasol akkor miért csodálkozol, hogy byte-ot kapsz eredményül karakter helyett?
Te nem olvasol vagy az embedded-et nem érted? "embedded is van, ha az install miatt aggódsz, Compact a neve"
És mint ugyanott írtam, sok megoldás van. Az Express-t azért hoztam fel példának, mert integrálva van a a fejlesztőeszközzel, még egy dll sem kell hozzá, gyárilag tudja. Jobb klikk, Add new item -> Local Database.
"Elkepzelheto, hogy az okozott gondot nalam, hogy az egyik gepen ha megnyomom az ő gombot, akkor 337-es kodut, a masik pedig 245 -os kodu karaktert ertelmez. (Nem tudom, hogy ez elofordulhat e, nincs itt nalam mindket gep, hgy egyszerre tudnam tesztelni mindketton.) " Ez lemaradt az előzőből. Ott tartottunk, hogy a bötű csak egy logikai fogalom, mint minden más a számítógépben a betű is csak egy szám. A kódolás mondja meg, hogy a szám milyen betűnek (pontosabban karakternek, mert lehetnek krikszkrakszok is egy karakterkészletben) felel meg, és természetesen ez fordítva is igaz. NevemTeve pont az ő betűt hozta fel példának a 465-ben. Teljes ISO 8859-2.
Természetesen előfordulhat, hiszen a Windows karakterkódolása állítható, mert nem csak magyarok, hanem más nyelvűek is használják. Nincs benne semmi varázslás, csak arra kell figyelni, hogy íráskor és olvasáskor is ugyanazt a kódolást használd.
Egy számítógéppel is tudod tesztelni, vagy virtuális gépet használsz, vagy módosítod a beállításokat a Regional and Language Options-ben (a te Windowsodon is van ilyen).
