Én ezt úgy szoktam megoldani (ha a load soká végez és nem lehet kiölni, márpedig általában ez van) hogy van egy timerem mondjuk 2 másodperces időzítéssel, defaultból letiltva. Ez indítja a load-ot, a selectedindexchanged pedig csak annyit csinál hogy timer.enabled=false; timer.enabled=true; A timerben pedig az első dolog hogy letiltom őt. Ennek hatására ha a júzer össze-vissza kóvályog a listboxban nem történik semmi, míg ha megállapodik egy helyen akkor elindul a load. Ráadásul a timerrel a szálkezelés vs windows.forms című szívásokat is megspórolhatod.
Bővítem a listát: a Load idejére letiltod a ListBox-ot, hogy a felhasználó ne tudjon összevissza kattintgatni (természetesen valahogy jelzed, hogy éppen történik valami, és a hibakezelésben is feloldod a tiltást).
Több szál esetében figyelni kell a Control.InvokeRequired Property property értékét, mert UI-t hívni másik szálból rosszat eredményez az álmoskönyvek (és a dokumentáció) szerint.
Ha az a Load() másik szálon fut, akkor ölöd meg, amikor csak akarod, és indítasz helyette másikat (persze, nem tudjuk, pontosan mit csinál, nyilván oda kell figyelned, hogy semmi ne dőljön össze, ha csak úgy kirántod alóla a szőnyeget).
Megszakitva a filozofalgatasokat, a "ki hol baszta el :)" cimu resz utan (ertsd: nem letezo hibakodok) felvetnek egy kerdest:
Legyen egy Load() metodusom, amit mondjuk egy ListBox SelectedIndexChanged eventjeben hivok meg. Ennek a Load() -nak a futasideje legyen kb 10 masodperc.
Na most ha a Load()-ban nincs Application.DoEvents(), es en elkezdek vadul kattintgatni a ListBoxban, akkor szepen sorra lefut 25 -szor a Load().
Cel: arra keresek megoldast, hogy hogyan lehetne azt elerni hogy uj kattintaskor az eppen aktualis Load() - ot megszakitsa es az ujat kezdje el betolteni.
Egy masik kerdes, ami most jutott eszembe, igaz meg nem neztem utana: rekurziv hivas eseten lehet a forditonk olyat mondani, hogy ne tegye a stackre a visszateresi cimet?
Nem olyan rossz az, de ha nincs akkor még mindig a legjobb megoldás az ha nem fordítanak. Ha van egy hiba a programban azzal a felhasználó eleve nem tud mihez kezdeni. Az hogy hivatkozás az inicializálatlan objektumpéldányra centire ugyanannyit fog mondani neki hogy object reference not set to instance of object.
Nem véletlenül írtam, csak leszavaztatok, hogy az egésznek pofon egyszerű, kecske-káposzta megoldása lett volna, ha a hibáknak van egy egyedi azonosítója is, valami kód, ami ott szerepel változatlanul bármelyik nyelvű hibaüzenet mellett.
És ez az amiben nem értünk egyet. Normál körülmények közt, ha valami gond van, akkor azt a program jelzi. Pl. ha a user olyan helyre ír nullát amivel osztani kellene, akkor a program kiírja szépen hogy ide ne írj be nullát, és nem divide by zero exceptiont tol a user arcába. Ha nem ez van akkor valami nagyon el van szúrva. És itt az esetek 99.9999%-ában a felhasználó nem igazán tud mit lépni egy üzenetre. A programozó igen, de ehhez tudnia kell(ene) hogy mi a búbánatot is takar az üzenet. És itt az érdekesség, ugyanis mi a .NET keretrendszer dolgainak a nevét ugye angolul ismerjük. Innentől kezdve aztán el lehet játszani hogy mire is gondolhatott az áldott fordító amikor lefordította az adott fogalmat angolról magyarra. Én legalábbis már párszor beleszaladtam ebbe. Ha kínaiakról van szó akkor még azt mondom hogy lehet hogy rendben van a dolog. De én legalábbis a rendszer üzeneteinek fordítását közvetlenül az msdn.microsoft.com magyarra fordítása utánra időzíteném :-)
Mindebben teljesen igazad van, de én végig Midnight Coder hozzászólására reagáltam, hogyaszongya: „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.”
Ebben ő szemmel láthatólag nem azt nehezményezte, hogy a hülye programozó miért engedi a saját, normális hibaüzenetei és hibakezelése helyett a rendszer üzeneteit felbukkanni. Ebben a kérdésben ugyanis teljesen egyetértek veled, én sem tartom kívánatosnak kész programban a rendszerüzeneteket, ámbár alighanem mindketten kénytelen-kelletlen elismerjük, hogy főleg egy program fejlesztésének-tesztelésének kezdeti szakaszában nem mindig lehet elkerülni, bár törekedni mindenképpen kell rá. Jó, persze, olyan módon el lehet kerülni, hogy nem a lekezeletlen rendszerüzenetet hagyom megjeleníteni, hanem azt írom helyette, magyarul akár, hogy "Rettentően sajnáljuk, akkora nagy hiba történt, hogy a program most felrobban, kérjük, írja meg nekünk azt a hibakódot, hogy AE85478534, és majd megpróbálunk valamit kezdeni vele", de ezzel csak elmaszkíroztam a hibát, mert ezen a szinten már nem tudok korrigálni, csak lefagyni én is.
Ő viszont szerintem a fenti mondatban azt nehezményezte, hogy az micsoda ronda dolog, hogy a MS lefordította magyarra ezeket az üzeneteket. Erre mondtam én azt, több menetben is kifejtve, hogy mivel az MS-nek nincs elvi lehetősége biztosan megakadályozni, hogy akár saját, akár harmadik féltől származó rendszerüzenetek adott körülmények között, bár nem jó, de mégis megjelenhessenek a felhasználó előtt, akkor már a kisebbik rossz, ha fordít, mert a felhasználó az elsődleges szempont, aki ha magyar Windowst vett, azért vette, hogy akármi történik, magyarul kommunikáljon vele.
Ha jobban megnézed, a szintén beidézett Exceles mondatára nem is reagáltam, hiszen abban teljesen igaza van: ebben az esetben a lokalizálás a makrók hordozhatóságát szünteti meg, tehát nyelvészeti kérdésektől függetlenül is totális öngól.
"de valahogy nem akarjátok figyelembe venni" Te meg azt nem akarod észrevenni, hogy teljesen másról beszélsz folyamatosan. Nem "lokalizáljunk vagy ne lokalizáljunk" a kérdés, hanem hogy "lássa a felhasználó az oprendszer, framework, library, stb. belső üzeneteit vagy ne". A Delphi VCL "Index out of bounds" üzenete is ilyen, az is a fejlesztőknek szól nem a felhasználóknak, pedig nem az oprendszer része.
Utoljára ismétlem meg: az oprendszer üzenetei nem a végfelhasználónak szólnak. Nem a nyelv a lényeg, hanem a forrás. Őt nem érdekli a GetLastError, a .NET kivételei és más programok, libraryk, rendszerek belső működése.
A felhasználóhoz az a program kell szóljon amelyiket éppen használ, és olyan nyelven amit a felhasználó ért. A megértéshez nem csak az szükséges, hogy a szavakat értse, hanem az is, hogy a mondandót megértse és tudjon velük kezdeni valamit. Ez lehet akár annyi is, hogy valami hiba történt, vedd fel a kapcsolatot valakivel valami módon és küldd el neki a hiba részleteit valamilyen módon (lehet akár faxon is adott esetben).
Ha egy fájl nem található, akkor azt is közölni kell, hogy mihez szükséges a fájl, hogyan lehet megkeresni vagy pótolni, és azt, hogy mivel jár a hiánya (nem mindegy, hogy a teljes program működésképtelen lesz emiatt vagy csak a naplózás nem fog működni). Ezeket az információkat nem ismerheti egy általános rendszer (legyen az oprendszer vagy egy library), ezért szükséges az alacsonyszintű rendszerek alacsonyszintű hibáit a felsőbbszintű rendszerekben érthetően tálalni a felhasználónak, és akkor már az sem kérdés hogy érti-e.
Kommunikáció: a felhasználó el tudja dönteni, hogy megbízik-e egy szoftverben avagy nem. A hibajelentés lehet csak szöveg, arról könnyű eldönteni hogy tartalmaz-e olyant amit nem akarok megosztani X céggel.
Igen, ez az egész több munkával, több idővel jár, többet kell gondolkozni és tervezni, de ez a helyes út. És mint írod, az esetek többségében ez nem így működik, mint sok más egyéb esetében sem (pl. a tesztelés is szükséges és jó, mégis az elsők között van a "majd később megcsináljuk" listán), de attól még ez marad a követendő megoldás.
Teljesen lényegtelennek tartom a kérdést, hogy tud-e vele valamit kezdeni vagy sem. Az a lényeg, hogy ha nem is érti, ne azért ne értse, mert nem azon a nyelven szól hozzá, amit megszokott a számítógép használata közben. Így ugyanis azt sem tudhatja, hogy értené-e egyáltalán vagy sem, és ez sokkal rosszabb.
Valamint, mint ezt mondtam, de valahogy nem akarjátok figyelembe venni, magyarul ugyan valóban nem megy, de vannak olyan nyelvek és akkora piacok, ahol simán meg lehet lenni a fejlesztés és a felhasználás közben az angol ismerete nélkül. Erre is gondolni kell – nem nekünk, de a .NET készítőinek, lokalizálóinak azért igen.
A hibajelentés teljesen függ attól, milyen programomról van szó. Vannak olyanok, amelyek semmilyen netes tevékenységet nem végeznek, ezeknél (a felhasználó szemszögéből nézve is) elfogadhatatlannak tartanám, hogy bármiféle kommunikációt kezdeményezzen kifele. Pláne nem olyan adatokkal (és valami dump, stack trace vagy hasonló más nyilván olyan lenne), amelyről a felhasználó nem tudja megállapítani, hogy mi is az, nem véletlenül a banki jelszavai-e titkosítva... :-) Én sem engedek ki semmit a tűzfalon, ami nem kifejezetten netes program, mástól sem várnám el a sajátom esetében.
Az olyan kliensszoftver viszont, amelyik állandó netes kommunikációban van a szerverével, megint más kérdés. Ilyennél természetesen van olyan, hogy bizonyos hibákat a szerveren naplózunk, persze. Ha ennek ellenére befut egy rendszerszintű kivétel (nem gyakori, de nem mondom, hogy nem fordult még elő, főleg, hogy külső fájlokkal is dolgozunk, és ha azokban valami korrupció van, nem mindenre lehet előre felkészülni), akkor igen, nekiállunk kitalálni, mi lehetett az oka, beszélünk a felhasználóval, igyekszünk reprodukálni, elkérni vagy más módon ellenőrizni a fájljait, és így tovább. Ebben a folyamatban egy elküldött szimpla hibaüzenet édeskevés (egyébként előfordult, persze, hogy képernyőképként elküldték).
Amúgy természetesen egyetértünk, hogy a rendes hibakezelést el kell várni a programozótól (ámbár attól, hogy egyetértünk ebben, attól még a sok-sok program odakinn a világban nem feltétlenül lesz jobb hirtelen). Ennek ellenére, mivel ezt az operációs rendszernek (és a .NET futtatási környezete, ezt továbbra is határozottan állítom, ma már messze az oprendszer része ilyen értelemben) ezt nem áll módjában kikényszerítenie, az egyetlen, amit tehet, az éppen az, hogy minden egyébbel együtt ezt is lokalizálja, mert megjósolhatatlan, hogy mikor melyik üzenet milyen környezetben bukkan-bukkanhat fel, és az milyen befolyással lesz a felhasználóra. Arról egyébként már nem is beszélve, hogy aki már látott ilyen programlokalizációt közelről, az tudja, hogy a fordítást végző ember tipikusan teljesen kontextustól függetlenül, ömlesztve kapja a lokalizálandó szövegeket, fogalma sincs, melyiket lehetne, ha lehetne egyáltalán, rendszerszintű vagy felhasználói szintű üzenetnek tekinteni (bár, általában, nem is ért hozzá ennyire).
Úgyhogy, szerintem, nem kell ezt ennyire túlragozni. Jó, akkor időnként ki kell találni, mi is lehetett az eredeti üzenet, hogy rákereshessünk a kuglival. Ki szoktuk találni, ti is, én is, azért nem akkora nagy tudomány ez...
Magyarázd már el, hogy egy átlagos felhasználó (nem fejlesztő vagy más IT szakmabeli) mit kezd egy oprendszerből jövő üzenettel, legyen az bármilyen nyelven (több példára kérdeztünk rá konkrétan)? Neki teljesen mindegy, hogy egy szám vagy egy kínai szöveg jelenik meg, egyiket sem érti és egyikkel sem tud és kíván foglalkozni azon kívül, hogy amennyiben újraindítás után is létezik a hiba akkor keres valakit aki foglalkozik vele. Teljesen mindegy, hogy az oprendszer milyen részekből épül fel, hiszen nem csak a .NET Framework, hanem sok más library is része.
Az oprendszer és senki más levelező- és egyéb programja pedig ugyanúgy nem szabadna a felhasználó orra alá dörgölje az alacsonyszintű hibaüzeneteket, hanem értelmes, a konkrét programon belül érvényes üzenetet kellene mutasson helyette (pl. FileNotFoundException helyett "XY beállításokban ellenőrizd, hogy a választott fájl létezik-e."), hiszen az oprendszernek fogalma sincs, hogy a keresett fájl mire való, hol lehet kiválasztani (csak az exception alapján a felhasználó sem tudná ezeket), és még az sem biztos hogy nem létezése hiba, mert lehet van egy default helyette és a program hiba nélkül működik tovább, max. egy Warning kerül be a logba és a felhasználó semmiről sem értesül.
Konkrét eset: apósomnak hiába írta ki a Skype, hogy valamilyen fájl hibás, mert nem tudta mit csináljon. Igazából én sem tudtam, mert a hibaüzenet hiányos volt, ezért újra kellett installáljam. Lehet elég lett volna törölni a fájlt, de a fejlesztő ezt kifelejtette a hibaüzenetből, nekem pedig nem volt kedvem a netet böngészni emiatt.
A hibajelentések küldése webes vagy emailes felületen létező és működő dolog (nem csak Windowsban, és talán kevésbé jellemző a dobozos szoftverekre). Kár, hogy te pont fejlesztőként tartod fölöslegesnek és vonod ki magad alóla. A hibajelentés pedig annyira használható amennyire a fejlesztő felkészítette rá a rendszert. Nem kell debug build ahhoz, hogy értelmes hibajelentést lehessen küldeni (naplózni, stb), melynek alapján ha nem is egyből, de kevés munkával reprodukálható a hiba, és ha reprodukálható akkor már debug módban könnyebben beazonosítható.
Kösz, én nem kérnék belőle, ezt szerintem te sem gondoltad végig. Milyen címre küldjön, mit, mi van, ha a cím változik, és egy nagy, elterjedt programnál, főleg, ahol a felhasználó képeket, szövegeket, dokumentumokat, külső adatfájlokat dolgoz fel, ráadásul természetszerűleg nem kap olyan debug és egyéb információkat a programmal együtt, amiből a programozó számára értelmes következtetést le lehet vonni, mit kezdenék vele? És hogyan tudnám meg, pontosan milyen fájlok, milyen műveletek, milyen lépések vezettek a hibához, és miképpen tudnám reprodukálni? A Windowsban is van ilyen gyári hibajelentés, az ember első dolga, hogy kikapcsolja, úgyis tudnivaló, hogy nem ér semmit, legfeljebb statisztika lesz belőle, ha egyáltalán.
Ami a keretrendszert illeti, csak arra próbáltam felhívni a figyelmet, hogy ma már nem különálló fejlesztői rendszer, hanem az oprendszer része. A hibaüzenetei nemcsak a te programodban bukkanhatnak fel, ha valami baj történik, hanem az oprendszer saját programjai is ugyanúgy lefagyhatnak, tegyük fel, csak hasra ütve, hogy az oprendszerhez mellékelt levelezőprogramot is abban írják, mert ma már miért ne. Akkor, ha az eléggé el nem ítélhető módon futásidejű hibát jelez egy magyar Windowson, tegye angolul?
Továbbra is azt mondom, mi, fejlesztők vagyunk a kisebbség, a felhasználók a többség, és a mi dolgunk az ők kiszolgálása, nem fordítva. Az üzeneteknek az ő nyelvükön kell szólnia, és nekünk kell időnként a fejünket vakarni, hogy akkor most mi is van. Nem kell bemutatnod a helyzetet, én is ezt csinálom nap mint nap. Akkor is, ennek ellenére is ezt gondolom.
Még egyébkéntebb, valóban, a magyar hibaüzenetekben a Gugli nem sokat segít, ez igaz. De a kínait próbáltad már? Én sem, de könnyen el tudom képzelni, hogy egy kínai, angolul gyengén tudó fejlesztő (mert van akkora piac, hogy megengedhetik maguknak), angolul még gyengébben tudó felhasználóknak írva programot simán elboldogul az angol nélkül, csak a kínaival. Még akár a spanyol is, tudja a fene...
Kösz, én nem kérnék belőle, ezt szerintem te sem gondoltad végig. Milyen címre küldjön, mit, mi van, ha a cím változik, és egy nagy, elterjedt programnál, főleg, ahol a felhasználó képeket, szövegeket, dokumentumokat, külső adatfájlokat dolgoz fel, ráadásul természetszerűleg nem kap olyan debug és egyéb információkat a programmal együtt, amiből a programozó számára értelmes következtetést le lehet vonni, mit kezdenék vele? És hogyan tudnám meg, pontosan milyen fájlok, milyen műveletek, milyen lépések vezettek a hibához, és miképpen tudnám reprodukálni? A Windowsban is van ilyen gyári hibajelentés, az ember első dolga, hogy kikapcsolja, úgyis tudnivaló, hogy nem ér semmit, legfeljebb statisztika lesz belőle, ha egyáltalán.
Ami a keretrendszert illeti, csak arra próbáltam felhívni a figyelmet, hogy ma már nem különálló fejlesztői rendszer, hanem az oprendszer része. A hibaüzenetei nemcsak a te programodban bukkanhatnak fel, ha valami baj történik, hanem az oprendszer saját programjai is ugyanúgy lefagyhatnak, tegyük fel, csak hasra ütve, hogy az oprendszerhez mellékelt levelezőprogramot is abban írják, mert ma már miért ne. Akkor, ha az eléggé el nem ítélhető módon futásidejű hibát jelez egy magyar Windowson, tegye angolul?
Továbbra is azt mondom, mi, fejlesztők vagyunk a kisebbség, a felhasználók a többség, és a mi dolgunk az ők kiszolgálása, nem fordítva. Az üzeneteknek az ő nyelvükön kell szólnia, és nekünk kell időnként a fejünket vakarni, hogy akkor most mi is van. Nem kell bemutatnod a helyzetet, én is ezt csinálom nap mint nap. Akkor is, ennek ellenére is ezt gondolom.
Még egyébkéntebb, valóban, a magyar hibaüzenetekben a Gugli nem sokat segít, ez igaz. De a kínait próbáltad már? Én sem, de könnyen el tudom képzelni, hogy egy kínai, angolul gyengén tudó fejlesztő (mert van akkora piac, hogy megengedhetik maguknak), angolul még gyengébben tudó felhasználóknak írva programot simán elboldogul az angol nélkül, csak a kínaival. Még akár a spanyol is, tudja a fene...
Azért ezt az e-mailes megoldást nem gondoltad végig te sem, ugye? :-)) Milyen címre, kinek, mennyit, mi történik, ha a cím rég nem él, mekkora felesleges és felhasználhatatlan adatforgalomhoz vezethetne ez, különös tekintettel arra, hogy nem nagyon adsz ki (legalábbis pénzes programnál) olyan debug információkkal ellátott, dotfuscatorral nem kezelt .NET programot, amelyből éppen emiatt bármi érdemleges, hibakeresést megkönnyítő információ visszajöhetne.
Egy-egy keretrendszer hibaüzenet kapcsán nem a szomszéd Pistike fog tudni segíteni hanem a gugli. Az viszont sokkal jobban tudja angolul. Néhányszor már volt alkalmam kipróbálni a dolgot...
Attól függ. Vannak a felhasználói programnak (beleértve az oprendszer user interfészét is) a felhasználónak szóló üzenetei, és vannak a futtató rendszernek a programozó számára szóló üzenetei. Egy run-time error tipikusan nem az a dolog amivel a felhasználó bármit is kezdeni tudna. Mondjuk én ezt a windows tervezői helyében úgy oldottam volna meg, hogy ha feljön egy ilyen ablak akkor kiírja hogy rendszerhiba történt, és naplózza-e illetve elküldje-e az üzenetet e-mailben a fejlesztőnek. Azzal ugyanis hogy objektumhivatkozás történt ismeretlen példányra a mezei júzer szart se tud kezdeni - és ez a .NET legegyszerűbb üzenete, ez még tudni lehet hogy mit jelentett volna angolul. De néha vannak olyan üzenetek amik macerásabbak.
És a szomszéd vagy haver biztosan jobban fogja érteni angolul, mint magyarul? Nem becsülöd te túl a szomszédokat és a haverokat? Nem magunkból kell kiindulni... :-)
De a vita eléggé akadémikus, mivel a számítástechnika valamikor utoljára húsz évvel ezelőtt tartott ennél a szemléletnél, azóta a mai széles körű, sőt, mindent maga alá temető elterjedtségéhez és társadalmiasodásához nagyon nagy mértékben hozzájárult, mi több, lehetővé tette az, hogy lefordították a felhasználók nyelvére. Én nem tudok ebben semmi kivetnivalót fellelni.
Amúgy eléggé el is kanyarodtunk a kezdeti kérdéstől, amely ugyebár az volt, hogy saját, szakmai környezetében, nem odakinn a placcon hogyan hivatkozzon az ember magyar beszédben angol kifejezésekre (ámbár, mint megállapítottuk, a legelsőként feltett kérdés, a C# nem is angol, hanem szimbólum).
A pontos határt én sem tudom meghatározni. Egy elég hétköznapi példa: "XY szolgáltatás nem sikerült elindítani mert blablabla." vagy a "Hálózati meghajtó nem csatlakoztatható" (a magyar változatok biztos pontatlanok, nem ismerem a helyes változatot). Egy átlag felhasználónak fogalma sincs mi a szolgáltatás vagy a hálózati meghajtó (sokuknak a meghajtó és a memória létezéséről sincs tudomása), legtöbbjük még a Vezérlőpultról sem hallott, nemhogy azon belül megtalálná a szolgáltatásokat vagy az Event Log-ot (magyar nevét nem tudom). Még az sem biztos, hogy van jogosultsága ezekhez a funkciókhoz. Egyébként sem tudja értelmezni a blabla részt, egyből hívja a rendszergazdát vagy a havert aki felvarázsolta a Windowst a gépére. Van elég idősebb és gyakorló háziasszony rokonom, tudom miről beszélek.
Olyan programok, amelyeknél ez számít, természetesen legyenek kétféle (többféle) nyelvre fordítva, és nézze meg öntevékenyen, hogy milyen nyelvi környezetben fut. Régebben is meg lehetett oldani, a .NET meg a korábbiaknál is egyszerűbbé teszi ezt. Mellesleg, ha valaki magyar környezetben angol oprendszert használ, az az ő saját döntése, és nyilván el fogja fogadni az ebből fakadó, furcsán ható nyelvi kettősséget. Én is azt használom, én is elfogadom. De akinek átlagos, hús-vér, nem szakmai hazai felhasználók számára kell programot írnia, az szerintem jobban teszi, ha a mindenestül magyar környezetet tételezi fel, hiszen egészen triviálisan ez az általánosan jellemző.
Az Explorer, a Task Manager, van a Control Panel dolgai, az Administrative Tools eszközei – csak példaként – mind természetesen része az oprendszernek, a te kategorizálásod túl szigorú; ha jól értem, nagyjából a kernelt és a szolgáltatásokat tartod oprendszernek, szerintem az ennél sokkal több (bár ez egy ismételten visszatérő vita, és nincsenek éles határvonalak, természetesen). Mindenesetre a kernelen kívül valóban egyre több minden már .NET a Windows előrehaladtával (már a szolgáltatások között is), és ez a rászarány nyilvánvalóan nem csökkenni, hanem folyamatosan nőni fog ezután is.
De most komolyan, egy kifejezetten személyi számítógépek személyi használatára szánt operációs rendszer üzenetei – bármelyik üzenete! – ugyan mégis kinek szólnának, ha nem a felhasználónak?
OFF Laptop téren nem tudom mi a helyzet, de "angol billentyűzet" keresésre 48 találat van a depo.hu-n, és ezek nagy része valóban billentyűzet.
Arról nem is beszélve, hogy egy igazi fejlesztő egyformán jól ír angolul magyar billentyűzeten és magyarul angol billentyűzeten (természetesen ékezehthelyesen) :-ppp
"lassan a fél operációs rendszert abban írják, így hát még logikusabb, hogy az üzenetei is lokalizálva legyenek." Még mindig fenntartom, hogy az operációs rendszer (mindenféle framework) üzenetei nem a végfelhasználónak szólnak (nem tévesztendő össze az oprendszer a ráépülő programokkal, pl. Windows Explorer, Task Manager). Továbbá ezzel egy másik érvet hoztál fel amellett, hogy a program ne mutassa a framework (oprendszer) üzeneteit: képzelj el egy magyar programot egy angol Windows-on, az üzenetek egy része angol, másik része magyar lenne.
A gyári dialógust soha nem engedem megjelenni, természetesen. Minden programomban magamra irányítom az UnhandledException és a ThreadException kivételeket, és a debug-változatban az e.ToString()-et, a véglegesben az e.Message-et íratom ki egy szokásos üzenetben, hogy ugyanúgy nézzen ki, mint a program bármilyen másik üzenete. Nem nagyon örül neki az ember, ha jön egy ilyen, de azért kétségtelenül előfordulhat, akárhogy is vigyázol. És ha már véletlenül előfordul, sokkal jobbnak tartom, ha egy mindenben magyarul beszélő programot használó magyar felhasználónak magyar üzenet érkezik ilyenkor. Igen, nekem lehet, hogy macerásabb (bár elég kevés ilyen üzenet szokott felbukkanni, nincs memória, nullhivatkozás, nem túl sok és változatos, hiszen a nyilvánvaló dolgokat az ember természetesen lekezeli tudatosan), de én vagyok a felhasználómért, nem fordítva, ennyi belefér, bele kell férjen.
Ráadásul azt se felejtsük el, hogy a .NET ma már nem csupán a külső fejlesztők dolga, lassan a fél operációs rendszert abban írják, így hát még logikusabb, hogy az üzenetei is lokalizálva legyenek. Én ebben nem látok semmi gondot. Abban már sokkal inkább, hogy a Microsoft nagyon sok buta fordítást kényszerített ránk, és sokan mások is ragaszkodnak hozzá, mert szent isten, mi lesz, ha nem pont ugyanúgy mondják, hiszen a felhasználók már azt szokták meg. Én például ebbe nem szoktam belemenni, például telepítőprogramhoz is a saját fordításomat használom, és ahol jónak láttam, kiigazítottam a Microsoft-féle magyart. Még nem panaszkodott egy felhasználó sem soha, hogy nem értette meg... :-)
Van egy alkalmazásod. Abban kezeled a hibákat (már csak azért is, mert az unhandled exception ciki). Hibakezeléskor pedig azt közölsz a felhasználóddal amit szeretnél. Ha neked a "26-os hiba volt, hívd a szupportot vazze." tetszik akkor ezt, és majd a szupport jól megnézi a nagykönyvben hogy a 26-os hiba téves jelszó és jól letolja a felhasználót mert úgy felejtette a caps lock-ot. A framework hibái a fejlesztőknek szólnak, náluk pedig alapkövetelmény azok megértése.
Igen, ez is elég nagy hülyeség a magyar nyelvben. Már rég .-ra kellett volna cserélni. Ahogy egyébként azt is utálom hogy idehaza művészet angol kiosztású billentyűzetet, laptopot beszerezni.
Nem arra gondoltam a hibakóddal, hanem hogy ha az Exception.Message része lenne magától, mondjuk, a végén egy szögletes zárójelben, akkor elég lenne a kuncsaftnak annyit mondani, hogy azt a kódot szíveskedjen megadni, a többi senkit sem érdekel, legyen kínaiul vagy zulu nyelven...
