Új hozzászólás Aktív témák
-
Alexios
veterán
Nem lehet.
.NET Core is futtatható linuxon, és .NET Core 3-tól WPF appokat is lehet írni, de a WPF-nek windowsos függőségei vannak, így WPF(vagy winforms) alkalmazásokat továbbra sem lehet linuxon futtatni.Majd a .NET 6-al idén érkező MAUI talán megoldás lehet erre
[ Szerkesztve ]
-
martonx
veterán
Kevered a dolgokat. A .Net 5.0 nagyon nem egyenlő a régi .Net Framework-kel (ami 4.8-al ért véget).
A .Net 5.0 az a .Net Core-ra épül, viszont több mindent átemeltek a régi .Net Frameworkből, vehetjük úgy, hogy összeolvadtak.
És egyrészt igen, a .Net Core már cross platform. Másrészt a windows-os GUI elemek továbbra sem használhatóak linux-on. azaz a klasszikus winforms és wpf alkalmazások pont ilyenek, amik továbbra is csak windows only-k.
A .Net 6.0 idén év vége felé fog megjelenni, és az már abszolút cross-platform GUI-t is fog tartalmazni MAUI néven fut, jelenleg még csak preview.Addig is mindez áthidalható pl. AvaloniaUI-val(ami cross-platform jelenleg is) : Avalonia UI Framework
Én kérek elnézést!
-
Keem1
addikt
válasz martonx #9552 üzenetére
"A .Net 5.0 az a .Net Core-ra épül, viszont több mindent átemeltek a régi .Net Frameworkből, vehetjük úgy, hogy összeolvadtak."
Tehát vehetjük úgy, hogy a jövőben a .NET és a Core összeolvadva akármilyen néven (felőlem maradhat .NET, Core vagy Jóskapista is) fog folytatódni úgy, hogy az új framework tartalmazza mindkettő korábbi platform motyóit?
Ilyen jó hírt is régen hallottam... ha igaz.Egyébként a Core valaha része lesz a Win10-nek, mint most a .NETFW? Írnék én Core toolokat, ha rajtam kívül senki nem tudja futtatni. Telepíteni bármit csak ezért senki nem fog, akkor keresnek más megoldást. Ilyenek az emberek. Ráadásul a Mono miatt a régi FW-s cuccok még egy kaputelefonon is elfutnak. A Core meg nagyon válogat az eszközök között (ARM procira gondolok).
[ Szerkesztve ]
-
Alexios
veterán
Nem tartalmazza mindkettőt, elsősorban a core-ra épül, de elég sok mindent átvettek a régi fw-ből főleg támogatás céljából(lásd wpf, winform support), de elsősorban core alapú az egész, és az is marad, de ez nem a jövő, hanem már így van. Van amit nem vettek át(WCF, Webforms pl), de a lényeg hogy a jövő a .net 5+, nem lesz már új .net fw verzió
.Net core-nál amúgy lehet self contained is publisholni, azaz akkor is fut ha nincs a usernél a runtime feltelepítve
[ Szerkesztve ]
-
martonx
veterán
Alexios megelőzött. Ez már évek óta így van, mondjuk a .Net Core 1.x még nagyon fapados volt, 2.x-től kezdve én már soha többé nem is használtam a régi .Net Frameworköt.
5.0-tól kezdve meg elhagyták a core-t a nevéből, és már csak .Net 5.0-nak hívják a zavarokat elkerülendő.És a .Net core 2.x óta tudsz olyan appokat írni, amikhez semmit nem kell telepíteni (se előtelepítve lennie a gépen, ellentétben a régi .Net Frameworkkel), egyik OS-en sem, mindent magába foglal. És simán fut Windows-on / linuxon / osx-en. Jó persze, ahogy feljebb írtuk, ezek GUI nélküli appok, azaz console appok / web appok.
Az idén év végén befutó 6.0 viszont már cross-platform GUI-t is fog tudni.Én kérek elnézést!
-
vlevi
nagyúr
válasz martonx #9555 üzenetére
"5.0-tól kezdve meg elhagyták a core-t a nevéből, és már csak .Net 5.0-nak hívják a zavarokat elkerülendő."
Ha így nézzük, akkor pont, hogy zavaró. Aki járatlan a témában, azt hiheti, hogy az a 4.6 továbbfejlesztése...Én egyébként pont a napokban frissítettem otthon a VS2019-et, és abban Asp.Net Core-nek hívják, és külön van a .Net Framework.
De a framework kiválasztásánál már valóban úgy van, ahogy mondot, lehet választani, de az 5-s nek a nevében nincs benne a core. -
martonx
veterán
Ezzel pont csak megerősítetted, amit mondtam. 5.0-tól kezdve már csak egyféle .Net van, nincs Core és Framework Felfoghatod a 4.8 továbbfejlesztésének
Az Asp.Net Core más téma, az egy bizonyos verzióig valóban képes volt mind .Net Core, mind .Net Frameworkkel működni.Én kérek elnézést!
-
Keem1
addikt
válasz Alexios #9554 üzenetére
Nekem már ez is egész jól hangzik. Hónapok óta elfailelt a beépített update (VS 2019 Community), így most az installerrel tettem fel, meg leszedtem a .Net 5.0-t is. Először megszokásból a .Net FW között kerestem, de a Core-nál találtam meg végül
Tesztelgetem. Eddig .Net 4.6 volt szinte mindenre nálam (mostanában meg már inkább 4.8), meglátjuk, benne vannak-e mindazok az 5.0-ban, amire nekem szükségem van. -
Keem1
addikt
-
Alexios
veterán
Ha kézzel kéne letöltögetni, akkor elég macerás lenne dolgozni olyan helyen ahol több mint 1 fejlesztő van
Jó esetben ugye valamilyen source control alatt van a kód, ott nincsenek fent a nuget packagek, csak a csproj-ban a packagereferencek(vagy még régebbi módon a packages.config-ban), ami alapján majd tudja a nuget hogy mit kell letöltsön. -
Keem1
addikt
válasz Alexios #9561 üzenetére
.... és #9562 fatal`
Nagyon baba
Elő is ásom a már retired (de a covid miatt le nem adott) régi céges laptopomat, amin tutira nincs ez a betegség (.Net Core ) és kipróbálom rajta.Ellenben... A régi .Netben volt olyan hogy átjárhatóság a wines és a console-os appok között. Tudtam ablakot nyitni console esetén és ablakos projectnél megjeleníthettem a console felületét is, ez az ilyen, általam írkált toolokat még kényelmesebbé tette. Ezt most nem sikerült megcsinálom. Működhet? Vagy ezt már felejtsem el?
A .Net lehet hogy őskövület, de rugalmas és mindent meg tudtam benne csinálni, ezért nehéz a váltás -
martonx
veterán
1. könyörgök jegyezd már meg a keretrendszerek nevét, vagy örökre ignorálni foglak trollkodásért. .Net 5.0 van most. Előtte pedig két ág létezett:
.Net Framework, ami 4.8-ig jutott el
.Net Core, ami 3.1-ig jutott el.
Olyan, hogy régi .Net nem mond semmit, mert nem értjük, hogy .Net Core-ra, vagy .Net Frameworkre gondolsz. Ahogy a .Net őskövület (oké, de melyik??? , amelyik 2001-ben jelent meg vagy amelyik 2017-ben jelent meg?) kijelentés se árul el semmit, azon kívül, hogy megtudtuk, hogy fingod sincs, hogy miről beszélsz. Hagy ne kelljen minden egyes mondatodat interpretálni, és azon töprengeni, hogy mire gondolhatott a költő.2. nagyon csodálnám, ha ne lehetne ezt a fajta kókányolást (kényelmes tool használatot, ahogy te hívod) megoldani .Net 5.0-val.
Én kérek elnézést!
-
Keem1
addikt
válasz martonx #9564 üzenetére
Hátöö...
1.)
Már lassan én is elvesztem a fonalat... Egyrészt nem értem ezt az ide-oda tilitolit, az egyikben ez benne van, a másikban meg valami más. Tudom, én vagyok megrögzött, régimódi, de én ha valami jól működik, azon nem változtatok (tehát én ezt a frameworkök közti váltást teljesen visszafelé kompatibilis módon oldottam volna meg).Szóval eddig többnyire a .Net Framework 4.6, újabban 4.8-at használtam, mert ami nekem kellett, vagy kényelmesebben lehetett megoldani ebben (lásd a kókányolásnak nevezett console+window egy időben), vagy valami hibára futottam a Core 3.1-gyel, és miután sokadjára se sikerült megoldanom, visszaváltottam 4.8-ra, ahol az előbbi hibakeresés idejének egytizede alatt megoldottam.
2.)
Lehet hogy te kókányolásnak nevezed, én rugalmatlanságnak. Nem értem, mi a probléma egy hibrid programmal, ahol van konzolod és ablakod is. De ha elmagyarázod nekem, hogy mi ebben a kókányolás, akkor elfogadom. Például a goto-t kókányolásnak gondolom én is, hisz a kód átláthatatlan, a program működése meg kiszámíthatatlan lesz tőle.Nálunk amúgy aki még konyít a fejlesztéshez (értsd: cloudos, de tud programozni, viszont nem hivatásos programozó), az Pythonban csinálja ugyanezt. Én a Pythont nem ismerem, biztos jó, de én nem ismerem. Ott abszolút elfogadott ez a hibrid megoldás is. Ha kell, a console kikapcsolható, marad az ablak. De a console is hasznos néha.
[ Szerkesztve ]
-
Livius
őstag
Én a .Net Framework 4.7.2-vel csináltam a projectjeimet eddig, és kicsit utána Googleztam hogy milyen dolgokban másabb mint a régi .NET core és most a sima .NET 5. Azt találtam hogy első közelítésben mindenki azt írja a blogokban meg mindenhol, meg az MS is, hogy van egy .NET Portability Analyzer arra, hogy a régi projectet fel lehessen mérni, mennyire kompatibilis az új .NET 5-vel vagy más régebbi .NET core-okkal.
Én ezt a kis VS2019 kiegészítő felraktam és kipróbáltam. Szerintem elég jó az eredmény. Egyelőre azt látom, hogy minden WPF cucc az már a .NET 5-re zöld pipát kapott, valamint olyan kategóriát is mutat hogy .NET 5 + extension, ebben az esetben az extension jelentheti azt, hogy valami NuGet packageből helyettesíthető a cucc?
Amúgy az én projektem összesen két komponensen bukott egyelőre el a kompatibilitás ellenőrzésen. Az analízisnek nem tetszett, hogy használom a SerialPort Class-t, ez ha jól látom csak .NET 5 extension-ben lesz benne, és még használok egy NI Measurement Studio 2019 libet, amire azt írja az NI hogy .NET Framework 4.5-kell neki minimum. Gyanítom ez az NI lib még nem a .NET 5-re íródott, persze nagy része az csak NI-os WPF GUI elem, meg pár HW-hez lib. Egy .NET 5 extensionos project az képes lehet majd visszafelé használni .NET Framework 4.x dll-eket?
[ Szerkesztve ]
Gigabyte GA-Z170-D3H, Intel Core i7-7700K, Corsair Vengeance 2x8GB DDR4-3600MHz, Intel 545s 256GB SSD, EVGA GeForce GTX 1060 GAMING 6GB
-
Már lassan én is elvesztem a fonalat... Egyrészt nem értem ezt az ide-oda tilitolit, az egyikben ez benne van, a másikban meg valami más. Tudom, én vagyok megrögzött, régimódi, de én ha valami jól működik, azon nem változtatok (tehát én ezt a frameworkök közti váltást teljesen visszafelé kompatibilis módon oldottam volna meg).
Pedig annyira nem bonyolúlt a dolog, és lehet lenne értelme utánanézni, ha már egyébként is foglalkoztat.Semmilyen tili-toli nincsen. Mióta a .Net Core (igen, a NET 5 is ide tartozik) vonal megjelent ezt rohamléptekben fejlesztik, az előző .Net Framework vonalat pedig csak minimális mértékben csiszolgatják.
A Core vonal már eleve multiplatformnak lett tervezve, illetve a fejlesztési modell is más. A távlati cél, hogy ez nem csak szebb jobb, gyorsabb és multi platform lesz, hanem hogy a Net 4.X szinte minden támogatott funkcióját -aminek értelme van- továbbvigyék. Ez utóbbi nagy feladat ezért csak inkrementálisan lehetséges.
-
Alexios
veterán
De a megszokottban nincs is változtatás, ha nagyon akarod használhatod a frameworköt, nyilván annak tudatában, hogy nem fog hozzá már frissítés jönni.
Az egész .NET Core lényege az volt, hogy nem kell visszafelé kompatibilisnek lenni, és nem kell hogy a következő 10 évben megkössék még 15 évről itt maradt dolgok a kezüket.
Sokáig pont azért mondta a MS is amúgy, hogy a Core nem váltja le egyelőre a Frameworköt, mert nem tartalmazott mindent, a .NET 5-nél ez lett a váltás, és ezért a névválasztás is, itt már úgy gondolták, hogy mindent amit a frameworkből tovább akarnak vinni az benne van, innentől ez a .NET jövője.Core nélkül a mai napig nem lenne a .NET cross platform, nem lenne ez az egész, hogy modulokra szét van szedve, valószínűleg nem is fejlődne ilyen gyorsan(ugye innentől évente jön új .NET főverzió), és akkor még amúgy a teljesítmény javulásról még nem is beszéltem.
Mi amúgy viszonylag nagy kódbázissal álltunk át Core-ra (WPF projekt nagyrészt), és a portability analyzer segítségével egyáltalán nem volt olyan vészes. A legkritikusabb része az volt, hogy van pár külső dll amit használnunk kell, és nincs belőlük Core/netstandard verzió, csak fw(ipari kamerák dlljei nagyrészt), viszont portability analyzerrel kijött, hogy nem használ semmi olyat, ami nincs benne a .NET Core-ban, így tökéletesen fut nálunk továbbra is, úgy hogy a fő projekt már nem fw, szóval én nem érzem ilyen macerásnak a váltást.
Cserébe bejöttek új featureök is, pl. teljes C#8-9 támogatás.
#9566 Livius : Az extensiön azt jelenti, hogy az alap core runtime nem tartalmazza, de nugetben van hozzá támogatás(pl.: [link] )
Ahogy láthatod fentebb a példámban, elképzelhető hogy továbbra is megy a .net fw dll core alatt is, de ez nem az extensiönön múlik, hanem hogy a dll miket használ. Ha olyan hívás van benne, ami core alatt nem létezik, akkor nem fog működni, de ha olyanok vannak benne csak amiket a Core is tartalmaz, akkor jó eséllyel menni fog. Dll-ekre is le lehet futtatni a portability analyzert amúgy, és akkor kidobja mi a helyzet velük.[ Szerkesztve ]
-
Livius
őstag
válasz Alexios #9568 üzenetére
A portability analyzer-ben beállítottam azt, hogy a reference dll-eket is megnézze, és a három NI dll-re piros x-et hozott ki az ellenőrzés, de semmi több részlet nem volt hogy mik hiányoznak nekik. Ennél még részletesebben egy dll-t lehet ezzel vizsgáltatni?
Gigabyte GA-Z170-D3H, Intel Core i7-7700K, Corsair Vengeance 2x8GB DDR4-3600MHz, Intel 545s 256GB SSD, EVGA GeForce GTX 1060 GAMING 6GB
-
Keem1
addikt
Srácok, regex helpet szeretnék kérni.
Kaptam PHP oldalról egy csomó kulcs-érték párost (sok ezer db) így (minden új sorban, tehát a vége line feed):
[kulcs] => értékMost van egy ilyenem, amivel az érték megvan, de a kulcs sajna hiányzik:
System.Text.RegularExpressions.Regex expression = new System.Text.RegularExpressions.Regex(@"(\[[a-zA-Z]{1,15}\]\s=>\s(.*)[\r|\n|\r\n])");
var results = expression.Matches(pet);foreach (System.Text.RegularExpressions.Match match in results)
{
Console.WriteLine($"Ertek: {match.Groups[2].Value.Trim()}");
}Hogy kaphatnám meg a szögletes zárójelben lévő kulcsot is?
[ Szerkesztve ]
-
pvt.peter
őstag
Sziasztok,
Ha van ez a kódunk:
if (variable is null) {
variable = expression;
}
Akkor ezt helyettesíthetjük ezzel is:variable ??= expression;
A kérdés innentől adott: ??= operátor thread safe?
[ Szerkesztve ]
Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
válasz pvt.peter #9576 üzenetére
Szinte biztos, hogy nem atomi, mint ahogyan az "i++" sem atomi, hiába fér bele egy sorba. Az if operatoros verzió amit helyettesíteni akarsz pedig garantáltan nem atomi.
Kérdés, hogy miért van szükséged atomi műveletekre? Az atomi műveleteket biztosító C# osztályt egyébként itt találod: Interlocked Class (System.Threading) | Microsoft Docs
Miért nem használasz egy "shared nothing" megközelítést ahol az adott konkurens metódusaid semmilyen közösen használt változót/adatot nem használnak? Vagy miért nem lockolsz valamilyen szemafor konstrukcióval a kritkus kódon (kritkus kód == írás művelet bármilyen közös változón)
SZERK
ezt dobta a kereső:
What are Atomic operations and what are not?
In C# Specification, the stamement about atomic operation is:
“Reads and writes of the following data types shall be atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types.” Also: “…there is no guarantee of atomic read-modify-write, such as in the case of increment or decrement.”.
a ??= operator szerintem a read-modify-write kategóriába esik...[ Szerkesztve ]
-
Keem1
addikt
Srácok, a Linq képes arra, hogy egy List<dictionary<string,string>>-ből megkeressem a list azon elemeit, amiknél egy adott dictionary key-re vagyok kíváncsi?
Tehát van egy nagy listem:
List<dictionary<string,string>> nagy
Amiből kéne egy olyan
List<dictionary<string,string>> kicsi
partial list, ahol a nagyból egy bizonyos kulcsot adok meg szűrési feltételként.Pszeudo:
List<dictionary<string,string>> kicsi = nagy.Where(item => item.Key = "blabla").ToList();
Valami ilyesmi
Szerk: igazából a fontos, hogy a dictionary bármi lehet, akár <string,object> is, de a key az mindenképp string. És a nagy list szerkezetét kellene visszakapjam, csak azokra az elemekre, ahol a key matchel a keresési stringre.
Szerk2: foreach-csel megvan, meg lenne, de nekem most Linq-re lenne szükségem.
[ Szerkesztve ]
-
Nem teljesen értem a feltételt. Arra van szükséged, hogy visszakapd:
A, azon dictionary-k felsorolását, amelyek rendelkeznek egy bizonoys kulccsal, VAGY
B, azon dictionary-k felsorolását, amelyek rendelkeznek egy bizonoys kulccsal amelyhez adott érték tartozik?List<Dictionary<string, string>> nagy
;A, // ahol van "xx" kulcs
nagy.Where(a => a.ContainsKey("xx"));
B, // ahol van xx kulcs és az ehhez tartozó érték "yy"
nagy.Where(a => a.TryGetValue("xx", out string val) && val == "yy");
a végén hívhatsz egy ToList()-et
[ Szerkesztve ]
-
cigam
félisten
Adott egy wpf project, amiben az egész ablakot tükrözni kéne. A Designer-ben csak egy kattintás, de nem tudom hogyan kellene leprogramozni. Az
<ScaleTransform ScaleY="1" ScaleY="1"/>
XAML sorra gondolok. Ezzel meg tudom forgatni a teljes ablak tartalmát vízszintesen, és függőlegesen, de nem találtam forráskód mintákat, vagy amit találtam az nem akart működni. Már a
st = ScaleTransform();
ra is panaszkodik. Tudnátok linkelni egy magyarázó oldalt, vagy egy pár soros kódot a megoldásra?Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
coco2
őstag
Sziasztok!
Összeakadtam egy olyan problémával, hogy csak pislogok rá. VS2015 nem hajlandó települni. Nem találtam a problémának relevánsabb topic-ot, talán modik elnézik nekem.
Legacy fejlesztéshez vs2015 update 3 kell nekem. Microsoft oldalon találtam letöltést valami azure dev programba bejelentkezés után archívumban (másutt már nem volt meg). Ezeket tudtam leszedni:
en_visual_studio_2015_shell_isolated_x86_dvd_9fda4a05.iso
341 megamu_visual_studio_2015_update_3_x86_x64_dvd_8923065.iso
6225 megaAz OS win10 2004-es. Felmountolom az első iso-t, telepítőt elindítom, feltelepül minden, szuper. És pislogok, hogy oké, de hogyan indítom el? Asztalon nincs kint ikon. Start menüben nincsen ikon. Kotrom microsoft oldalt, és azt találom, hogy végső soron ott az exe, csináljak róla kézileg indító ikont. Ez az exe:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
Az az exe nem létezik. Nincsen ott olyan abban a mappában. Néztem a support page-en, elvileg vs2015 támogatva van win10 alatt. Teljesen csak nem kellene kukásnak lennie.
Létezik valahol vs2015 "normális" install csomag (ami indulni is fog)? Vagy a jelenség normális és csak van a vs2015-nek valami heppje, amit tudnom kellene?
A témában bármilyen segítségnek örülnék.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
@cigam, @fatal: A második ugyan méretesebb, de az akkor is csak update. Ha azt indítom el, szól, hogy nem talál telepített vs2015 példányt. Ha előzőleg telepítem, akkor az is lefut hiba nélkül. De indító exe-t az sem ad.
@vlevi: Az az installer már csak 2019-et szed le. Nem legacy verziós vs kellene, nem is lenne problémám. De azt a tippet köszönöm, hogy talán online installert is kipróbálhatok 2015-re. Nézem..
@joysefke: Azt ugye sejted, hogy épelméjű fejlesztő nem jár azoknak - és nem is fognak kapni - akiknek csak arra kell, hogy fingassák? Ha fingásra vágytok, arra ott a babfőzelék, bon appétit
[ Szerkesztve ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
-
dqdb
nagyúr
C# esetében miért ragaszkodsz a 2015-höz? Ha akad VC14-et igénylő interop kód, amit macerás portolni, akkor oké, de amúgy önszívatás a régi .csproj formátumon maradni, sokkal lassabb NuGet csomagfrissítéssel szívni és a .NET Core 2.0 és frissebb támogatás teljes hiányáról ne is beszéljünk.
A VS2015 támogatása már egy éve lejárt, ezért nem tolja az ember képébe a Microsoft oldala, de ettől függetlenül a Community és többi változathoz tartozó ISO elérhető innen.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Alexios
veterán
Ha az eredeti példádban levő kódot akarod c#-ban:
var st = new ScaleTransform
{
ScaleX = 1,
ScaleY = 1
};
//Ha egy negyzetbe szeretned belerakni:
var transformGroup = new TransformGroup();
transformGroup.Children.Add(st);
var rt = new Rectangle();
rt.RenderTransform = transformGroup;
De azért mutatják be XAML-ben szerintem, mert a wpf fejlesztők 90% úgy fogja használni, nem feltétlenül code behindban fognak ui részt írni, neked miért fontos hogy így legyen?
-
coco2
őstag
válasz martonx #9596 üzenetére
6-7 éves vagy sem, a compatibility page-en az van, windows 10 targeted, szerintem elvárhatnám, hogy aktív támogatása legyen. Vagy akkor írnák, how win10 1704-es verzióig támogatott vagy valami, és 19xx-el már ne próbálkozzon senki mint ahogy 2xxx-el sem. Akkor tudnám, mi újság. De semmi olyan verzió információ nincs ott, csak egészben windows 10. Szóval nem szép, amit művelnek.
@dqdb: Igen onnét szedtem a fail 2015-ös installokat. Most nézem hamarosan a menet közben leérkezett "vs2015.3.com_enu.iso"-t (7439K) amit @fatal linkelt.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
dqdb
nagyúr
A compatibility page akkor érvényét vesztette, amikor tavaly lejárt a VS2015 kibővített támogatása is. A VS2017 és VS2019 még az aktív támogatási időszakban vannak, ezeknél lehet elvárásod, azonban ha a VS2015-nél valami eltörik, akkor IJ, ezek a dátumok végig szerepeltek a támogatási roadmapben.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Skoda, VW, Audi, Seat topik
- RAM topik
- Huawei P30 Pro - teletalálat
- Windows 11
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen TV-t vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Luck Dragon: Asszociációs játék. :)
- OLED TV topic
- További aktív témák...