Hirdetés
- Brogyi: CTEK akkumulátor töltő és másolatai
- Luck Dragon: Asszociációs játék. :)
- droidic: Windows 11 önállóság nélküli világ: a kontroll új korszaka
- sziku69: Fűzzük össze a szavakat :)
- Mr Dini: Mindent a StreamSharkról!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Gurulunk, WAZE?!
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Pitterix: Gyógytorna
- GoodSpeed: Miért úszta meg Albert Speer? (Reagálás a Telex cikkére)
Új hozzászólás Aktív témák
-
#5393
Karma
félisten
trisztan94
#5392
Karma
félisten
válasz
trisztan94
#5392
üzenetére
Két lehetőséged van:
1) A JSON felől minden mezőt stringre átírsz, és utólag konvertálsz egyesével mindent számmá. Brrr.
2) Írsz egy saját JsonConverter leszármazottat, ami lekezeli azt a helyzetet, hogy a debil szerver stringben küldi a számot, és kiparsolja automatikusan. Itt találsz rá példát, és én mindenképp ezt az utat javaslom. -
Karma
félisten
MASSIVE SPOILER ALERT!
No hát megfiatalodtam kicsit, és megírtam a feladatot én is
Generáltam tavok.txt-t, és megírtam LINQ-kela feladatokat.Ahogy jósoltam, a feladatok zöme egy sorral leírható. Mondjuk ha nem lett volna ez a perverzióm, lehet két sorban írtam volna a 4-5. feladatokat egy helyett
-
Karma
félisten
Nos akkor.
Egy általános észrevétel előre. Úgy látom a közoktatás le van ragadva azon a szinten, hogy korlátozott Pascal programozást tanítanak C# nyelven. (Erről már volt szó korábban, csak bebizonyosodik.)ű
Azt még elfogadom sok szemöldökborzolás mellett, hogy a LINQ 2 Objectset nem tanítják - mert így az összes érettségi feladat megoldható lenne egy-egy sorban -, de tömbök? Komolyan? Mindkettőtöknél nagyon megy ez, ezért hiszem hogy valami központi oka van...
Konkrétan akkor a bajok. A kozmetikai dolgokba, mint kis-nagybetűk, nem megyek bele.
Ott kezdődik, hogy static tagváltozókban van az adat, de mégis minek? A main függvény dolgozik csak vele, simán mehet oda lokális változónak. A static adatmezők, más néven globális változók csak bajt hoznak, ha hozzászoktok, és mondjuk a jövőben programozni is akartok. Más szakmák esetén mindegy; de akkor a hozzászólásom többi része is irreleváns.
Az adat struktúra elmegy szódával, viszont mint mondtam, nem tömbben kéne tárolni. Vannak a C#-ban nagyon jó lista szerkezetek, amik tudják magukról, hogy hány elem van bennük - ezzel az ind változó feleslegessé válik.
A List<T> a legegyszerűbb ezek közül. A Count-on keresztül eléred az aktuális darabszámot, és vannak metódusai elem hozzáadáshoz (Add) és törléshez is (Remove). Meg lehet szögletes zárójellel az akárhanyadik elemet manipulálni.
Tehát így néz ki a program eleje eddig:
...
class Program
{
struct adat
{
public int nap, dik, tav;
}
static void Main(string[] args)
{
var fuvar = new List<adat>();
... folyt köv...
}
}Az első feladatnál is kéne használni usingot a StreamReader köré. Ezen kívül a karakterenként feldolgozás feleslegesen lábbalhajtós. A soronkénti beolvasásig jó, utána kitör a WWIII. A sort fel tudod darabolni a Split metódussal a szóközök mentén, és azonnal kipotyog a három külön szöveg.
// 1. feladat
string sor = sr.ReadLine();
while (sor != null)
{
string[] elemek = sor.Split(' ');
adat f = new adat();
f.nap = int.Parse(elemek[0]);
f.dik = int.Parse(elemek[1]);
f.tav = int.Parse(elemek[2]);
fuvar.Add(f);
sor = sr.ReadLine();
}Egy csöppet rövidebb és olvashatóbb, nem?
Aztán mivel nincs ind, a ciklusokat fuvar.Count-ig kell járatni. Ez több helyen változtat a dolgon.
Na most első körben itt megállnék, mert nem akarom túlterhelni a fórumot. Egy kicsit nehezemre esik LINQ nélkül gondolkodni, mert tényleg egy sorba összeesnének vele a feladatok
De lehet inkább beadom a derekam és bevillantom a szebb világ képét.Még annyi, hogy az üres else {} ágakat teljesen felesleges kiírni, de legalább olvashatatlan.
-
#5381
Karma
félisten
trisztan94
#5376
Karma
félisten
válasz
trisztan94
#5376
üzenetére
Az enumerátorok a barátaid. Miután random sorrendbe rendezted a listát (vagy helyben, vagy egy jó extension methoddal), a garantáltan egyesével végiglépkedésre pont ez való.
-
Karma
félisten
válasz
tototos
#5371
üzenetére
Ha nem használsz try-finally-t akkor igen. Ebben az esetben ha bármi hiba történik és exceptionnel robban a kódod, a close nem hívódik meg, míg a using garantáltan lezárja. A finally blockba helyezett close szintén.
Attól még egy invalid path ugyanúgy exceptionnel robban, viszont a fájl meg garantáltan le lesz csukva.
-
Karma
félisten
Erre kapásból látszik a válasz: nem zártad be a fájlt. A legegyszerűbb, ha rászoksz a using kulcsszó használatára.
Vannak itt azért más gondok is, de a konkrét kérdésedre ez a válasz.
Holnap ki tudom fejteni a többit.using(StreamWriter sw = new StreamWriter(new FileStream("dijazas.txt", FileMode.Create))
{
for (int i = 1; i <= 7; i++)
{
for (int j = 1; j <= 40; j++)
{
for (int g = 0; g < ind; g++)
{
if (fuvar[g].nap == i && fuvar[g].dik == j)
{
sw.Write("{0}. nap {1}. út: ", i, j);
if (fuvar[g].tav <= 2) sw.WriteLine("500 Ft"); else { if (fuvar[g].tav <= 5) sw.WriteLine("700 Ft"); else { if (fuvar[g].tav <= 10) sw.WriteLine("900 Ft"); else { if (fuvar[g].tav <= 20) sw.WriteLine("1400 Ft"); else sw.WriteLine("2000 Ft"); } } }
}
else { };
}
}
}
} -
Karma
félisten
válasz
zsambek
#5340
üzenetére
Nem. Ehhez a feladathoz nincs szükség switchre, nem tudom trisztan94 mire gondolhatott vele.
Sokkal inkább van szükség egy klasszikus ellentmondás keresésre.
Például így:
#region MEGY 6. Feladat
string[] beolvrendszam = new string[7];
Console.WriteLine("6. Feladat: Kérem, vigye be a rendszámot:");
string beolvsima = Console.ReadLine();
foreach (var ell in ellenorzesek)
{
bool egyezik = true;
for (int i = 0; i < 7 && egyezik; i++)
{
if (beolvsima[i] != ell.rendszam[i] && beolvsima[i] != '?')
{
egyezik = false;
}
}
if (egyezik)
{
Console.WriteLine("6. Feladat: {0}", ell.rendszam);
}
}
#endregionMiközben írtad a sok egymásba ágyazott if-et, érezned kellett volna ahogy szárad le a kezed. Ha nem, legközelebb képzeld azt.
Egyébként a j változódat igazán átnevezhetnéd valami értelmesebbre. Direkt ki is hagytam a képből.
Másrészt vedd észre, hogy aposztrófok közé tettem a kérdőjelet: így nem kell substringgel és stringtömbbel szórakozni, a string ugyanis felfogható karakterek tömbjének is.
-
Karma
félisten
válasz
zsambek
#5337
üzenetére
Jézus ereje, miért csináltál hételemű string tömböt a rendszámból? Jó az egy darab stringnek is, illetve ez a sok rendszam.Substring(X, 1) is teljesen felesleges, mert ugyanezt tisztábban megkapod ha azt írod, hogy rendszam[X].
A switch ezen a helyen semmire se jó, de ezt az if-piramist azért ki lehet lapítani egy for ciklusba, ami az i-edik karaktereket összehasonlítja, és addig megy, amíg nem talál eltérést. Ha végigért, akkor meg kiír.
Van egy félsoros megoldás is regexekkel, de azt nem mondom el, mert egy erősen túlmutató területre vezet.
-
-
#5303
Karma
félisten
haromegesz14
#5301
Karma
félisten
válasz
haromegesz14
#5301
üzenetére
-
Karma
félisten
A natúr ContinueWith-tel az a baj, hogy ha nem jól paraméterezi az ember – márpedig egyáltalán nem triviális –, akkor a folytatásként meghívott Task háttérszálon fog futni, és nem jön vissza a hívó (tip. UI) szálra. Ilyen UI piszkálásoknál ez elég kritikus.
Referenciaként, a szükséges paraméter a kontextus:
Task task2= task.ContinueWith(() =>
{
this.TextBlock1.Text = "Complete";
}, TaskScheduler.FromCurrentSynchronizationContext());Ennél kicsit egyszerűbb az async/await kulcsszavakat használni
-
#5299
Karma
félisten
trisztan94
#5296
Karma
félisten
válasz
trisztan94
#5296
üzenetére
Kib... ronda.
Valahogy így nézne ki C# 5-ben tisztábban:
public async void Magic() {
emptyLetterHole.Visibility = Visibility.Collapsed;
filledLetterHole.Visibility = Visibility.Visible;
draggedButton.Visibility = Visibility.Collapsed;
await Task.Delay(1500);
filledLetterHole.Visibility = Visibility.Collapsed;
goodLetterHole.Visibility = Visibility.Visible;
await Task.Delay(3000);
goodLetterHole.Visibility = Visibility.Collapsed;
emptyLetterHole.Visibility = Visibility.Visible;
}---
A TextBlocknak meg adtál nevet (illett volna nagybetűvel kezdeni), azon a néven létrejött egy property a page-en. Ott el tudod érni (vagy ha nem használod, vedd ki az x
ame-et!).Másrészt a gomb Contentje tényleg a TextBlock lesz.
Harmadrészt meg az egész igen büdös, nem kéne minden logikát a Page-be írni...
-
#5286
Karma
félisten
trisztan94
#5285
Karma
félisten
válasz
trisztan94
#5285
üzenetére
MediaElementtel meg lehet csinálni mindkét variációt.
-
#5277
Karma
félisten
trisztan94
#5276
Karma
félisten
válasz
trisztan94
#5276
üzenetére
Típusnak inkább List<Nevek>-et adj meg, ha már listáról van szó
-
-
Karma
félisten
válasz
martonx
#5258
üzenetére
Igen, de azért mégis struktúráltabb, kontrolláltabb hozzáférést nyújtana az adatokhoz a szabad SQL futtatás helyett. Bár semmi értelme kardozni olyanokkal, akik szerint ez a megoldás rendben van.
Egyébként szerintem is megoldható WP-n simán.
trisztan94: Ennyi információ alapján egynek végülis elmegy. Bár a Synchronize-nak nem itt a helye szvsz.
-
Karma
félisten
válasz
tototos
#5251
üzenetére
Ettől még ne akard kódba rakni, mert az nagyon nem oda való, és amúgy is egy undorító félindiai megoldás. A resource-oknak ellenben pont ez a lényege, hogy belefordulnak az assemblydbe.
Ha resx fájlt adsz a projekthez, akkor string konstansként éred el a tartalmakat (és a solutionben egy fájl lesz, benne a két tartalommal); de olyat is csinálhatsz, hogy a solutionben külön fájlok, a kódban meg streamként éred el.
-
#5245
Karma
félisten
trisztan94
#5244
Karma
félisten
válasz
trisztan94
#5244
üzenetére
"Tényleg, mielőtt hülyeségeket beszélek: Az async az külön szálon fut? Pl. a RestSharp ExecuteAsync(request, asynccallback) metódus."
Általában igen, és úgy is illik, hogy a feldolgozás minél nagyobb része menjen háttérszálon (a CLR-ben lévő Async hívások ilyenek, saját kódnál meg pl. a Task.Run-nal tudsz háttérszálra küldeni dolgokat).
Viszont ez nem kötelező! Például ha egy Task<int> visszatérési értékű metódusodban a Task.FromResult() metódust használod, a visszaadott taszk azonnal kiértékelődik és nem lesz háttérszálra váltás, meg igazából aszinkron se.-----
"Erre kellett a HTTP POST, azzal kell elküldeni a MySQL query-t"... "Na most ez így elég rossz"
Áh, ez az igazi b@Ƶmeg kategória
Szoktam látni a hétköznapokban is durva kókány munkát, de ez simán dobogós lehetne.Mára már nagyon le vagyok merülve, úgyhogy nem tudok sokat regélni; de ha gyorsan demonstrálni akarsz, nézz utána az ASP .NET Web API 2-nek. Ezzel írhatsz egy olyan szerveroldali komponenst, aminek szép JSON/XML felülete van a mobilos klienseknek (olvasásra és írásra egyaránt megoldható), a konkrét adatbázist meg bőven elrejted.
De PHP-val se tartana sokból írni egy rendes controller osztályt, ami ilyen interfészt biztosít. Natúran se feltétlen, CodeIgniter és hasonló keretekkel meg pláne nem.
-
#5240
Karma
félisten
trisztan94
#5238
Karma
félisten
válasz
trisztan94
#5238
üzenetére
Pedig a HttpClient (NuGet: Microsoft.Net.Http) nagyon jól működik általában. Annyi csak, hogy az olyan headeröket, amik a bodyra vonatkoznak (a Content-Type ilyen pont) nem a Clienten és nem a HttpRequestMessage-en, hanem a String- Stream- stb. Content osztály Headersével tudod beállítani.
Telefonnal annyira nem könnyű példát vagdosni, úgyhogy majd később
-
Karma
félisten
válasz
Flashback
#5208
üzenetére
Adott a következő statikus osztály: [link]. Az ElementValue érdekes, de ott hagytam példaként két másik metódust, ami double-t vagy decimalt parse-ol ki az értékből.
A parsered így módosulhat ezek felhasználásával:
DPCO = item.Element("Data").ElementValue("PCO"),
DCaption = item.Element("Data").ElementValue("Caption"),
SConnect = item.Element("Data").ElementValue("Connection"),És ekkor kezelted azt, ha a Data vagy a PCO/Caption/Connection null.
-
Karma
félisten
válasz
Pttypang
#5205
üzenetére
Ez erősen feladatfüggő, de én a VM-re szavaznék ismét. Annyira figyelj majd oda, hogy a ListPicker nem lehet üres, egy alapértelmezett elemet mindig tartanod kell benne, valamint az elemeknek helyesen kell az Equalst implementálnia, mert az alapján kezeli a kiválasztást.
-
Karma
félisten
válasz
Pttypang
#5203
üzenetére
Mondtam hogy beszédes
Minden benne is van.
Amúgy ránézésre csak az a baj, hogy kisbetűvel írtad a bindingnál a property nevét. Érzékeny ám rá.adam014: A null coalescinggel csak az a baj, hogy a LINQ2XML-nél nem segít. Egyrészt a két oldalon azonos típusnak kell lennie (XElement vs String = aláhúzás), másrészt az ellen nem véd, ha a GetElement lánc közepében null valami. Sajnos.
Én amikor utoljára így parsoltam XML-t, csináltam extension methodokat, amik kicsit lerövidítették a nullchecket. Pl. string ElementValue(this XElement element, string childName, string defaultValue = null), ami a default értéket adja vissza akkor is, ha az element null, meg akkor is, ha az adott névvel nincs leszármazott tag
-
Karma
félisten
válasz
Pttypang
#5194
üzenetére
"Ha jól látom akkor a leírásodban említett ObservableObject ősosztály akkor nem is szükséges, mert az sqlmetal által legenerált kódban implementálva van?"
Pontosan.
"habár ha a LayoutRoot-nak adom át a menetrend db-t,"
Ez nekem kicsit meredek így kódrészlet nélkül, de ha bemásolnád, mondhatnék rá valamit. Egyébként ha binding hiba történik, az Output fülön elég részletes rókát hagy ott az engine: honnan, mit, milyen típust hova, milyen típusként, miért nem tudott bekötni.
Ilyen "üres a lista" szituációkban érdemes ránézni.
-
Karma
félisten
válasz
Pttypang
#5191
üzenetére
Apránként olvasd az osztályt, és lesz értelme
Annyiban bonyolultabb az én osztályomnál, hogy több tábla van benne - a Menetrend osztály Avasrol, Honnan és Jaratlista propertyjeivel érheted el ezeket.Felhasználás szempontjából én húznék egy ViewModel réteget ez elé, mert bár közvetlenül erre az osztályra is bindolhatsz, de plusz logikát (pl. szűrést, számítást) nem tudsz hozzátenni.
-
Karma
félisten
Pedig ránézésre azon túl, hogy túl hosszan fogalmaztál, rendben van a kód.
Ezt írtam próbaképp és működik is:
private void textBox1_TextChanged(object sender, EventArgs e)
{
int value;
if (int.TryParse(textBox1.Text, out value))
{
label1.Text = string.Format("Siker: {0}", value);
}
else
{
label1.Text = string.Format("Nem sikerult: '{0}'", textBox1.Text);
}
}Két dolgot próbálnék meg:
1) Breakpointot tegyél a metódus elejére, és kövesd végig milyen adatokat lát a kód.
2) A TryParse-ot cseréld ki Parse-ra, ami exceptiont dob -> abból láthatod, hogy mi akadályozta meg a feldolgozást.(#5183) Kommy: Nem lehet, hogy elnézted a nevét a controlnak, és a Round11 egy Label, nem pedig a TextBoxod? Vidd fölé a kurzort az IDE-ben, és tooltipben kiírja a típusát. Debuggolás közben meg meg tudod nézni akár azt is, hogy a sender kicsoda (pl. mi a neve).
-
Karma
félisten
Hátha valaki másnak is hasznos: tegnap estétől mostanáig összeütöttem egy PCL libraryt, amivel a pusher.comra lehet üzeneteket küldeni. Csak küldeni tud, feliratkozni és fogadni nem, de nekem pont ez kellett telefonon és Win8-on.
Meg ha a szolgáltatás nem is, talán arra érdekes példa, hogy egy PCL projekt hogyan szolgál ki három platformot párhuzamosan.
Igazából tavalyelőtt már használtam élesben egy koszosabb változatot, de most voltam úgy vele, hogy letisztázom és felteszem közösbe.
-
Karma
félisten
válasz
Alexios
#5136
üzenetére
Én úgy csinálnám - ezzel nem akarom implikálni, hogy ez követendő minta, csak az ízlésem más -, hogy az oldal DataContextje (aki egy viewmodel) felelős ezért.
Lenne egy DispatcherTimere és egy olyan propertyje, amin a képfájl elérési útvonala érhető el. Belül meg van egy fájllistája, amiből tickenként kiveszi a következő elemet, és az INotifyPropertyChanged interfészen keresztül felszól a XAML-nek, hogy változott a kép.
Fenn pedig egy szimpla bindinggal le van tudva a történet, 0 C# kód.
Ha mondjuk fade animáció is kéne a képek között, az valószínűleg kicsit bonyolultabb, de akkor meg írnék egy attached propertyt, ami kezeli az effektet. A bemenete ugyanúgy a bindingból jönne.
-
Karma
félisten
válasz
Alexios
#5121
üzenetére
Juj és pfúj. Persze majd ha felengedi, akkor meg másik brusht állít neki kézzel
A codebehind nem arra való, hogy azokat a dolgokat írja meg az ember, amiket egyébként is tud a rendszer... amargo közben megelőzött Rengeteg deklaratív megoldás van erre a problémára. Például az alap Silverlight elemek legtöbbje rendelkezik Normal, Pressed, Disabled állapotokat, amiket könnyen felül lehet bírálni Blendben a States fülön.
A pozíciónálós történetet is meg lehetne oldani okosabban: például egy Converterrel, ami figyelembe veszi a skálázás értékét (Application.Current.Host.Content.ScaleFactor), és az alapján felszorozva amikor Thickness objektumot ad vissza.
-
#5131
Karma
félisten
trisztan94
#5122
Karma
félisten
válasz
trisztan94
#5122
üzenetére
De lehet, ott a Device fül Stúdióban és Blendben is. A többi hozzászólást átolvasom mindjárt, de úgy érzem itt valami nagyon félrement...
-
#5114
Karma
félisten
trisztan94
#5112
Karma
félisten
válasz
trisztan94
#5112
üzenetére
Nyilván XAML-ben tudod ezt megoldani, margókkal, és nyugodtan zavard haza a "megrendelőt" ilyenkor.
-
Karma
félisten
válasz
Alexios
#5110
üzenetére
Azért az elég gáz, ha egy potenciálisan nullt visszaadó hívás után nem nézed meg az eredményt.
Az as egyébként ilyen esetekben szerintem kevésbé ronda, mint kézzel típust ellenőrizni és utána direct castolni.Mondjuk sok múlik a környezeten. DependencyObjectek tájékán mindig as-t szoktam használni, mert a XAML felől nincs típusellenőrzés így sok csekkolást igényel. Máshol meg nem szoktam castolni, csak ha muszáj
-
Karma
félisten
Szóval én így csinálnám. Ahogy ígértem, a lényeg három sor: a halak horoszkóp eldöntése két sor az IsPisces metódusban, és egy sor az emberlista leszűrése és kiiratása LINQ-val.
leximester: Kód nélkül elég nehéz erre bármit is mondani, esetleg megoszthatnád.
Két általános észrevétel addig is:
- BackgroundWorker 2014-ben? Hol voltál az elmúlt másfél évben? Az async API már WP7-en is használható (Microsoft.Bcl.Async csomag a NuGeten), WP8-on meg beépítetten megy.
- Kézzel töltött listát miért? A data binding nem véletlen van ott a rendszerben. -
-
Karma
félisten
Amit most linkeltél, az nem a feladatot oldja meg – túl sok felesleges dolgot rizsáz ki. Ha egy feladat azt mondja, hogy írd ki a neveket, akkor ne írjon ki semmi mást! ("nem férfi", "nem halak", stb. kuka) Egy érettségin, versenyen, való életben ez igen kritikus.
Az is fura, hogy a neveket beégetted, de a személyi számokat gépelgetni kell. Az egészet be lehetne égetni akkor már, és nem is lennél a konkrét 5 darabhoz kötve.
Egyébként kezdő Pascal kísérletnek szódával elmegy. C#-nak sajnos elég távoli.
Ha addig más nem szól bele, majd este kifejtem, hogy miért. -
#5084
Karma
félisten
trisztan94
#5083
Karma
félisten
válasz
trisztan94
#5083
üzenetére
Én mindig az MVVM mentén dolgozok, elég jó eszközök vannak a kényelmes alkalmazásához (mondjuk én csak az MVVMLightot használom, de van sok más is
).Mondjuk nem biztos, hogy erről kéne olvasgatnod, ha a korábban mutatott fogalomzavarokon még nem tetted túl magad teljesen. Az előző kérdéseidre sajnos nem tudok válaszolni. Én még gimnazistaként sokat forgattam programozási könyveket és feladatokat, az egyetem alattra pedig szépen összeértek és helyükre kerültek dolgok. Nem igazán volt egy meghatározó pont, egy könyv amit ajánlani tudnék.
De ha már az angol wikipédián végignézed a kapcsolódó anyagokat, akkor is előrébb kellene jutnod. Könyvet meg majd ajánl más
-
Karma
félisten
válasz
K_Gabor
#5079
üzenetére
A Stringben tárolás így is úgy is elég csökött megoldás, mert bitenként 16 bitet foglalsz le. Ha már valami, használj bool tömböket, de még jobb, ha nem is szívatod magad a bites formával.
Írtam egy minimál osztályt, ami biteket fogad, és nyolcanként kiírja egy Streamre. Itt megtalálod.
Ha FileStream helyett MemoryStreamet adsz neki, akkor byte tömböt is gyárthatsz könnyen vele.
-
Karma
félisten
válasz
K_Gabor
#5073
üzenetére
Félelmetes, hogy mi köze lehet egy pixelműveletnek a stringekhez...
De egyébként ha gyorsan akarsz bitmappel dolgozni, és nem telefonon/RT-n vagy, az unsafe pointeraritmetikánál nem nagyon lesz gyorsabb. Legalábbis a C# kód.
A biteskedésnél meg kell egy Stream ahova írod az eredményt, meg egy byte amibe shift művelettel tolod az értékeket.
-
#5066
Karma
félisten
trisztan94
#5061
Karma
félisten
válasz
trisztan94
#5061
üzenetére
Hazaértem, elolvastam, de... Ennek annyi köze van bármi objektumorientáltsághoz, mint egy vödör savas műtrágyának.
Tudod az objektumorientáltság, a nyelvtől függetlenül, nem arról szól hogy teleírod a kódod a class kulcsszóval. Amit eddig leírtál, ha egyszer azt is csinálja amit szeretnél, eddig kuka.
Az OO ott kezdődik, hogy szerepkörökre bontod a problémát. Ezeknek belső állapota van, amihez más nem nyúlhat. Van valami feladatuk, amit elvégeznek. A tieidre egyik se igaz.
Pedig Windows Phone-on nem kell még gondolkodni se nagyon rajta, mert adja magát egy MVP/MVVM felépítés. Csak meg kellene gondolni, mi az adat és mit kell vele csinálni.
Mivel nem értem hogy mi a feladatod (nincs nagy összhang a kód meg a pár mondat között), nem erőltetném hogy kitalálom helyetted. Az biztos pl., hogy egy szónak semmi köze ahhoz, hogy mondatban van-e vagy sem.
-
#5040
Karma
félisten
Peter Kiss
#5038
Karma
félisten
válasz
Peter Kiss
#5038
üzenetére
Csak sajnos nagy része, ami Guiddal operál, helytelen
-
#5035
Karma
félisten
Peter Kiss
#5033
Karma
félisten
válasz
Peter Kiss
#5033
üzenetére
Én removeAt helyett jobban szeretem ezt a technikát.
-
Karma
félisten
válasz
netpeti98
#4995
üzenetére
Most mindjárt olyat mondok, hogy kettéáll a füled: nem az a feladat, hogy rendezd a tömböt! Ujjgyakorlatnak persze jó volt a buborékrendezés, de a megoldáshoz felesleges.
A feladat szövegéből kiderül, hogy a bemeneted minden esetben 1 és N közötti számok kihagyás nélkül (definíció szerint). Neked azt kell vizsgálnod, hogy hány szám nincsen a helyén, és hány lépésből lehet őket a helyükre tenni, kézzel. Más szóval egy ideális rendezési algoritmust feltételezve.
Ha már ez a szám (legyen a példa kedvéért X) megvan, akkor közelebb vagy a megoldáshoz, de nem vagy kész. Ugyanis egy cserelépéssel lehet, hogy egy vagy két szám is a helyére kerül, azaz a kimenet kisebb mint X.
A példádat elnézve mondjuk egy szám sincs a helyén, úgyhogy X=10... De ennél kevesebb csere kell. Az ide vezető úton még gondolkodnom kell kicsit.
-
#4975
Karma
félisten
trisztan94
#4974
Karma
félisten
válasz
trisztan94
#4974
üzenetére
Most nem igazán van kapacitásom végigbogarászni a kódod, de ha már WP8-ra dolgozol, az "advanced" jelző ellenére a PhotoCaptureDevice API sokkal egyszerűbb az async hívások miatt. Szerintem megéri átállni rá.
-
Karma
félisten
-
Karma
félisten
Athlon64+ egy orbitális hibára hívta fel a figyelmem: az AsEnumerable használatával a LINQ to SQL már nem tudott beleszólni a DB hívásokba, folyamatosan felnyalt minden adatot...
Ezt javítottam is (frissítettem a bejegyzést), valamint feltoltam az egészet GitHubra.
-
Karma
félisten
Yay, valaki megjavított valamit a RIOS-ban, így fel tudtam tölteni a magyarázatot változtatás nélkül. Itt van a Logout bejegyzés hozzá.
-
Karma
félisten
Már húsz perce szívok a feltöltéssel lassan (nem volt elég az elmúlt hat óra a megírásához
), egyszerűen nem megy fel. A projekt elérhető innen, a szöveget meg egyrészt megpróbálom elküldeni privátban, aztán vagy átmegy vagy nem... -
Karma
félisten
Az a baj ezekkel (meg a korábbi) linkekkel, hogy az egyszerű példácskákból nehezen áll össze az ember fejében a teljes kép...
Főleg amikor némelyik teljesen tévútra viszi, miért kéne ObservableCollection itt például? Ha manuálisan hozza fel az adatot, akkor az eredményt egy az egyben berakhatja egy lista-típusú propertybe, és a listára meghívja a PropertyChangedet. Szerintem felesleges elemenként bizsergetni a listát.
Crytec2010:
Időközben elkészültem a saját megoldásommal. Írtam hozzá egy olyan terjedelmes leírást, hogy ide már nem is merem bedobni, inkább logoutra. Amint felment, beszerkesztem ide a linket, vagy külön hozzászólásba. -
#4951
Karma
félisten
trisztan94
#4950
Karma
félisten
válasz
trisztan94
#4950
üzenetére
Már bocs, de ez marhaság.
A WP8-ra célzott alkalmazások egyáltalán nem futnak, nem is láthatóak WP7-en. Pont fordítva van, mint írtad: a WP7-re célzottak futnak WP8-on szinte kivétel nélkül, quirks módban.
Érdekesség amúgy, hogy VS2013-mal már csak WP8-as projektet lehet indítani, a 7.1 támogatást kiölték. A Windows 8.1-gyel ugyanez a helyzet, sima 8.0-ás appot nem lehet kezdeni, sőt tönkre is teszi, ha abban nyitja meg a gyanútlan fejlesztő.
-
Karma
félisten
válasz
Pttypang
#4946
üzenetére
Igazából még egyszerűbb lenne, ha már úgyis WP7-re dolgozol, ha kihasználnád a platform egyetlen igazi erősségét: a XAML-t és a data bindingot
Minden bindingnál meg tudsz adni egy StringFormat paramétert, amivel deklaratívan le tudod írni a dátumformátumot. Például:
<TextBlock Text="{Binding StartTime, StringFormat='HH:mm'}"/>Mondjuk visszatérve a problémák helyes megoldásához, a megjelenítés formátumát se illik beégetni. Most persze lehet kivétel, mert magyar alkalmazásról van szó, de akkor is. Helyette a locale-specifikus "t" formátumstring a jó.
-
Karma
félisten
válasz
Pttypang
#4938
üzenetére
Dehogynem aljas, sőőőt. Pont ez szaglott már az előbb is.
Ha csak az óra-perc kell, és nem végzel vele dátumszámítási műveleteket, akkor is kapásból van két értelmesebb tárolási lehetőséged: 1) óra integer oszlop + perc integer oszlop; vagy 2) "14:20" jellegű varchar oszlop, amibe pont ennyit írsz.
Ha meg végzel ilyet, vagy csak a helyes megoldást keresed, akkor letárolod datetimeként, és megjelenítéskor beformázod egy HH:mm formátumtringgel. Ilyenkor még az se számít, ha az év/hónap/nap egyébként nulla.
-
Karma
félisten
válasz
Pttypang
#4935
üzenetére
Minden esetben a regionális beállításoktól függ a dátumformátum, szerencse hogy ilyen hamar beleszaladtál.
Eszközön meg emulátoron is át tudod állítani egyébként, így más kombinációkat is tesztelhetsz.Azt nem igazán értem, hogy mit és miért substringelsz a dátumon
Ez elég veszélyes és értelmetlen művelet...Gyanítom valami aljasságot művelsz a DB-vel, úgyhogy nézd meg ezt a választ hogy hogy kéne dátumot kezelni ebben a helyzetben.
Amúgy ha nem DB-ről lenne szó, tárolásra és átküldésre találták ki az invariant culture-t (CultureInfo.InvariantCulture), azaz ha valamiért stringként küldesz át nem-string adatot, használd azt a formázáshoz és parse-oláshoz is.
-
Karma
félisten
-
Karma
félisten
válasz
Jester01
#4740
üzenetére
Ilyet éltem már én is; ettől függetlenül szerintem megvan a maga megérdemelt helye az eszköztárban, mert az se ritka, hogy valami regexben kapásból olvasható, száz-ezer sor imperatív kódban meg nem.
(#4742) peter9228: A 48 valójában a '0' karakter ASCII kódja, a Convert.ToInt32 meg teszi a dolgát, és a karakterből ezt állítja elő a char típusból. Használj valami mást a számmá konvertáláshoz, vagy mondjuk használd ki, hogy az ASCII kódból egy egyszerű kivonással (48) megkapod a számjegy értékét.
Amúgy meg StreamReadert csak és kizárólag using blokkal együtt használj, plz!
-
Karma
félisten
válasz
Jester01
#4734
üzenetére
Milyen más módon mennél neki a regexen kívül?
Önerőből lehet, hogy én egy korutint írnék rá ami egyszer iterál végig a stringen, figyeli a relációs jeleket, és azok alapján adja vissza a substringeket. De egy kicsit merengve rajta az ehhez kellő állapotgép ekvivalens egy egyszerű regexszel.
-
#4726
Karma
félisten
trisztan94
#4722
Karma
félisten
válasz
trisztan94
#4722
üzenetére
Hogy van az, hogy le tudod kérni a pozíciót a térképen mozgáshoz az UpdateMap metódus közepén, de pont ugyanazt a kódot nem tudod átemelni a POI létrehozásához?
Mert ugyanazt kell csinálni hozzá, nem is értem hol a gond..."A geolocator aszinkron szerzi meg a pozíciót, ezért be kell rakni az "async" modifiert a metódusba, ami viszont csak void return értéket enged, tehát nem adja vissza a pozíciót."
Ebből a mondatból viszont csak a legelső tagmondat igaz, a többi mind tévedés.
1) Attól, hogy valami aszinkron, még nem kötelező se az async, se az await kulcsszavak használata. A visszatérési érték Task<GeoPosition> típusú, aminek például használhatod a ContinueWith metódusát arra, hogy mi történjen a háttérfolyamat befejeződésekor, nincs kötelezően szükség az awaitre. Csak épp megéri használni, mert garantáltan visszajön a hívószálra és könnyebben olvasható.
2) Az aszinkron metódusok háromféle visszatérési értékkel rendelkezhetnek: Task, Task<T> vagy void. A GeoLocator a másodikra példa. Void visszatérési értéket csak UI eseménykezelők esetében célszerű írni.
3) Dehogynem. -
Karma
félisten
válasz
Bobrooney
#4720
üzenetére
Nekem mondjuk az se jött át, hogy most egy Windows Forms alkalmazásról van szó, vagy WPF-ről, vagy ASP-ről, vagy... Enélkül duplán nehéz bármit mondani.
De nagy általánosságban úgy tudod elkerülni a validáció ismételgetését, hogy nem a view osztályodban definiálod ezeket, hanem a model (vagy viewmodel) rétegben. Így minden hozzájuk kapcsolódó form egy helyről fogja tudni a szabályokat.
(Ez egyébként a Java frameworkökben is így szokás, amennyire láttam.)
-
#4683
Karma
félisten
trisztan94
#4682
Karma
félisten
válasz
trisztan94
#4682
üzenetére
Semennyire, és semennyire. Semmi közöd a többi alkalmazáshoz.
-
Karma
félisten
válasz
zsambek
#4641
üzenetére
Igen, a " " a string, a ' ' meg egyetlen karakter konstans jele.
Csinálhattad volna úgy is, hogy char változóba rakod az indulást. Viszont akkor meg arra kell figyelned, hogy a split metódus stringeket ad vissza, neked meg csak az első karaktere kell.
Int esetén nem kell (nem is szabad!) semmilyen idézőjel a szám köré.
-
Karma
félisten
válasz
zsambek
#4638
üzenetére
Ömm, ez a részlet annyit csinál, hogy beolvas egy számot konzolról, és kiírja az annyiadik elemet. Mindezt a beolvasás sorrendjében, nullától számolva. Keresés nem nagyon van benne.
Mondjuk ha a honnan még mindig egy string[], azaz úgy van ahogy tegnap másoltad, akkor a kód le se fordul, mert stringet akarsz charhoz hasonlítani. Aposztróf ( ' ) helyett használj idézőjelet ( " ) a string konstansokhoz.
-
Karma
félisten
válasz
zsambek
#4626
üzenetére
Na, csak írtam valamit így feladat nélkül.
A hibakezelést én se erőltettem túlEz pl. egy olyan változat, amit érettségin is simán elhisznek az embernek. A korábbi mondandóm lényege a TimesheetRow osztály, amit fenn definiáltam, benne propertykkel az egyes mezőkhöz.
A Main metódust nagyon nem akarom túlragozni, mert szerintem a C# elég jól olvasható akkor is, ha angol mondatokként tekintesz rá. Tömören csinálok egy üres listát (amibe TimesheetRow elemeket lehet rakni), majd feltöltöm elemekkel ahogy kipotyognak a sorok.
A humor kedvéért ebből a listából kiválasztom az öt leghosszabb távolsággal rendelkezőt (csökkenő sorrendben), majd kiíratom őket kézzel.
Mindenképpen próbáld meg a logikát mögötte megérteni, ne a sorokat bemagolni, mert csak úgy van értelme az egész történetnek. Kérdezz bátran.
Meg megírtam korutinnal is, mert jobban szeretem.
-
Karma
félisten
válasz
Jester01
#4624
üzenetére
Szerintem helyzetfüggő, lehet hogy ilyen esetben a fél eredmény a cél.
Mondjuk a hibakezelés egyik esetben se merülne ki ennyiben. Azért kár try-catchbe tenni, hogy utána szó nélkül lenyelje a kivételt; mint ahogy ha esetleg nem találkozott a TryParse-szal, minden egyes hívást külön try blokkba rakjon. Az előbbire tömegesen, de azért az utóbbira is láttam már példát.
-
Karma
félisten
válasz
zsambek
#4621
üzenetére
Az előbb említett szerzőt én is javaslom
Egyébként a kódod legnagyobb problémája az, hogy nem C#, csak szintaktikailag.
Logikailag inkább C-re vagy Pascalra emlékeztet, gyanítom ugyanaz az eset, mint amikor az orosztanárokból faragtak angoltanárokat nagyon gyorsan...Pár apróság, ami már most is megkönnyítheti az életedet:
1) A különálló tömbök helyett definiálj egy új osztályt, ami összefogja az adattagokat. Így egy sor egy objektum lesz, amit könnyen tudsz egy Listben tárolni és kezelni.
2) Fájlt, vagy bármilyen más lezárható erőforrást nem szabad így a levegőben lógva kezelni. Ha például a fájlban az egyik int hibás, a keletkező Exceptiontől úgy pukkan ki a kódod, hogy a fájl meg nyitva marad. Ez jobb helyeken halálfejes hiba - azaz azonnal bukod a vizsgát és próbálhatod újra legközelebb.
Ehelyett használd a using szerkezetet, ami garantálja, hogy a blokk végén a fájl (vagy bármilyen más, IDisposable erőforrás) lezáródik, ha hiba van, ha rendben futott minden. Itt láthatsz is egy példát, hogy hogy kellett volna kinéznie. Szokj rá.
3) Az int.Parse(string val) robban, ha nem számot talál. Ehelyett szerencsésebb az int.TryParse(string val, out int result) metódust használni, ami simán egy hamis bool értéket ad vissza a kivétel helyett.
-
Karma
félisten
válasz
sztanozs
#4606
üzenetére
Sztornó, újraolvastam az eredeti kérdést...
Nem vagyok benne biztos, hogy ez a struktúra leírható reguláris kifejezéssel (a matematikai hátterét régen tanították egyetemen és nem emlékszem, de nagyon erős a gyanúm). Szerintem nem úszod meg, hogy legalább egy SAX-hoz hasonló streaming parsert írjál a formátumhoz.
Egyébként valós példatöredék jó lenne, hogy lássuk mi is, ezek a belső blokkok hogyan jelennek meg. Két normál szövegrész között is például?
De lehet inkább beadom a derekam és bevillantom a szebb világ képét.
ame-et!).
Szoktam látni a hétköznapokban is durva kókány munkát, de ez simán dobogós lehetne.
Ez elég veszélyes és értelmetlen művelet...
Ú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!
- Gyúrósok ide!
- Okosóra és okoskiegészítő topik
- Meghalt a Windows 10, éljen a Windows 10!
- Víz- gáz- és fűtésszerelés
- Proxmox VE
- Brogyi: CTEK akkumulátor töltő és másolatai
- A világűrbe repíti az AI-t az NVIDIA és a Starcloud
- Luck Dragon: Asszociációs játék. :)
- Óra topik
- Lakáshitel, lakásvásárlás
- További aktív témák...
- Samsung Galaxy S23 Ultra 12/512GB, Normál, Kártyafüggetlen, Töltővel, Dobozzal, 1 Év Garanciával!
- Akcióban! Sencor SSS 6300 NYX 2 - Új, bontatlan + 2 év garancia!
- Csere-Beszámítás! Gamer Notebook! MSI Thin 15 B12UC! I5 12450H / RTX 3050 / 16GB DDR4 / 512GB SSD!
- Precision 7560 27% 15.6" FHD IPS i7-11850H RTX A3000 32GB 1TB NVMe magyar vbill gar
- ASUS RTX 5090 32GB GDDR7 ROG ASTRAL OC - Új, Bontatlan, 3 év garancia - Eladó!
- Tablet felvásárlás!! Samsung Galaxy Tab A8, Samsung Galaxy Tab A9, Samsung Galaxy Tab S6 Lite
- BESZÁMÍTÁS! Asus X370 R5 2600 8GB DDR4 250GB SSD 1TB HDD GTX 1650 4GB Zalman T7 Chieftec 400W
- Corsair K70 RGB TKL // EU // Számla + Garancia //
- Apple iPhone 12 64GB / Kártyafüggetlen / 12Hó Garancia / 100% akku
- HIBÁTLAN iPhone 15 Pro 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3503
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest