- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Android alkalmazások - szoftver kibeszélő topik
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Íme az új Android Auto!
- Samsung Galaxy Watch7 - kötelező kör
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy S24 FE - később
- Bemutatkozott a Poco X7 és X7 Pro
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Fotók, videók mobillal
Új hozzászólás Aktív témák
-
Alexios
veterán
muszáj az existinguser.Property1 = value1; minden egyes módosítandó adatnál, tehát a problem, hogy mindegyik elé mehet az object neve is.
De amúgy ez miért olyan nagy baj, vagy miért számít egyáltalán? Szerintem teljesen lényegtelen, martonx megoldása teljesen jól olvasható, ha nem létezik létre hozod, ha igen explicit látszik miket módosítasz, majd mentés, mindenféle magic nélkül ahol találgatni kell hogy működik és mint látjuk nehéz debugolni. Az egyetlen pont inkább ellene hogy ha az id-n kívül minden propertyt updatelni akarsz, akkor ha később hozzá adsz egy új propertyt akkor ezt is updatelni kell, de szerintem ezt azért meg lehet ugrani.
De tényleg, az hogy használni kell az object nevét nem kódismétlés, ettől nincs duplikalt kód, redundancia, akármi. Ha ennek a metodusnak a tartalmát atmasolnad egy másikba, ahelyett hogy ezt hívnád, na ott lenne kódismétlés, és abból lehetne gond.
-
Alexios
veterán
válasz
pmonitor
#10083
üzenetére
A fő probléma azzal van hogy a referencia típus fogalmát kevered az object-el.
Pusztán az hogy az értéktípusok is az object-ből származnak végső soron(nem nehéz amúgy ezt belátni, nem véletlen ignoráltad gondolom a kód példámat is, de ugyanúgy elérhető minden metódus egy int-en is ami egy objectben van, csak hogy még szemléletesebb legyen, ha már a language specet teljesen ignorálod), nem jelenti azt hogy ettől a heap-ben vannak tárolva. Pont ez a System.ValueType lényege, ennek köszönhetően vannak értéktípusként kezelve. Tehát az hogy a System.ValueType-ból származik, nem jelenti hogy ez egy referencia típus, hiszen pont a System.ValueType miatt lesz értéktípus, de ettől az még az objectből származik. Ha pl. egy intet objectként kezelsz akkor jön a boxing, hiszen referencia típusként akarod kezelni(itt is látszik hogy az object az ősosztályuk amúgy, hiszen simán átadhatsz egy intet mondjuk egy metódusnak ami objectet vár, mindenféle compiler error).
Kicsit olyan ez inkább mintha egy ősosztályán át hivatkoznál egy példányra, ott sem érheted el a metódus/propertyk stb amik a leszármazott osztályban vannak, érték típusoknál meg ha objectként hivatkozol rá akkor jön a boxing, és "elveszted" a leszármazott érték típus tulajdonságokat.(ez csak egy analógia, nem a pontos mechanizmus a kötekvést elkerülendő) -
Alexios
veterán
válasz
pmonitor
#10080
üzenetére
Biztos ezért zártak ki
Már linkeltem amúgy neked a hivatalos language specet persze leírtad hogy ők sem tudják miről van szó [link] All struct types implicitly inherit from the classSystem.ValueType, which, in turn, inherits from classobject.
Tudom hogy úgysem hiszed el, de azért futtasd le ezt a kódot is és nézd meg az outputot, gondolom a nyelv maga se tudja miről beszél:int x = 1;Console.WriteLine(x is object); -
Alexios
veterán
válasz
Tomi_78
#10076
üzenetére
Fordítsuk meg a kérdést és gondold át mit kéne csináljon a program akkor ha olyan ágba kerülsz ahol nem inicializálod majd később hivatkozol rá. Vagy adsz egy default értéket (pl az if/switch blokkok előtt, int valtozo =1; ), vagy minden lehetséges úton inicializálni kell ha később hivatkozol rá.
Az utóbbinál amúgy az a baja hogy ha var-t használsz akkor egyből inicializálni kell, mert a compiler nem tudja hogy mi az. A switchen belül pl az egyik ágban számot, másikban szöveget adnál neki, honnan tudja melyik a helyes? Ez egy erősen típusos nyelv, nem lehet egy változó egyszerre több típus, tehát vagy megmondod az elején hogy milyen típus lesz és később is tudod inicializálni, vagy használod a var kulcsszot és egyből értéket adsz neki hogy tudja milyen típus kell legyen.
-
Alexios
veterán
válasz
Tomi_78
#10070
üzenetére
másold be az egész releváns kódrészletet, pusztán hibaüzenetből nehéz látni mi a gond
De ennek így jónak kéne lennie:
int[,] palya;switch (mostpalya) {case 1:palya = new int[,]{{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{0,0,0,0,0,0,0,0,0,0},{2,0,0,0,1,0,0,0,0,2},};break;} -
Alexios
veterán
válasz
pmonitor
#10049
üzenetére
Akkor még egyszer utoljára leírom.
Az állítás nem az volt hogy mindegy melyiket használod _bármelyik_ esetben, hanem hogy _ebben_ az esetben mindegy volt, hiszen ezek ciklusok, nem típusokon lehet végigmenni velük, hanem gyűjteményeken. Az eredeti kérdező kérdése az volt hogy mire jó a foreach, továbbra is fenntartom, hogy az ő esetében az lett volna a lényeg hogy gyűjteményt csináljnon és menjen rajta végig(ahogy végülis meg is csinálta), ezt pedig bármivel megcsinálhatta, foreach/for/while _ebben_ az esetben mindegy, hiszen a gond nem a foreach-el magával volt hanem hogy amit ő szeretett volna abban a formában nem lehet.
Azt hogy mit lehet módosítani közben, vagy törölni, csak te hoztad ide, senki más nem vitatta, hiszen az állítás nem az volt hogy foreachben az aktuális itemet nem lehet megváltoztatni, hanem hogy az hogy pl. foreach(string a string) miért nem értelmes.while() és a for() egyébként csak megerőszakolva működik minden enumeratoron(de nyilván nem erre tervezték.
Ez egy teljesen mellékszál, de ez nem megerőszakolás, és annyira erre tervezték hogy a foreach egy syntactic sugar ahogy fatal is írta, azaz valójában build után ez while-al fog menni az enumeratoron. Ettől függetlenül te, én, stb, mint végfelhasználó nem így fogjuk írni, hiszen nyilván azért hozták létre a syntactic sugar-t hogy használjuk, de ettől még nem árt tisztában lenni a működésével, és azzal hogy ez nem megerőszakolás.
Illetve a mindegy nem mindegy részhez annyit, hogy _mindent_ amit foreach-el meg lehet írni, meg lehet for vagy while ciklussal(hiszen a foreach is egy fancy while ciklus), de fordítva ez már nem igaz, szóval fölösleges újabb példákat hozni rá, mert senki nem vitatja ezt.+1 a linkedről:
c#-ban mindennek van egy közös szülőtípusa, úgy hívják object
Most ha attól eltekintünk hogy tök nyilvánvaló kötekvés ha azt nézzük az eredeti kérdező kérdésének mi volt a lényege, ha jól értem erre a cáfolatod a struct akar lenni [link] itt a hivatalos msdn c# language spec doksi, ez egyértelműen írja hogy All struct types implicitly inherit from the classSystem.ValueType, which, in turn, inherits from classobject
Tehát minden struct implicit a System.ValueType-ból származik, az pedig az objectből. Ettől még nyilván van lényegi különbség a value és reference típusok között, nem kell cáfolaltot felhozni, ha ez nem tetszik a Microsoft-al vitatkozz, ők tervezték a nyelvet, és ez az ő reference dokumentumuk. -
Alexios
veterán
válasz
Tomi_78
#10047
üzenetére
Jó lesz így már, nyilván kód szervezésre nem feltétlenül ez a legjobb, vagy nevezéktanra, de ha működik akkor működik. A lényeg az hogy valahogy nyilván kell tartanod ha valami konkrétan akarsz végigiterálni, aztán erre vannak különböző módok még, de kezdésnek elég lesz szerintem ez neked.
#10046 fatal` : Hagyd, átment a saját blogjára továbbra is csak a lényegi mondandót kiforgatva olyanokról vitatkozni amit senki nem mondott
-
Alexios
veterán
válasz
pmonitor
#10043
üzenetére
Nincs olyan amin foreach-el végig lehet menni, de while-al nem, fentebb mutattam is példát miért van ez így(mert pl. a foreach is egy while-ra fordul), a hashset sem kivétel ezalól(for-al is meg lehet természetesen csinálni, nem muszáj indexel elérni elemeket for cikluson belül is, mégha nem is célszerű). Az más kérdés persze megint, hogy magaddal vitatkozol.
-
Alexios
veterán
válasz
pmonitor
#10039
üzenetére
Nézd már meg az eredeti kérdést, nem volt benne .Count, pont erről beszéltem hogy az nem egy gyűjtemény, hanem egy típus. A JatekElemei nem egy lista, tömb, akármi más volt, hanem egy osztály típus, max statikus countja lehetne technikailag, ami nincs. Ahogy ez is volt a kérdés hogy miért nem lehet végig menni foreachel rajta, és azért mert nem egy gyűjtemény. Ugyanúgy for és while-al se lehet vegigmenni rajta, mert nem egy gyűjtemény, de még csak nem is egy peldanyositott akármi
-
Alexios
veterán
válasz
pmonitor
#10037
üzenetére
De tökmindegy, hiszen arról volt szó hogy az esetben _mindegy_ melyikkel iterálna végig rajta, egy gyűjteményen(vagy enumeratoron, mielőtt ebbe köt valaki) kell és nem egy típuson. Ebből a szempontból teljsen mindegy hogy for, while, foreach, mert a kérdés nem ez volt, hanem az hogy lehetséges-e ilyen:
foreach(tipus objnev tipus){}
ami ugye nem. Ilyen szempontból tökmindegy, mert ilyet sem lehet hogy while(tipus) meg olyat sem hogy for(tipus), mert értelmezhetetlen ebbe a formában, hiszen ez nem egy gyűjtemény. Az állítás nem az volt hogy mindig mindegy melyiket használod, hanem ebben az esetben az. -
Alexios
veterán
válasz
pmonitor
#10035
üzenetére
Ha el is olvasod az egész mondatot amit írtam beszéljünk.
Ha már nagyon kötekvés akkor meg lehet nézni mit is csinál egy foreach:int number;while (enumerator.MoveNext()) { number = enumerator.Current; }Innen tök érthető hogy miért nem lehet megváltoztatni, csak hát sosem mondtam hogy meg lehet, sőt, teljesen másról beszéltem.
-
Alexios
veterán
válasz
pmonitor
#10030
üzenetére
Most nem teljesen értem ebből a szempontból a kötekvést, be lehet hozni persze értéktípusokat, akkor 98%-ban minden az objectből jön, a lényeg hogy nem kell csinálni egy őstípust csak azért hogy legyen egy őstípus.
Nem tök mind1. Mert pl. foreach esetén nem módosíthatod magát az objektumot. Csak az objektum.akármi-t.
Ezt pláne nem értem, ha az egész mondatot olvasod és nem csak a részét kiragadva, akkor úgy folytatódik hogy mindegy mert gyűjteményeken mennek végig. Persze most bele lehet menni iterátorokba, stb, meg abba hogy ez se teljesen igaz így, hiszen ha valami yield return-el adja a cuccokat az biztos gyűjtemény-e, de emberünk nem tudja min lehet egy ciklussal végigmenni, nem gondolnám hogy ez itt releváns.Mert pl. foreach esetén nem módosíthatod magát az objektumot. Csak az objektum.akármi-t.
Ha már ennyire kötekedni akarunk, a gyűjteményt nem tudod módosítani, pont azért mert egy enumerátoron megy a foreach -
Alexios
veterán
válasz
Tomi_78
#10027
üzenetére
Tehát ha mindennek van egy közös szülőobjektuma
Amúgy c#-ban mindennek van egy közös szülőtípusa, úgy hívják objectAkkor hozzak létre egy Listát is, amelybe belekerülnek az osztályobjektumok, és ennek a Listának a nevét adjam meg a foreach-ben az egyik JatekElemei helyett?
Igen. Foreachel, de igazából, while, for, tökmindegy mivel gyűjteményeken iterálsz végig, nem típuson.
lassanként elvész az egyszerűség, mert ezesetben ugyanúgy gondoskodni kell a Lista kezeléséről, amikor elemeket adok hozzá vagy törlök belőle.
De valakinek csak gondoskodni kell róla nem? Vagy nem teljesen értem az elképzelésed, honnan tudja az alkalmazás hogy min akarsz végigmenni, mi legyen benne vagy nem? Az hogy van egy szülőtípus az nem azt jelenti hogy ő tisztában van minden leszármazott példányáról, ez csak a típus meghatározásban segít neked.
#10026 quailstorm : igen, én is írtam hogy reflectionnel meg lehet csinálni, csak 90%-ban ha felmerül hogy reflectionnel menne, az egy rossz gondolat
Kezdőknél pedig 100%-ban rossz gondolat, kizárt hogy egy kezdőnek bármilyen szempontból _tényleg_ szüksége legyen rá. -
Alexios
veterán
válasz
Tomi_78
#10024
üzenetére
Min akarsz végig iterálni?
foreach (JatekElemei jatelem in JatekElemei) {itt a foreach ugye maga a ciklus. Ezek után a zárójelen belül először jön a típusa az adatoknak ami esetedben JatekElemei lenne(amúgy használhatsz var-t is ha nem akarod kiírni, de itt most pont jól látszik) aztán a ciklusváltozónév amit adsz az adott elemnek, majd magát a listát amin végig akarsz iterálni. Viszont te az objektum típusát adtad meg és nem egy listát/tömböt/valamit amin végig lehet menni.
Mivel egy gyűjteményed van az egészben, és az is más típusú, ezért ha tippelnem kéne nem erre akarod használni, viszont kicsit zavaros számomra hogy mit szeretnél akkor.
Ha a kérdésed az hogy az összes JatekElemei típusú objektumodat szeretnéd frissíteni, akkor ezeket valahol trackelned kéne és azon végigiterálni(vagy technikailag reflectionnel is meg lehet valószínűleg csinálni, de ne tedd), de ebben a kódrészletben az se világos igazából hol hozod létre azokat amiket frissíteni szeretnél itt
van egy fő osztály, amelyből minden más osztály származik a programban
Már ez a kiindulási pont is rosszul hangzik amúgy hogy miért akarsz ilyet csinálni, biztos erre van-e szükséged -
-
Alexios
veterán
Olyan nagy breaking changek nincsenek 5 és 6 között már, valószínűleg simán tudod upgradelni bármi gond nélkül. De amúgy igen, az utóbbi időben felgyorsult a .NET fejlesztése, jelenleg a 6 az LTS azaz hosszabb távon támogatott verzió, és két évente jön egy új LTS, közben pedig egy rövidebb ideig támogatott verzió (jelenleg a 7 az aktuális)
-
Alexios
veterán
válasz
martonx
#9855
üzenetére
Nincs túl nagy react native tapasztalatom, viszont Microsoft xaml frameworkökkel van elég sok ahhoz hogy ne akarjak új projektet kezdeni rajta, főleg mikor vannak más alternatívák amiket nem fognak holnap kukázni a következő 70%ban hasonló dologért, inkább csak ezért a kérdésem
vagy ha legalább a Microsoft átírná valami saját alkalmazását maui-ra hogy kicsit komolyabban vehető legyen hogy ezt már tuti komolyan veszik -
Alexios
veterán
válasz
leslie23
#9817
üzenetére
Ha a kérdés az, hogy van-e még piaci igény WPF fejlesztőre, a válasz igen. Az, hogy hosszútávon mennyire éri ebbe most jelentős energiát fektetni más kérdés, de nekem is jelentős WPF fejlesztés volt pl. az előző munkahelyemen.
WinUI3/MAUI-ra amúgy elég könnyen átvihető a tudás, de én nem biztos arra alapoznék, hogy ezek nagyon el fognak terjedni a jövőben, desktop alkalmazásnál jó vagy sem sokkal inkább az electron és hasonlók az irány, én inkább efelé mennék el ha most 0ról akarnék desktop fejlesztéssel foglalkozni. -
Alexios
veterán
válasz
bandi0000
#9808
üzenetére
Ha jól értem a problémád, akkor igazából az a gond hogy ha nem is singletonra van beregisztrálva a DI-ba a függőség, de ugyan azt a példányt adja vissza két külön requestre - ezt pl. lehet állítani asp.net core-ban biztosan, hogy milyen életű legyen a függőség, lásd: [link] Egy nagy mindenhez is értő szerviz feldarabolása mondjuk kifejezetten jó ötlet(single responsibility principle pl.), hogy minden csak azt hívjon ami kell is neki tényleg
Ettől függetlenül amúgy létezik természetesen method injection is, asp.net core-ban is akár, lásd: [link]
-
Alexios
veterán
Én ezt az örököltetést nem erőltetném a helyedben, mert egyrész semmi szükség rá
Másrészt az öröklés IS-A kapcsolatot felételez, márpedig már nyelvtanilag is látszik hogy a dark IS A light nem állja meg a helyét
De ott agyalok, hogy a ColorScheme osztályt egyelőre nem tudom implementálni, mert nem tudom neki megmondani hogy az light és dark is lehet igazából.
Én itt megmondom őszintén nem teljesen értem mire gondolsz, de én a joysefke által felvetett úton mennék tovább -
Alexios
veterán
Hát, lehet érdemes lenne megnézni a c# és oop alapokat, mert ez kb a legalapabb öröklődés
Példa:
using System;public class Program{public static void Main(){var dark = new Dark();Console.WriteLine(dark.Magenta);Console.WriteLine(dark.Green);}}public class Light{public virtual string Magenta{get;} = "LightMagenta";public virtual string Green {get;} = "LightGreen";}public class Dark : Light{public override string Magenta {get;} = "DarkMagenta";}Ha a kérdés az, hogy ezek statikus propertyk lennének, akkor statikus propertyket nem lehet virtualnak vagy abstractnak megjelölni, szóval felülírni sem lehet őket
-
Alexios
veterán
Rég volt már algoritmusok és adatstruktúrák órám, de ahogy mondja quailstorm is, egy fa struktúra alapvetően egy irányított gráf, szóval abban érdemes gondolkodni.
Kész megoldás helyett/mellett ajánlom hogy olvass utána az adjacency matrix/adjacency list struktúráknak, mert gráfok leírására van kitalálva, és bármely programnyelvben tudod implementálni.
Itt egy példa rá c#-ban: [link] -
Alexios
veterán
De hol szeretnéd a végén látni? Azt leszámítva hogy a változóneveknek fordítási időben már ismertnek kell lennie is ott lenne a probléma, hogy c#-ban nem fognak csak úgy globális változók létrejönni, szóval ami a cikluson belül jön létre, az utána már azon kívül nem lesz elérhető.
Ha c#-ban nem lehet ezt megcsinálni, akkor miért szeretnéd más nyelven, főleg ha a fentebb említett megoldások sem jók, hanem kell az hogy legyenek ilyen változónevek, mi a cél?Technikailag amúgy javascriptben pl. megoldható, csak felmerül a kérdés, hogy miért akarnál ilyet csinálni?
-
Alexios
veterán
válasz
martonx
#9716
üzenetére
Biztos mennie kell macen is, eleve a Xamarin Studiot nevezték át anno vs for mac-re, ios fejlesztésnél kell mac eleve hozzá a buildhez, bár hobbi projekthez én is vagy maui-t(mondjuk ebből még mindig csak previewk vannak..) vagy react nativeot kezdenék inkább tanulgatni már.
Hogy a témához is hozzászóljak, milyen macről van szó?
[link] Itt ugyan erről a hibáról írnak, esetleg erre rá lehet nézni -
Alexios
veterán
válasz
joysefke
#9706
üzenetére
2,
Ha azért csomagolnád be a DbContext-et egy abszrakt, generikus UoW / Repository petternbe, hogy az EFCore egy absztrakció mögé kerüljön, és a felsőbb réteg ne dependáljon közvetlenül az EF felé, akkor ez nemes és jó indok, de saját tapasztalatom alapján nem működik jól.
Én ezzel szintén saját tapasztalat alapján nem értek egyet, nálunk pl. nagyon jól működött mikor legacy appot migráltunk ef6-ról ef core-ra, majd szintén mikor bizonyos részeket dapperre. A kliens kód oldaláról lényegében semmi változás nem történt csak az interfészek mögötti implementációk -
Alexios
veterán
de .NET 5-ön belül mi, WPF, Winforms, más?
Az, hogy webapp vagy sem mondjuk szerintem nem sokat dob azon hogy szép vagy sem, desktopon is meg lehet bármit csinálni
WPF-en belül ha van egy listád amihez tudsz bindolni, akkor a lista elemeire simán tudsz csinálni egy ilyen ListViewItem-et, amiben mondjuk van egy Grid 4 oszloppal, elsőben a kép, a másodikban a név, harmadikban a dátum, negyedikben a gomb, stb. Winformson belül is biztos van valami hasonló
-
Alexios
veterán
Nem teljesen értem a kérdést
Ha a kérdés az hogy a desktop appon belül valami browser controllal legyen megjelenítve, szerintem ne, bár előnye lehet hogy később újra használhatod.
Nem tudom milyen desktop frameworköt használsz, de igazából bármelyikben ugyanúgy kivitelezhető, nem is különösebben bonyolultan.
WPF-et ismerem én, ott mondjuk egy ListView-t kötsz a listádhoz, és a ListViewItem-nek a datatemplatejében már azt csinálsz elemenként amit szeretnél -
Alexios
veterán
ItemsSource gyűjteményeknél van, ekkor ennek egyes elemei lesznek a datacontextjei a uielementeknek.
A DataContext leegyszerűsítve annyit jelent, hogy annak az osztálynak a propertyjeihez lehet kötni, ezt meglehet explicit is határozni, de sokszor - pl. az itemssourcenal - is beállítódik, attól hogy nincs konkrétan kiirva
-
Alexios
veterán
A scaletransformot be kell állítani valamihez, mert ez valaminek a transzformációja. A sima zárójel amúgy ha használsz mögötte {} zárójeleket is nem feltétlenül muszáj.
Szóval vagy van valamid amit szeretnél méretezni a xaml-ben, ott adsz egy nevet neki x : Name-el, majd a code behindban arra hivatkozol, vagy azt amit méretezni is akarsz code behindban hozod létre, és a végén hozzáadod a mainwindowhoz.Viszont, igazából mindegyik megoldás idegen a WPF-től, még ha működne is. Kezdésnek tudom, hogy viszonylag sok tud lenni, de tényleg érdemes olvasni az MVVM patternről, és data bindingról, mert egyrészt sokkal egyszerűbb dolgod lesz, másrészt erre van kitalálva. A lényege, hogy xaml-ben létrehozod a ui elementedet amit akarsz, majd ezt hozzá kötöd egy propertyhez, ezt általában egy viewmodel osztályban szokták, esetedben ha kezdésként a xaml.cs fájlban van sem gáz. A lényeg, hogy az az osztály, amihez kötni akarod meg kell valósítsa az INotifyPropertyChanged interfészt, ez az egész WPF sava-borsa, majd ha változás van akkor ezzel jelezni.
Valami ilyesminek kéne lennie pl.:
public partial class MainWindow : Window, INotifyPropertyChanged{//Inotifypropertychanged interfész megvalósításapublic event PropertyChangedEventHandler PropertyChanged;protected void OnPropertyChanged([CallerMemberName] string name = null){PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));}//Property amihez tudsz kötni xaml-rőlprivate double scaleX;public double ScaleX{get => scaleX;set{scaleX = value;//Ez az egész lényege, emiatt fog értesülni a UI arról hogy változás történtOnPropertyChanged();}}
public MainWindow(){InitializeComponent();//Esetünkben nincs viewmodel, szóval ez az osztály lesz az ahol keresni fogja a propertyket
DataContext = this;//Kezdésnek legyen 1, bárhol változtathatod aztán a kódban, pl. timerrelScaleX = 1;}}Aztán xaml-ben így lehet kötni hozzá:
<!--Ui Element amit méretezni akarsz, itt egy grid, de amúgy kb bármi lehet-->
<Grid>
<Grid.RenderTransform>
<!--Kötés a ScaleX propertyhez, amit a code-behindban állítunk-->
<ScaleTransform ScaleX="{Binding ScaleX}"/>
</Grid.RenderTransform>
</Grid>A lényeg, hogy ezután, ha lesz egy timered, akkor csak simán a ScaleX propertyt kell állítanod, és semmi más varázslatra nincs szükség.
-
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?
-
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. -
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. -
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
-
Alexios
veterán
-
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. -
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 ) -
#9492
Alexios
veterán
DrojDtroll
#9488
Alexios
veterán
válasz
DrojDtroll
#9488
üzenetére
Unit/egyéb tesztek ahogy korábban is írták, ajánlott olvasmány: [link]
-
Alexios
veterán
válasz
Tomi_78
#9342
üzenetére
Szia,
Nem teljesen értem a kódodat, ezt valahonnan kimásoltad? A problémák amik előjöttek azért vannak, mert olyan változókat használsz amik nincsenek sehol deklarálva.
Pl. az srcRect és units változókat miért adtad meg a DrawImage-ben, ha nincsenek is ilyenjeid?Az egydenever változót használod minden metódusban, pedig a konstruktorban, mint lokális változó hozod létre. Ha egy metóduson belül hozol létre egy változót, akkor az csak azon a metóduson belül fog élni, máshol nem, ezt javíthatod a kódon belül pl. így:
Bitmap deneverkepe1 = new Bitmap("kepei\\kisdenever1bmp.bmp");Bitmap deneverkepe2 = new Bitmap("kepei\\kisdenever2bmp.bmp");Deneverek[] egydenever;majd később már csak ehhez rendelsz értéket:
egydenever = new Deneverek[3];
int svsz;De érdemes lenne első körben a nyelv alapjait is átnézned.
Illetve miért pont SharpDevelop, ami évek óta discontinued állapotban van?
-
Alexios
veterán
Hát, elég egyértelmű az exception
.NET Core 3-al bekerültek olyan api-k is, amik nem platformfüggetlenek. Pl. WPF kódot lehet .NET Core 3-al írni, de ettől még nem fogod tudni linuxon futtatni, ha tippelnem kéne akkor a System.ServiceProcess is ilyen[link]
Szerintem ezt a linket nézd meg, itt jó eséllyel találsz megoldást -
Alexios
veterán
A .NET fw 4.8-al véget ért, security patchek érkeznek hozzá egy darabig, és kész. Idén jön a .NET 5, az már a core-ra épül, ez a jövő
Inkább pont fordítva, mi értelme .net fw-ben egy új projektet kezdeni?(főleg 4.5-ben)Ráadásul ha linuxon is akarsz .net-et futtatni, eleve nem látom értelmét mással kezdeni, mint az ott natívan támogatott .net core-al
-
Alexios
veterán
-
#9227
Alexios
veterán
DrojDtroll
#9226
Alexios
veterán
válasz
DrojDtroll
#9226
üzenetére
Én fejlesztettem még rá régen, bár túl sok minden nem rémlik már belőle
-
-
Alexios
veterán
válasz
alapz@j
#8874
üzenetére
A nyelvet tényleg, de azért általában valamilyen frameworkön belül szokták ezt használni, aminek megvannak a saját tooljai, stb, frameworktől függ mennyire jó a doksija, supportja, akármi, szóval azért nem teljesen lényegtelen.
De amúgy tény, hogy simán lehet váltani, ha az ember szeretne
-
#8514
Alexios
veterán
DrojDtroll
#8513
Alexios
veterán
válasz
DrojDtroll
#8513
üzenetére
Na de ha ez egy típushoz tartozó, statikus dolog, akkor miért akarnád eleve interface-be rakni, hogy más is megvalósítsa - azt ami egy kifejezetten X típushoz tartozik?
Szerintem, mikor ilyen igények lépnek fel, ott valószínűleg eleve érdekes a kód is már. -
#8511
Alexios
veterán
DrojDtroll
#8509
Alexios
veterán
válasz
DrojDtroll
#8509
üzenetére
absztrakt osztály esetleg, itt az ososztaly tartalmazhat statikus metodusokat, de ezeket nem fogod tudni felulirni egy származtatott osztályban, mivel a statikus metódus nem példány hanem típushoz van kötve- azaz c#-ban nincs olyan hogy abstract static vagy virtual static
-
-
#8466
Alexios
veterán
pelgrim_v1
#8464
Alexios
veterán
válasz
pelgrim_v1
#8464
üzenetére
Szerintem magyarul az egyetlen értelmes c# könyv a Reiter István féle C# programozás(vagy valami hasónló címe van
) Bár egy pár éves már, de alapnak bőven elég kéne legyen -
Alexios
veterán
Ha jól értem, a belső Dictionary kulcsait szeretnéd visszakapni a belső dictionary értékei alapján?
Ott hirtelen valami ilyesmi jut eszembe, bár lehet van ennél hatékonyabb megoldás is:properties.SelectMany(m => m.Value.Where(s=>s.Value.Equals("megnevezes"))).Select(k=> k.Key)Az más kérdés, hogy itt valójában az értékeid a kulcsok, lehet célszerűbb lenne a kettőt felcserélni, és máris egyszerűbb lenne a keresés. De szerintem amit kereshettél a SelectMany, az az amivel tudsz a külső dictionary összes elemében selectelni
(#8452) tboy93 : Várakozik, de érdemes megnézni a linkelt oldalt. Ott írja, is, hogy ha már nagyobb a terhelés nem célszerű Sqliteot használni, mert nem megbízhatóak a filerendszerek lockolásai, és előfordulhat, hogy sérül az adatbázis, de szerintem esetedben nem lesz ez gond, nyilván enterprise környezetbe nem ez a megoldás
-
Alexios
veterán
Én nem vagyok meggyőzve róla, hogy ez a dictionary a dictionary-ben a leghatékonyabb módja annak amit tárolni akarsz.
Igazából nem is teljesen értem mit szeretnél, tulajdonképpen min iterálnál végig? Az első dictionaryn?
Az pl.:
properties.Where(p=> p.Key.Contains("partners"))Vagy eleve tudod hogy az első dictionary "partners" kulcsainál tárolt adatain akarsz végigmenni? Akkor ha stringet akarsz keresni, miért objectként tárolod? Ha stringként tárolod valami ilyesmi lenne:
properties["partners"].Where(p=> p.Value.Contains("megnevezes")).Select(s=>s.Key)
Ez ugye egy listát fog visszaadni, nem 1 db id-t, mert itt semmi nem garantálja, hogy egy value-hoz csak egy key van, ha te tudod akkor esetleg lehet pl. FirstOrDefault-ra cserélni a Where-t, csak akkor meg kell nézni, hogy nem null-e mielőtt megpróbálod az id-t elérni.De amúgy a linq sem varázslat, alapvetően ugyanúgy végigiterál egy foreachel a clr, csak ezt te nem látod
(#8449) tboy93 : Hát, igen meg nem. Ki tud szolgálni az sqlite több klienst is egyszerre, viszont amíg írja az adatbázist addig lockolja - tehát addig a másik írás meg kell várja az első befejezését. [link] Itt amúgy le is vannak ezek írva, mikor érdemes használni. Valószínűleg, ha jól értem, a te esetedben azért nem kéne olyan masszív terhelésre számítani, hogy ez gondot okozzon.
-
Alexios
veterán
-
#8051
Alexios
veterán
BTminishop
#8049
Alexios
veterán
válasz
BTminishop
#8049
üzenetére
Akkor legyen egy vertikális stackpanel, és soronként egy horizontális, és utóbbiba rakod a négyzeteket, a vertikálisba pedig a horizontálisokat
-
#8048
Alexios
veterán
BTminishop
#8047
Alexios
veterán
válasz
BTminishop
#8047
üzenetére
A stackpanel vertical és ne horizontal legyen
-
#8037
Alexios
veterán
BTminishop
#8036
Alexios
veterán
válasz
BTminishop
#8036
üzenetére
Érdemes, pl. már csak azért is mert jobban skálázódik különböző felbontásokra.
-
Alexios
veterán
Hogyne tanítanák progmaton, a tárgyból már nem emlékszem(Programozás vagy C++ volt talán?) de szó volt azért ilyen alap memória kezelés dolgokról nyilván. Ha meg csak a Stack mint algoritmusról van szó pláne
De azért ezek tényleg az alapok c#-nál is, referencia/érték típusok, boxing, stb, szó volt róla, hogy junior c# pozi van megcélozva korábban, ezeknek illene utánanézni előtte.
-
#7460
Alexios
veterán
BTminishop
#7459
Alexios
veterán
válasz
BTminishop
#7459
üzenetére
asp.net mvc
-
Alexios
veterán
Ha már rövidebben akarod akkor:
if ((Kiserocimkek.Count(a => EredetiKiserocimkek.Any(b => (a.EloirtDarab != b.EloirtDarab) || (a.Vonalkod != b.Vonalkod))) > 0)
return true;Viszont itt nincs semmiféle sorrend, minden elem össze van hasonlítva mindegyikkel, eleve ha fontos az index, akkor nem nagyon fogod linq-val megírni
) Bár egy pár éves már, de alapnak bőven elég kéne legyen
Ú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!
- Könyvajánló
- sziku69: Fűzzük össze a szavakat :)
- Medence topik
- Hálózati / IP kamera
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Autós topik
- Android alkalmazások - szoftver kibeszélő topik
- Horgász topik
- Spórolós topik
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- További aktív témák...
- ÚJ aktiválatalan Apple iPhone 16 Pro 128GB ! 1ÉV nemzetközi APPLE GARANCiA
- Új Gamer PC - Ryzen 7 5700X / RTX 5060 / A520M / 16GB vagy 32GB RAM / 240GB + 1TB M.2 SSD / 650W
- Samsung Galaxy Z Fold 4 256 GB, szürkészöld + S Pen tok
- TP-Link ER-7212PC Omada 3-in-1 Gigabit VPN Router
- TP-Link EAP Omada Wifi AP-k (225, 245, 615)
- BESZÁMÍTÁS! MSI Z77 MPOWER Z77 chipset alaplap garanciával hibátlan működéssel
- 1-12 részletre.Új noblechairs EPIC műbőr FEKETE - FEKETE. 2 év garancia!
- Azonnali készpénzes INTEL CPU NVIDIA VGA számítógép felvásárlás személyesen / postával korrekt áron
- ÚJ Lenovo Legion Pro 5 16IRX9 - 16" WQXGA 165Hz - i5 14500HX - 32GB - 1TB - RTX 4060 - 3 év garancia
- Bomba ár! Lenovo ThinkPad T480s - i7-8GEN I 16GB I 256GB I 14" WQHD I HDMI I Cam I W11 I Gari!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest