- Vivo X200 Pro - a kétszázát!
- One mobilszolgáltatások
- iGO Primo
- Folyamatos vérnyomásmérést kínál a Huawei Watch D2
- Samsung Galaxy Watch7 - kötelező kör
- VoLTE/VoWiFi
- Samsung Galaxy S21 FE 5G - utóirat
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Honor Magic6 Pro - kör közepén számok
- Milyen GPS-t vegyek?
Új hozzászólás Aktív témák
-
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.
-
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.
-
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?
-
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.
-
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
-
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.iso341 megamu_visual_studio_2015_update_3_x86_x64_dvd_8923065.iso6225 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.exeAz 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.
-
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? -
-
joysefke
veterán
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 -
Keem1
veterán
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>> nagyAmiből kéne egy olyan
List<dictionary<string,string>> kicsipartial 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.
-
joysefke
veterán
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... -
Keem1
veterán
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?
-
Livius
őstag
-
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. -
joysefke
veterán
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.
-
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?
-
Keem1
veterán
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.
-
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.
-
Keem1
veterán
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 -
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
veterán
-
Keem1
veterán
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. -
martonx
veterán
-
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
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. -
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
-
Keem1
veterán
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).
-
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
-
Alexios
veterán
-
Livius
őstag
Sziasztok!
Az MS oldalán belefutottam egy érdekességbe, pontosabban abba, hogy azt írjak a .NET framework 5.0 már telepíthető Linuxokra. Valaki próbálkozott ilyennel már, hogy egy C# WPF GUI-s program amit a Windows-ra csinált és ott jól is működik, Linuxon hogy lehet futtatni?
Install .NET on Linux -
martonx
veterán
winget-cli pont erre van, kb. 1 éve elégedetten használom. Igaz, a mai napig sincs meg minden rajta 100%-ban, pontosabban az elmúlt 1 évben 1 olyan alkalmazás volt, amit csak a scoop-ból (ez is olyan, mint a winget) tudtam beszerezni.
microsoft/winget-cli: Windows Package Manager CLI (aka winget) (github.com)
winget-pkgs/manifests at master · microsoft/winget-pkgs (github.com) - ezek vannak most rajta, percről percre bővül a lista. Ha te ezt meg tudod számolni, akkor sok sikertDe a belinkelt chocolatey is tök jó.
Nem fog hamvába halni, mivel ha figyelemmel követed, MS nagyon tolja a console irányt (windows terminal).
-
Keem1
veterán
válasz
joysefke
#9547
üzenetére
Na, végre valami kezdeményezés
Egyébként ahogy most így utánaolvastam, van valami MS-féle kezdeményezés is (winget), de félek hogy ez is hamvába fog hullni. Kb. 900 package-et látok benne (ha jól látom), ami egy Windows, mint target esetén még naponta is kevés, nem hogy összesen...
Pedig ez első olvasatra olyan, amilyennek én szeretném hogy legyen. Azt írják, lesz külső repo is (vagy már van is, legalábbis github skeletont már találtam hozzá).
-
Keem1
veterán
Srácok, szerintetek a Windowsnak miért nincs már végre egy normális package managere? Nem, a Windows Store nem az... bár az ötlet jó, a megvalósítás egy vicc kategória. Csak UWP appok vannak, külső forrás nuku, azt se tudom, hogyan lehet ott appot publikálni (sehol semmi említés, ingyenes-e vagy sem), és szerintem jellemzően MS által preferált fejlesztők/projektek vannak jelen, és maga a store tárolja egyedül a csomagokat.
Nekem inkább a Winstore az Android Store itteni megfelelője, jellemzően mobilos appokkal (hol vannak már a Wines telefonok...). Miért nem kerülhet oda be egy régebbi app, ha tökéletesen működik? Ne kelljen már összevadászni az installert. No meg miért csak az általuk engedett appok mehetnek, külső források miért nem? A Win Store ötletben zseniális, megvalósításban nem hogy kapufa, inkább öngól. Ja, és lehetne különböző láthatóság: publikálok egy appot, akkor mondhatom azt, hogy bárki elérheti, vagy mint a YouTube esetén, privát (csak én, mondjuk gépeim között), vagy nem listázott (akinek a linkjét átküldöm, az elérheti). Nagyon kétlem, hogy ezek a jó gondolatok csak nekem jutnak eszembe, és az MS zsenijeinek nem...Én inkább valami olyasmire gondolnék, mint a Debian alapú linuxokban az APT. Nem csak egy forrás, hanem ami alá van írva, bármi lehet a forrás, akár mirror site is. Bármilyen app mehet, a megfelelő platformra valót installálja, az update is pofonegyszerű.
-
pmonitor
aktív tag
válasz
pmonitor
#9544
üzenetére
Azt elfelejtettem, hogy a működő kód megtalálható itt. Valamint egy rövid leírás itt.
-
pmonitor
aktív tag
válasz
pmonitor
#9542
üzenetére
A következő módosítással sikerült megoldanom. Ezt:
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct PARTITION_INFORMATION_GPT
{
public Guid PartitionType;
public Guid PartitionId;
[MarshalAs(UnmanagedType.U8)]
public EFIPartitionAttributes Attributes;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 36)]
public string Name;
}Így módosítottam:
[StructLayout(LayoutKind.Sequential)]
public unsafe struct PARTITION_INFORMATION_GPT
{
public Guid PartitionType;
public Guid PartitionId;
public EFIPartitionAttributes Attributes;
public fixed byte Data[72];
}Így kell az unsafe kód engedélyezése, de a probléma megoldódott.
-
Keem1
veterán
Srácok, egy webclientes kódrészletet kéne kiegészítenem. Túl sok, bonyolult és fontos kód része, így csak a várt működéshez szükséges kóddal egészíteném ki.
Ami kéne, egy json stringet kéne az alábbiakkal együtt elküldenem POST-ként. UploadString jó lenne, de az alábbiakat átírni nem akarom. Muszáj ezzel kezdenem valamit, mert már működő kód.
GZipStream responseStream = new GZipStream(wc.OpenRead(page_url), CompressionMode.Decompress);
StreamReader reader = new StreamReader(responseStream);
ResponseHtml = reader.ReadToEnd(); -
pmonitor
aktív tag
A következő kód:
using System;
using System.IO;
using System.Runtime.InteropServices;
namespace DiskProp
{
class Program
{
const uint IOCTL_DISK_GET_DRIVE_LAYOUT_EX = 0x70050;
public enum PARTITION_STYLE : int
{
MasterBootRecord = 0,
GuidPartitionTable = 1,
Raw = 2
}
[Serializable]
[StructLayout(LayoutKind.Sequential)]
public struct DRIVE_LAYOUT_INFORMATION_MBR
{
public long Signature;
}
[Serializable]
[StructLayout(LayoutKind.Sequential)]
public struct DRIVE_LAYOUT_INFORMATION_GPT
{
public Guid DiskId;
public long StartingUsableOffset;
public long UsableLength;
public long MaxPartitionCount;
}
[Serializable]
[StructLayout(LayoutKind.Explicit)]
public struct DRIVE_LAYOUT_INFORMATION_UNION
{
[FieldOffset(0)]
public DRIVE_LAYOUT_INFORMATION_MBR Mbr;
[FieldOffset(0)]
public DRIVE_LAYOUT_INFORMATION_GPT Gpt;
}
[StructLayout(LayoutKind.Sequential)]
public struct PARTITION_INFORMATION_MBR
{
public byte PartitionType;
public bool BootIndicator;
public bool RecognizedPartition;
public Int32 HiddenSectors;
}
[Flags]
public enum EFIPartitionAttributes : ulong
{
GPT_ATTRIBUTE_PLATFORM_REQUIRED = 0x0000000000000001,
LegacyBIOSBootable = 0x0000000000000004,
GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER = 0x8000000000000000,
GPT_BASIC_DATA_ATTRIBUTE_HIDDEN = 0x4000000000000000,
GPT_BASIC_DATA_ATTRIBUTE_SHADOW_COPY = 0x2000000000000000,
GPT_BASIC_DATA_ATTRIBUTE_READ_ONLY = 0x1000000000000000
}
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct PARTITION_INFORMATION_GPT
{
public Guid PartitionType;
public Guid PartitionId;
[MarshalAs(UnmanagedType.U8)]
public EFIPartitionAttributes Attributes;
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 36)]
public string Name;
}
[StructLayout(LayoutKind.Explicit)]
public struct PARTITION_INFORMATION_UNION
{
[FieldOffset(0)]
public PARTITION_INFORMATION_MBR Mbr;
[FieldOffset(0)]
public PARTITION_INFORMATION_GPT Gpt;
}
[Serializable]
[StructLayout(LayoutKind.Sequential)]
public struct PARTITION_INFORMATION_EX
{
[MarshalAs(UnmanagedType.U4)]
public PARTITION_STYLE PartitionStyle;
public long StartingOffset;
public long PartitionLength;
public int PartitionNumber;
public bool RewritePartition;
public PARTITION_INFORMATION_UNION DriveLayoutInformaiton;
}
[Serializable]
[StructLayout(LayoutKind.Sequential)]
public struct DRIVE_LAYOUT_INFORMATION_EX
{
public PARTITION_STYLE PartitionStyle;
public int PartitionCount;
public DRIVE_LAYOUT_INFORMATION_UNION DriveLayoutInformaiton;
[MarshalAs(UnmanagedType.ByValArray, ArraySubType = UnmanagedType.Struct, SizeConst = 128)]
public PARTITION_INFORMATION_EX[] PartitionEntry;
}
[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern IntPtr CreateFile(
[MarshalAs(UnmanagedType.LPTStr)] string filename,
[MarshalAs(UnmanagedType.U4)] FileAccess access,
[MarshalAs(UnmanagedType.U4)] FileShare share,
IntPtr securityAttributes, // optional SECURITY_ATTRIBUTES struct or IntPtr.Zero
[MarshalAs(UnmanagedType.U4)] FileMode creationDisposition,
[MarshalAs(UnmanagedType.U4)] FileAttributes flagsAndAttributes,
IntPtr templateFile
);
[DllImport("kernel32.dll", ExactSpelling = true, SetLastError = true, CharSet = CharSet.Auto)]
public static extern bool DeviceIoControl(IntPtr hDevice, uint dwIoControlCode,
IntPtr lpInBuffer, uint nInBufferSize,
IntPtr lpOutBuffer, uint nOutBufferSize,
out uint lpBytesReturned, IntPtr lpOverlapped
);
static void Main(string[] args)
{
Type ts = typeof(DRIVE_LAYOUT_INFORMATION_EX);
int ss = Marshal.SizeOf(ts);
}
}
}Ezt a kivételt dobja:
Nem kezelt kivétel: System.ArgumentException: A típus („DiskProp.Program+DRIVE_LAYOUT_INFORMATION_EX”) nem adható át végrehajtásra nem felügyelt struktúraként; nem számítható ki értelmezhető méret vagy eltolás.
a következő helyen: System.Runtime.InteropServices.Marshal.SizeOf(Type t)A DRIVE_LAYOUT_INFORMATION_EX elég összetett struktúra. Nem tudom, hogy hol lehet a hiba. Van valami 5letetek?
-
-
Keem1
veterán
válasz
sztanozs
#9534
üzenetére
A már sokat emlegetett céges team toolomat egészítem ki egy auto dark switcherrel.
Van egy cron lib, aminek a joblistje szabványos crontab stringet és a futtatandó metódust kéri.
Aztán start() és innentől már nem az én dolgom a jobok futtatása, megoldja ez a lib a háttérben külön threadekként.
A dark mode on és a dark mode off kerül bele két fix taskként, és ehhez generálom a cron stringet.
Erre két opció megy: kézzel megadja a delikvens (dark on xx:xx-kor, dark off yy:yy-kor) vagy automatikusan lekért földrajzi hely szerinti napkelte/napnyugtakor.
Ha ez elég lenne, egyszerű lenne a két cron string: "xx xx * * *" illetve yy yy * * *". De nem elég, a napokat is bele akarom mazsolázni: az utolsó csillag a days of week, ami lehet * (minden nap, ha vagy egyik nap sincs kiválasztva, vagy mind a hét be van kattintva), vagy pedig a napok sorszáma/rövidítése vesszővel felsorolva (1,2,5 vagy Mon, Tue,Fri).Dióhéjban ennyi.
* Igen-igen, tudom, hogy van egy csomó kész megvalósítás (még egyiket se próbáltam), de céges gépre nem tehető fel külső forrásból semmi.
-
Keem1
veterán
Köszönöm, megnézem ezt is
Időközben találtam egy megoldást, de félve merem leírni, mert eléggé gány Lett egy ilyenem: List<DaysOfWeek> dayschecked
Aztán a DaysOfWeek.TryParse segítségével csekkolom a LINQ által kiköpött checkbox texteket, amik (optimális esetben) azonosak egy nap nevével. És a dayschecked végül így a kiválasztott napokat tartalmazza. A cron string készítésekor pedig a napok első 3 karakterét joinoljaGány... de működik. A cron elfogadja a napok számait és a napok 3 betűs rövidítéseit is. Ez utóbbit lovagoltam meg.
-
Keem1
veterán
A lista egy crontabszerűséghez lenne.
A lényege, hogy Monday=1, ... Sunday=7
A formon fenn vannak a napok, amikből készül a crontab string utolsó szekciója.
Az megvan, hogy ha a bekattintott elemek száma = 7, akkor ez * lesz. Ha pl. csak a hétfő, akkor 1. Ha hétfő-kedd, akkor 1,2. És így tovább.Szóval a cél az, hogy:
- ha a bekattintottak száma 0 vagy 7, akkor a(string)cronweek = "*". Itt mindegynek veszem, hogy mind be van-e kattintva vagy egyik sem, az a teljes hetet fogja jelenteni.
- ha 1-6 van bekattintva, akkor azok numerikus indexei kerüljenek bele vesszővel elválasztva, pl:(string)cronweek = "1,5,6"Az adott stringemnek kötelezően vagy egy csillagnak, vagy 1-től 6-ig vesszővel elválasztott felsorolásnak kellene lennie a bekattintott checkboxokból azzal a megkötéssel, hogy ha mind be van kattintva vagy egyik se, akkor kötelezően csillag legyen.
Szóval ez a cél.
-
-
Keem1
veterán
Srácok, van a formon egy groupbox, azon pedig 7 db checkbox (vizuálisan beragadó gomb formájában). Ezek a hét napjait reprezentálják.
Addig eljutottam, hogy a bekattintott napokat (egyelőre a control neveit stringként) bedobom egy listbe:List<string> days = new List<string>(gbDays.Controls.OfType<CheckBox>().Where(chk => chk.Checked).Select(chk => chk.Name).ToList());Nekem viszont olyan kéne, hogy a groupboxban betöltött indexük szerint (ahol az első checkbox a 0., az utolsó a 6.) kellene inkább egy List<int>. Feltéve ha egyáltalán van ilyen indexük.
Szerintetek?Közben rájöttem, hogy elvileg a fenti LINQ kódot lehetne továbbvinni úgy, hogy a mostani listában szereplő index kerülne bele a végső, int listbe. Ugye?
Pszeudo:
int[] dayindexes = ListOfControls().WhereChecked().ToList().IndexesFromSourceList().ToList();Nem tudom, ez mennyire érthető így.
Szerk2: ez nem biztos hogy jó ötlet. Összezavarodtam
-
leslie23
tag
válasz
pmonitor
#9526
üzenetére
Nagyon köszi nektek a segítséget, még nem volt időm foglalkozni vele.
Az asnyc-await biztos, az enabled propertyt elegendő lenne a menustripen false-ra tenni, szóval ez elegánsan hangzik. Az egyetlen félelmem továbbra is a színes ikonok miatti 2-3 másodperces szürke/színes "villogás", ami az enabled változtatása során történik. Ki fogom próbálni, ha nagyon zavaró, akkor marad az OnClick eventek programozott hozzáadása/lecsatolása.
Köszi szépen a tippeket! -
pmonitor
aktív tag
válasz
leslie23
#9525
üzenetére
Ha fizikailag egy csoportba tudod tenni azokat a control-okat, amelyeket nem szeretnél használni a művelet alatt, akkor használhatsz groupbox vagy panel controlt, és akkor
panel1.Enabled=false;vagygroupBox1.Enabled=false;,
majd ha végeztél, akkor true.Ha nincsenek 1 csoportban, akkor még mindig van olyan lehetőség, hogy 1 listába beleteszed azokat a control-okat, amiket le szeretnél tiltani. Ebben az esetben 1 ciklussal kell végigmenni a lista elemein, és így tiltani/engedélyezni.
-
leslie23
tag
válasz
martonx
#9524
üzenetére
Szia! Köszi, async-await lesz mindenképp. Viszont ha jól értelmezem, akkor az await ellenére másik gombra még rá tud kattintani a user, és le is fog futni mögöttes logika. Én lényegében ezt szeretném megakadályozni. Vagyis elkerülni azt, hogy ténylegesen fagyjon az UI, de nem engedni olyan műveleteket meghívni, amelyek csak úgy értelmezhetőek, ha a DataGridView már teljesen készen van.
-
leslie23
tag
válasz
Alexios
#9522
üzenetére
Ez konkrétan WinForms, de gondolom ebből a szempontból a WPF is hasonló lehet. Az Enabled property kapcsolása amúgy jó ötlet, így megúszható lenne a bool flag ellenőrzés az eventök elején. Az egyetlen bajom, hogy így WinFormsnál két másodpercre minden control elszürkül, ami a relatíve sok színes ikon miatt egy viszonylag erős villanó effektust jelentene.
Esetleg a Click eventek lecsatolása, majd újbóli hozzáadása szerintetek járható út, vagy ez fapados megoldás lenne? -
Alexios
veterán
válasz
leslie23
#9521
üzenetére
Milyen desktop alkalmazás? De igazából jó úton jársz, WPF esetében pl. csinálhatsz valami bool propertyt ami ha kattintható akkor true, amúgy false, és ehhez kötöd a uicontrol-ok IsEnabled propertyjét.
A ui szál nem lefagyasztására az aszinkron futtatás lesz a megoldás, ahogy mondod. -
leslie23
tag
Sziasztok!
Azt hogy tudom észszerűen megcsinálni egy desktop appnál, hogy adatok frissítése alatt (gombra rányom, adatokat lekérem DB-ből és újra populálom + formázom a DataGrid-et, összesen ez kb. 2 másodperc) a UI ne legyen fagyva, vagyis a gomb vizuálisan ne legyen lenyomott állapotban, de újabb műveleteket ne tudjon kezdeményezni a felhasználó.
Ezeket egyébként értelmezni is nehéz lenne, mert bármilyen művelethez előzetesen az összes adat betöltése szükséges.
Egyelőre aszinkron futtatás és egy flag használata tűnik megoldásnak, a flag értékét pedig minden egyes user által indított esemény elején ellenőrizni kell. Viszont mivel elég sok control elem van a formon, ez kicsit körülményesnek tűnik. Van erre jobb megoldás? -
Keem1
veterán
válasz
sztanozs
#9519
üzenetére
Valahogy úgy...
De semmi nem tart örökké, majd az ő tündöklésük is alábbhagy. Nekem sose kéne olyan IoT megvalósítás, ahol egy szem mobilappot tukmálnak.
Egyrészt miért csak mobil? Miért dedikált app? Desktop miért nem? Otthonlevés érzékelése? Sehol.. Napkelte-napnyugta? Sehol.Jobban preferálom az átjárható megoldásokat, mindenki azt használhatja, ami szimpatikus. Szerencsére sok ilyen van. Az én Smart Home-om felülete is alapvetően HTML5+JS. Gyors, szép, mobilon és desktopon is tökéletes. És érzékeli ha hazaértem, és lámpát gyújt. Meg sötétedés után kapcsol. De a többi hasonló is ilyen, pl. a Domoticz.
A saját megoldás egyedüli erőltetése beszűkült látásmódot és az innováció teljes hiányát jelenti.Na mindegy, befejeztem az offot.
-
Keem1
veterán
válasz
joysefke
#9517
üzenetére
Röviden? Megszüntették az API-t
Egyébként:dynamic responsejson = JsonConvert.DeserializeObject(Response);
if (responsejson != null && responsejson.Count != null && responsejson.Count > 0)
{
foreach (var item in responsejson)
{
returndata.Add(item.Name, item.Value);
}
}A lényegi része ez.
Kicsit hosszabban:
De időközben a remek Xiaomi-Yeelight páros szó nélkül kivette a 3rd party API-t a lámpáikból. Egyik este vettem észre, hogy a scheduled task szerint már kapcsolnia kéne, mégse teszi. Aztán miután rátaláltam rengeteg elégedetlen vásárlóra a szó nélkül, lapítva kivett funkció miatt, próbáltam szabadságharcosként én is részt venni benne. Miután a Pi-n deaktiváltam a lámpákat, hogy ne legyen tele a log a hibaüzenetekkel.
Még megy a szájkarate a gyártó fórumain, mert semmilyen 3rd party eszközzel nem mennek most a Xiaomi lámpák. Domoticz, Home Assistant, stb. kuka -
Keem1
veterán
válasz
sztanozs
#9515
üzenetére
Ó hogy azanyáját
Ha már tényleg fontos a platformfüggetlenség, vajon miért nem lenne jó egy full univerzális
Environment.DetectYourOSVersionWhateverYouUse()metódus...Na mindegy, vannak dolgok, amik szerintem a józan ésszel ellenkeznek, de ez legyen az én bajom.
Köszönöm, így már működik
Amúgy azt se értem, hogy a Dark/Light módhoz a registry-t kell b*szatnom, egy univerzális (akár WinAPI) motyó helyett. Már látom előre a rögtönítélő őtiszteletreméltó McAfee ferde nézését a folyamatos registry b*zerálás miatt
-
sztanozs
veterán
[link]
oka
* For applications that have been manifested for Windows 8.1 or Windows 10. Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2). To manifest your applications for Windows 8.1 or Windows 10, refer to Targeting your application for Windows.
Identifying the current operating system is usually not the best way to determine whether a particular operating system feature is present. This is because the operating system may have had new features added in a redistributable DLL. Rather than using the Version API Helper functions to determine the operating system platform or version number, test for the presence of the feature itself. -
Keem1
veterán
Srácok, életemben először kell Windows verziót megállapítanom (néhányan kértek tőlem egy scheduled dark/light theme switchert, amit érdekes módon a Windows még magától valamiért nem tud).
Viszont ez Windows verzió függő (ha valaki nem jó OS-t használ, akkor nem fog működni).
Ámde azEnvironment.OSVersionnem jó Windows verziót jelez.Több gépen is tesztelve az output - ez bizony egy Windows 8:
Microsoft Windows NT 6.2.9200.0Míg valójában az én rendszerem:
Microsoft Windows [Version 10.0.19042.867]Mi az oka a bugnak?
-
#9513
sztanozs
veterán
DrojDtroll
#9512
sztanozs
veterán
válasz
DrojDtroll
#9512
üzenetére
persze - az az adott osztályra cast-ol, vagy null-t ad - gyakorlatilag az alábbinek megfelelő synthetic sugar:
// object o = valami();
// T t = o as T;
T t = o is T ? (T)o : null; -
#9512
DrojDtroll
veterán
DrojDtroll
veterán
Jól sejtem, hogy ott ahol "as" operátor van használva kellene null-check is?
(ASP.NET Webforms legacy projekt -> nagyon sok helyen van a session-ből listába-tömbbe alakítás, majd munka a listán null check nélkül)
-
joysefke
veterán
Dictionary<string, object> -be deszerializálni nem megoldás?
Ez tartalmazná az első hiearchia propertijeit azok neveivel mint kulcsokkal és a hozzájuk tartozó "nem túl típusos" objektumértékkekkel. Ami kulcs hiányzik, olyan property nem volt a Jsonban.
Ha a második hiearchiaszint propertijei már erősen típusosak, akkor ott _gondolom_ már működni fog a castolás object-ről?
Ha a dynamic vonalon indulsz el, nézd meg az ExpandoObject-et. Ez is egy <string, object> dictionary valosít meg, többek között.
-
vlevi
nagyúr
Newtonsoft tud dynamic-t csinálni a jsonbol.
Tényleg nem célszerű sűrűn használni, de, ebben az esetben talán ez a jó megoldás.
A dynamicnal le tudod vizsgálni mindegyik részét, hogy null-e vagy sem, ha tömb, hány eleme van, satöbbi.
Nekem is volt olyan, ahol a httppost után visszakapott json a végeredmény függvényében más és más volt. -
Keem1
veterán
Srácok, mi a legjobb módja egy nem fix tartalmú JSON feldolgozásának?
A legjobb alatt értem, hogy tökéletes része legyen egy már meglévő robosztus programnak, ne f*ssa magát össze ha új entry kerül a JSON-ba vagy kerül onnan ki.A legjobb módja nyilván a szerializáció lenne, használtam már ilyet, de ott 1:1 megfeleltetés volt a JSON tartalma és a célobjektum között. Ez most nem ilyen, ez egy webes response, és a kutya füle se tudja, mikor mi kerül épp oda bele. A helyzetet bonyolítja, hogy multidimenziós a response. Nekem nem kell minden bele, de egy full háttérben futó eszközön menne (kijelzés nincs, log persze van), így nem túl szerencsés, ha egy-egy query alkalmával összehugyozza magát a program.
A Newtonsoft.Json library-t használom, valamennyire ismerem, de ott nem találtam erre biztonságos megoldást erre. A legegyszerűbb egy multidimenziós, bejárható objektum lenne, fogalmam sincs, létezik-e ilyen C#-ban. A dynamic nevű "adattípus"-t
ismeremhallottam róla, de ahogy tudom, eretnekség használni.Ha nem létezik ilyen, amit én keresek, megoldom máshogy (pl. felbontom a kapott JSON-t rész-objektumokra és szerializálom belőle azt, amire nekem szükségem van), csak ez egyrészt kicsit macerásabb, másrészt nehezebben vihető tovább, ha később kiderül, más adat is kell a response-ból.
Egyébként ha nem multidimenziós lenne, akkor valószínűleg egy dictionary-t használnék.
-
martonx
veterán
válasz
pmonitor
#9506
üzenetére
Továbbra sem értek egyet. Kezdőkről, sőt ha az eredeti kérdést olvastad, ultrakezdőkről beszélünk.
Akik nem azért kotorásznak a designer.cs file-ban, mert tudatosan abban akarnak módosítani, hanem mert olyan szinten fingjuk sincs, hogy mit csinálnak, hogy találomra bökdösnek a boldogan megtalált .cs file-okra.Ergo őket nem félrevezetni kellene, meg összezavarni, és ne abból indulj ki, hogy minden kezdő egyébként istenadta programozózseni, csak még kevés a tapasztalata.
Hanem egyértelmű iránymutatásokkal terelgetni, és majd ha egyszer (valaha?) oda jut, hogy valamit elrontott a designer file-ok piszkálása nélkül, akkor jöhet az igazság minden részletének kibontása , hogy figyi vannak ezek a designer file-ok, amikről eddig azt mondtuk, hogy ezeket nem kellene piszkálni. No, de ezek nem poénból vannak ott, van olyan eset, amikor ezekben kell javítani a visual kódszerkesztő dolgait. Ilyenkor ezekbe tudatosan bele lehet, sőt kell is nyúlni.
Ettől még az ökölszabály, hogy ezeket nem kellene piszkálni, továbbra is áll.Egyébként meg kötözködés helyett, neked is szabad megválaszolnod kérdéseket, szabad a pálya.
Mindenki szabadidejében teszi, te is nyugodtan beleállhatsz, csak ne zavard össze, ne vidd félre szegény kezdőket -
pmonitor
aktív tag
#9482 martonx: *.designer.cs fileokat nem szabadna módosítani.
vs.
#9505 fatal`: alapvetően nem abban turkálunk.Azért ez a 2 kijelentés között elég nagy különbség van. Pl. ha azt írta volna, amit te, akkor történetesen egy szavam sem lett volna.
Szerintem meg egy kezdő winforms-osnak kötelező megismerni azt, hogy a design nézet mögött mi zajlik a háttérben. Módosítani valamit design nézetben, megnézni, hogy ez mit változtatott a .design file-ban, használni a szürkeállományát, hogy ez miért is történik stb.. stb.. A kezdőn nem a friss kezdőt értem azért, hanem aki már tisztában van az event-ekkel. Sőt, az sem árt, ha esetleg néha ránéz az IL kódra is, hogy egy kicsit ahhoz is konyítson. Mint ahogy az sem baj, ha egy C-s kezdő nézegeti a generált ASM kódot is.
Martonx szerint meg semmi köze a .designer.cs file-okhoz.
Ez merőben eltérő filozófia a kettőnk között. Én azért alakítottam ki ezt az álláspontom, mert ha 1 kezdő elszúr valami olyan dolgot, amit nem tud helyreállítani(bár igazából nem kellene feladnia), akkor sem történik semmi. Egy példaprojekt tönkrement. És? Viszont sokkal magabiztosabb lesz később, mikor esetleg hozzá kell nyúlni egy éles projektben(ami nem mehet a kukába).
-
fatal`
titán
válasz
pmonitor
#9502
üzenetére
Ismét terelsz.
Nem azt mondtam, hogy nem javítunk meg elcseszett designer fájlokat, hanem, hogy nem gányolunk bele mindenfélét. Nyilvánvalóan nem árt, ha értjük, hogy mi van benne, de azt nem azt jelenti, hogy össze-vissza gányolunk benne.#9503: A fenti eset nem ritka, így ebben az esetben nem értek egyet, de nem ez volt a kiindulópont.
De mindegy, túl sok hsz-t pazaroltunk erre, a lényeg, hogy alapvetően nem abban turkálunk.
-
pmonitor
aktív tag
válasz
Alexios
#9503
üzenetére
Ezért írom le már harmadszor, hogy tudni kell, hogy mit csinál az ember fia/lánya.
Az mindenképpen csak jó, ha ÉRTI valaki a működést, mert adott esetben helyre tud hozni dolgokat.
Én pl. jártam úgy, hogy 1 codeproject.com-os példában eleve elszállt a designer nézet. Hasznos volt, hogy tudtam, hogy mit kell csinálni.szerk.: mondjuk nekem aztán mind1, hogy valaki érti-e, vagy nem.
-
Alexios
veterán
válasz
pmonitor
#9502
üzenetére
De a kiindulási pont nem az volt, hogy miután elrontottunk valamit turkálni kéne benne, hanem hogy ha pl. új controlokat akar létrehozni, vagy meglevőkhöz hozzáadni, stb, akkor azt ne itt tegye.
(A felvázolt problémádnál pedig egyszerűbb megoldás szeirntem ha visszacsinálod a módosításokat, mint ennyire belemélyedni ebbe
vagy legalábbis 1. pont után érdemes lehet bekomitolni a változásokat, és nem érhet gond ) -
pmonitor
aktív tag
De beleírhatunk. Képzeld el a következő esetet:
1.: Designer nézetből létrehozol egy eseményt.
2.: Valamilyen megfontolásból törlöd az esemény Designer nézetben(de az eseménykezelő metódust nem, mert ugyebár azt nem törli a designer nézetből)
3.: Mégis szükséged lenne az eseménykezelőre.Ebben az esetben létrehozol designer nézetben egy eseménykezelőt dupla kattal. Igen ám, de ez az eseménykezelő metódus üres, az eredeti metódust akarod vissza csinálni. A létrehozott eseménykezelő metódust törlöd. Ekkor elszáll a designer nézeted. Innen már nincs más választásod, mint a designer file-ban turkálni.
Lehet, hogy a példám nem mindennapos, de előfordulhat, hogy MUSZÁJ a designer file-ban turkálni, hogy helyrehozd a designer nézetet.
-
fatal`
titán
válasz
pmonitor
#9500
üzenetére
Akkor most olvasd el mégegyszer a kiindulást adó kérdést/problémát.
A designer által generált fájlba nem írunk bele. Erre jössz azzal, hogy nincs rá feltétlenül szükség. Senki nem is mondta, hogy van, lehet bármekkora kuplerájt csinálni a kódban, de nem erről volt szó.
Ki is lépek abból a programból, nem jó semmire ![;]](http://cdn.rios.hu/dl/s/v1.gif)
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).
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Vivo X200 Pro - a kétszázát!
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Alkoholista nevelde
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Nyíregyháza és környéke adok-veszek-beszélgetek
- Synology NAS
- Tőzsde és gazdaság
- Kerékpárosok, bringások ide!
- Videós, mozgóképes topik
- Kedvenc zene a mai napra
- További aktív témák...
- HP Zbook 15 G3 laptop (15,6FHD/I7-G6/16GB/256SSD/AMD2GB/MagyarVilágítós/Win11)
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új csak kipróbált Smartech 55 139cm Qled 4K UHD Quantum tv google assistant,Netflix, stb
- DJI Mini 4 pro - Fly More Combo - RC2 drón szett +128GB SanDisk SD
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RTX 4060Ti 8GB GAMER PC termékbeszámítással
- Lenovo ThinkPad X13 G2 multitouch
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- BESZÁMÍTÁS! MSI B550 R9 5900X 32GB DDR4 512GB SSD RX 6700 XT 12GB Rampage SHIVA Enermax 750W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged