- Samsung Galaxy A56 - megbízható középszerűség
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- One mobilszolgáltatások
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
- VoLTE/VoWiFi
- Mobil flották
- Xiaomi 15 - kicsi telefon nagy energiával
- Google Pixel 8a - kis telefon kis késéssel
- Samsung Galaxy S25 - végre van kicsi!
- Milyen okostelefont vegyek?
Új hozzászólás Aktív témák
-
togvau
senior tag
Gondoltam, de így is átment más szálakra aminek kell, csak azt én kezeltem mi, hogyan megy át. De ez más nyelvekben is meg van oldva, ilyen async kényszerítés nélkül.
Csak azt nem értem, hogy miért vannak ilyen hibás, nem ajánlott dolgok a rendszerben, mert nem csak a webclient ilyen, más hasonlókról is hallottam. És még csak nem is deprecated-ek. -
togvau
senior tag
-
togvau
senior tag
Na úgy tűnik megvan az async vírus továbbterjedését megakadályozó ellenszer XD
Task.Run(() => asyncFertőzőDolog(paraméter)).Result;
, így a várakozás is megvan. -
togvau
senior tag
Úgy néz ki most működik úgy, hogy ugyan azt a httpclientet használja.
Csak mivel kikényszerítette, hogy a paralel foreach is async legyen, a kész üzenet rögtön megjelenik, mivel nem várja meg.
próbáltam azt hogy a paralel foreach visszatérő izéjével (Parallelloopresult, hogy.
while (!paraloop.IsCompleted)
{
Thread.Sleep(500);
}De nem nyert így se, meg !-nélkül sem. Miért nem lehet ezt az async láncot egyszerűen megszüntetni, főleg ha nincs is szükségem rá?
-
togvau
senior tag
válasz
Peter Kiss #8354 üzenetére
Nincs rosszul szervezve, javaban teljesen jó.
Akar a halál asyncolni, elég a paralel is, csak hát a httpclient asyncot követel, a webclient meg nem követel, de az sem működik.Semmi bonyolult nincs benne. Generál egy letöltenő fájllistát, azokat a fájlokat meg le kell töltenie, és kicsomagolnia, minden darabot sajat szálon, mert ugye nincs közük egymáshoz.
Javaban ezt az egész listát egy foreach bedobálja egy fixedthreadpoolba, és megcsinálja. Itt a threadpoolba dobálás mivel nincs ilyen, egy paralel foreachel lett helyettesítve.Ott a lényegi rész, nincs disposeolva
-
togvau
senior tag
Amúgy akkor kódok.
Ez hívja:
Parallel.ForEach(filelist, para, async file =>
{
string downfileeee = await downloadZipAsync(file[0]);
UnzipFromFile(downfileeee, destination, file[1]);
counter++;
Application.Current.Dispatcher.Invoke(() =>Installer.MainWindow.thiswindow.downbutton.Content = "Downloaded " + counter + " of " + filelist.Count + " files");
});Ezt:
private static async Task<string> downloadZipAsync(string down)
{
string tempfile = Path.GetTempFileName();
using (var client = new HttpClient())
{
if (DEBUG) Console.WriteLine("starting download: " + down);
var fileStream = File.Create(tempfile);
Stream x= await client.GetStreamAsync(down);
x.CopyTo(fileStream);
fileStream.Close();
// wc.DownloadFile(down, tempfile);
// wc.Dispose();
}
if (DEBUG) Console.WriteLine("finished download: " + down);
return tempfile;
} -
togvau
senior tag
válasz
martonx #8347 üzenetére
webclientet se kell, de lehet. Ahogy a httpclientet is. Net Core-ban lehet nincsenek ezek a bugok? Amúgy melyik települ fel a windóz 10-el? nem a sima .net framework? Akkor a júzereknek úgy is az lesz fent... és ennek a konverziónak az a lényege, hogy ne kelljen JRE-t telepíteniük, meg mást sem. Na meg a .net programot talán nem vírusnak ismeri fel a vindóz defender...
Amúgy hihetetlen, de a HTTPclient nem kb 250. fájlnál dobja azt az exceptiont, hanem pontosan 250-nél... Teljesen mindegy hogy melyik fájl az, ha 250-et letölt, elhasal.
-
togvau
senior tag
válasz
sztanozs #8349 üzenetére
egy bugos dologról, egy még bugosabb dologra nem.
Ennél ez van, mindig kb a 250. fájl körül, +/-10:
Exception thrown: 'System.Net.Sockets.SocketException' in System.dll
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respondÉéérdekes módon webclientnél nem ez a hiba van, amúgy is 500. környékén szokott lenni, na meg persze Java-nál sehol sincs hiba. Mindig ugyan az a szerver, ugyan azokkal a fájlokkal.
-
togvau
senior tag
WebClient wc= new WebClient();
wc.Dispose(); -nál timeoutol. De néha a downloadfile-nál is.
Miért? kb 550 fájl külön külön letöltése, összesen kb 500 mega méretben.
Ugyan ennek a programnak a Java változatánál nincs ilyen gond, (mellesleg sokszor gyorsabb is, 15 másodperc vs ~2 perc, pedig a .net-es változatban 8 letöltési szálra van korlátozva, de java-ban is csak 10)
-
togvau
senior tag
Milyen ingyenes egyszerű obfuscator akánlott? Lehetőleg mindenféle sallang, pl telepítés nélkül
Mert elég beszédes a fordított kód...
-
togvau
senior tag
válasz
martonx #8328 üzenetére
Ja, végül is, amikor egy opensource játékba C# kódoltam ilyesmi problémák nem voltak
Viszont van a kódomban egy valami, egy sima letöltés számláló amihez csak annyi kell, hogy behív a weboldalra, mintha egy böngésző címsorába beírnék valamit.
WebRequest.Create("http://valami.valahol.hu/akármi/index.php?letoltoazon=kod");
Ez tavaly működött, de most nem. De ugyan ezt a stringet böngésző címsorban ellőve, megjelenik a számláló adatbázisban.
De a c# programból nem. Nincs exception, és ráfut a sorra.
Szerk: megvan, kellett egy GetResponse() rá, különben nem csinálja a dolgot.
-
togvau
senior tag
Háttt ez... FURA
insta.email = gemail.Text;
insta.pass = gepassword.Password;
insta.dest = destination;
insta.choicess = choice.SelectedItems;
await Task.Run(() => insta.LetsDoThis());Így működik. Tehát nem lehet a task runnál paraméter, mert ha van, akkor a szokásos exception. Ha nincs, működik.
De akkor miért nem azért sír?
-
togvau
senior tag
válasz
Szabesz #8323 üzenetére
Ahogy vártam, ugyan az a hiba, így is:
await Task.Run(() => { new InstLogic().LetsDoThis(gemail.Text, gepassword.Password, destination); }); és itt elszáll.
Mégsem hívódik meg 2x, csak 1x. Beraktam egy >= hit countos breakpointot, és nincs kettő.
Tehát ha nincs invoke, akkor a háttérlogika abban a sorában száll el, ahova kéne. Ha van mindenhol, akkor meg már a task.run-nál elszáll, méghozzá akkor, amikor a háttérlogika konstruktora lefutott (amiben speciel nincs semmi).
Tehát nem csinál semmit, és elszáll az exceptionnal a háttérlogika osztály példányosításakor. Ezt is a konstruktorban elhelyezett breakpointtal néztem. Tehát vége a konstruktornak, F10 tovább lépés, a Task.Run-nál exception.
Na ilyet még nem láttam semmilyen nyelvben.Ha ehelyett new InstLogic().LetsDoThis(gemail.Text, gepassword.Password,destination); van, működik. Csak nem frissül a gui.
-
togvau
senior tag
válasz
Szabesz #8321 üzenetére
Azt írja ki, amit bemásoltam. Semmi többet.
Van egy rakás "megoldás", csak egyik sem működik. A linkelt megoldásban például az nem, hogy a this.-nek nincs Dispatcher-e.
A legközelebbi ez volt amit kitaláltam, így pl a buttonclick-ben a Task.Run MÁSODSZORI meghívásánál hasal el:
MainWindow.thiswindow.Dispatcher.Invoke(() => { Installer.MainWindow.thiswindow.choice.Items.RemoveAt(0); });
Csak kérdés, hogy 1 klikkre, ki hívja meg másodszor a buttonclicket, és ezt:
await Task.Run(() => { new InstLogic().LetsDoThis(gemail.Text, gepassword.Password, destination); });
Szóval sok mindent próbáltam, és ha nem az invoke-nál hasal el, akkor a rejtélyes másodszori Task.Run-nál hasal el. De a fura, hogy ha csak simán new-el ugyan abban a threadben indítom, akkor csak 1x fut le a buttonclick, és csak egyszer indul.
(Pedig de egyszerű volt magát a háttérlogikát asyncesíteni... bár bonyolultabb mint Java-ban, de nem vészes. Külön-külön max 8 szálakon tölt fájlokat, ellenőriz hashkódot, kicsomagol, stb...)
-
togvau
senior tag
a vicc az, hogy az egészet meghívó metódusban történik ez, mivel a button click meghívja egyszer a taskot, majd még egyszer, ki tudja miért...
-
togvau
senior tag
hello
Van egy háttérlogikás osztályom (kisebb módosításokkal egy javas dolog át C#-sítva). amihez van GUI, és a MainWindow.xaml.cs-ben pedig egy button clicknél egy ilyen:
if (gemail.Text != null && gepassword.Password != null && gemail.Text.Length > 4 && gepassword.Password.Length > 10)
{
///*Task.Run(() =>*/ insta.LetsDoThis(gemail.Text, gepassword.Password,destination)/*)*/;
new InstLogic().LetsDoThis(gemail.Text, gepassword.Password,destination);
}Így működik, csak ugye a háttérlogika blokkolja a GUI-t amíg nem végez, én meg szeretném hogy legyen valami visszajelzés hol tart.
De ha a new-es sort kommentelem ki, és Task.Run-al futtatom, akkorException thrown: 'System.InvalidOperationException' in WindowsBase.dll
The calling thread cannot access this object because a different thread owns it.A lényeg az lenne, hogy a háttérlogika "írhasson" a gui-nak, frissítgessen feliratokat, aszerint ahogy halad.
-
togvau
senior tag
Hello
Még mindig egy WPF gui-ban szeretnék egy progress bar szerűséget csinálni, és a GUI/xaml osztály egy másik osztály metódusát hívja meg, amin belül Parallel.ForEach-ben megy a lényeg, de ha onnan akarom frissíteni a GUI egyik komponensének értékét akkor persze
The calling thread cannot access this object because a different thread owns it.
Installer.MainWindow.thiswindow.downbutton.Dispatcher.Invoke(() =>Installer.MainWindow.thiswindow.downbutton.Content = "Downloaded " + counter + " of " + fileset.Count + " files");
Ez pedig ha bent van a foreachben belassítja az műveleteket, és ha kész van, nem lép ki a foreachből soha, mellesleg nem is változtatja a contentet.
Hogy lehet működőre megcsinálni?
Mellesleg hogy lehet a gazda GUI példányt lekérdezni? Mert a thiswindow változót a gui adja meg paraméterként az osztály létrehozásakor, ami gáz megoldás.
-
togvau
senior tag
Dispatcherezés megvan, csak az nincs, hogy hogy indítsak a gui Button_Click-jéből GUI-t nem blokkoló feladatot (a fő metódust ami végez mindent, letöltést, stb) Task.Run-al "The calling thread cannot access this object because a different thread owns it.", new Thread(() => -al egyszer sikerült, másodszor már ugyan azt a hibát dobálja...
Ja és ráadásul ezt az osztályt a GUI konstruktora példányosítja, szóval nem tudom hogy lehet másik thread a gazdája...
-
togvau
senior tag
Najó, a háttér kód már nagyjából jó, bár még mindig malmozik néha letöltéskor, de nem sokat, elmegy, úgy is a javas változat marad az elsődleges, a netes a finnyásoknak lesz akik nem akarnak JRE-t telepíteni.
Most a GUI-t kéne informatívabbá tenni, valahogy úgy hogy a parallel.foreach dolgozik a letölteni valókon, és ebből valami info kéne a GUI-ra, hogy ennyiből ennyi fájl letöltődött.
A parallel.foreach-be nem tudok a GUI-n lévő dolgon módosítani, mert "InvalidOperationException: 'The calling thread cannot access this object because a different thread owns it.'".Na meg az onclick által meghívott háttérlogika metódus blokkolja a GUI-t amíg az be nem fejezi... most egy threadben futassam a metódust hogy ne blokkolja?
-
togvau
senior tag
válasz
Froclee #7816 üzenetére
getter setter pont jó javaban, mert jól szabályozható a láthatósága (pl csak protectedbe hagyom a setelést, de a getelést publicban is), és nem olyan fura egyedi szintaxis mint a C#-ben a get; set; amihez hasonló szerkezet abban sem nagyon van máshol. Van más amiben tényleg kicsit jobb a C# ami most nem jut eszembe, de az sem olyan nagyon hűha könnyebbség, csak simán "jópofa".
Miért kéne awaitelni a kicsomagolást? Ha az megtörténik, akkor már a fájl felejthető a programnak, mert már nem tesz semmit a végeredménnyel.
@#7815: nincs hibás zip, se 0 byteos.
Mit kéne lezárni? Csak webclient downloadfile és a client.GetStreamAsync(fileUrl).Result; nyit kapcsolatokat. Semmi más. -
togvau
senior tag
válasz
Szabesz #7812 üzenetére
private static Stream ConvertToStream(string fileUrl)
{
try
{
if (DEBUG) Console.WriteLine("ConvertToStream: "+fileUrl);
return client.GetStreamAsync(fileUrl).Result;
}
catch (Exception ex) {
if (DEBUG) Console.WriteLine("down error: " + fileUrl);
throw ex;
}
}
client pedigprivate static readonly HttpClient client=new HttpClient();
async awaitet nem akarnék használni, örülök, ha a lehető leggyorsabban rövidre zárom, és nem kell asyncesíteni még a GUI-t is
Nem olyan nagyon új a C#, csak ez a nem túl jól működő letöltés dolog az új, meg ez a nagyon fura szálkezelés. Mint írtam java-ban, ott a threadpool, oda bepakolom a szálakat, aztán annyi, vagy ha nem akarom korlátozni a számukat simán thread.Run(), és az URL.openStream() mindenhogy működik, 1 szálon, és akárhányon is, teljesen párhuzamosan, sallang nélkül. Itt nem igazán akart, itt javasolta a valaki, hogy inkább a HttpClient-et használjam.
Mint látható a kódból, egyszerre csak 1 fájlt tölt le, ami elvileg egyszerre 1 kérés. Vagy nem?
#7813: nem minden esetben, de az esetek nagy részében igen, jobb a java. De ez nem meglepő, hiszen az egyik microsoft eredetű, a másik meg nem
-
togvau
senior tag
Addott ez a kód:
HashSet<string[]> fileset = checkFiles(mainhashlink, destination);
foreach ( ChoiceBean emt in Installer.MainWindow.thiswindow.choice.SelectedItems)
{
fileset.UnionWith(checkFiles(emt.url, destination));
}
if (DEBUG) Console.WriteLine("fileset count: " + fileset.Count);
foreach (string[] file in fileset)
{
if (DEBUG) System.Console.WriteLine("file: " + file[0]);
string downfileeee= downloadZip(file[0]);
Task.Factory.StartNew(() => UnzipFromFile(downfileeee, destination, file[1]));
}És itt a használt downloadZip()
private static string downloadZip(string down)
{
if (DEBUG) System.Console.WriteLine("starting download: "+down);
string tempfile = Path.GetTempFileName();
/*var fs = new FileStream(tempfile, FileMode.Open, FileAccess.Write);
ConvertToStream(down).CopyTo(fs);
fs.Close();*/
new WebClient().DownloadFile(down, tempfile);
if (DEBUG) System.Console.WriteLine("finished download: " + down);
return tempfile;
}Ott van kikommentblokkozva milyen volt előtte (ConvertToStream egyszerűen egy HttpClient-en átmenő streamet ad vissza).
Szóval converttostreammel (httpclient) iszonyú lassú volt, néha sok másodpercig állt néhány kbites letöltéssel, aztán 30 mbit, majd megint állás, és így tovább. Webclientre átrakva kevesebb az üresjárat, de az is malmozik sokat. Ez miért van?
(Java alapon hasonló kód ami ugyanezeket tölti, pedig kitolja maxra a 30mbitet, folyamatosan, bár ott több szálon megy a letöltés is, nem csak a kicsomagolás, ami itt nem megy.)
-
togvau
senior tag
Van ez a konstruktor kód:
public TxtLogger(string file) : base(new FileStream(file, FileMode.Append))
{
this.file = file;
}És itt az kéne, hogy meghívott paramétert manipuláljam (bemeneti fájlnevet kicsit megváltoztatni, ÉS ez után legyen vele meghívva az ősosztály konstruktora. Ilyet hogy lehet?
-
togvau
senior tag
válasz
sztanozs #7779 üzenetére
Ez sem nyert. Az nyert félig-meddig, hogy szétválasztottam a dolgokat, és a letöltés a soros terv szerint megy
Míg a kicsomagolás, vízjelezés parallel foreachben. Most megpróbálom valami taskban kicsomagolni, hogy minden egyes fáljt amit letöltött rögtön kezdjen kicsomagolni, ne csak akkor amikor már minden letöltődött.
De egyszerű volt ez java-ban, hogy egyszerűen csak bedobtam a threadpoolba... -
togvau
senior tag
Na kipróbáltam a Httpclientesítést .Result-os rövidre zárással. Ugyan az a jelenség mint a webclientnél... csak most már "System.Net.WebException: The request was aborted: The request was canceled."
-
togvau
senior tag
válasz
Froclee #7773 üzenetére
kb 3 viszont mert a C#-nál nem lehet normális változót visszahozni több szálon, ezért pontosan ugyanarra a feladatra 2 csak kicsiben különböző függvény kell? (egy normális streamet visszaadó, és egy kötelezően task<streamet> visszaadó a párhuzamosított részhez)
A GUI függvényeiig elvitt asyncolgatásnál nem fogja azt is kérni, hogy a gui osztály is legyen async, meg a wpf-et is írjam át asynccé? -
togvau
senior tag
válasz
Froclee #7766 üzenetére
wpf
meló, egy java-ban írt telepítőt akarok átírni c#-ra, mivel az m$ sikeres a java FUD-ban.
Letölt aes128+gzipelt adatfájlt, néz stimmelő felhasználónevet jelszót benne (amit wpf felületen kell megadni), és azonosítókkal tér vissza, majd az adatfájlban található url-ről hash listát letölt, és csekkolja a kijelölt mappában hogy stimmelnek-e a listában lévők a lemezen lévőkkel, ha nem akkor bekerülnek a fájlok a letöltendő listába, és a listán lévő fájlokat letölti (1 fájl/zip szintén kódolva), kicsomagolja, eközben vízjelet helyez el benne.
És ennyi.
Java-ban viszonylag sima ügy volt. Itt is végül is működik, csak a több szálú letöltés/kicsomagolás nem működik rendesen. És ha asyncet használok egy metódusban, akkor az azt meghívónak is asyncnak kell lennie, és az azt meghívónak is, és így tovább... -
togvau
senior tag
válasz
martonx #7764 üzenetére
És mit csináljak ezekkel a taskokkal? Hogy lehet a Task<Stream>-et sima streammé vagy bármilyen más normális változóvá alakítani, úgy hogy normális visszatérési értéke legyen a függvénynek, és csak async taskok a legfelsőbb szintig? (azért fura, hogy java-ban egy szimpla url.openStream()-al el volt intézve az egész, még párhuzamosítva is).
-
togvau
senior tag
válasz
martonx #7760 üzenetére
Ha nem csinálok mindig újat, csak 1 darab van, akkor: "WebClient does not support concurrent I/O operations"
Másrészt ott nem csak letöltés van mint látható, hanem kicsomagolás, lemezre írás, fájlokban pár byte cseréje. Ezért van párhuzamosítva, de a letöltésnek is néha jót tesz, gondolj csak a több szálon letöltést tudó letöltőprogramokra.
-
togvau
senior tag
-
togvau
senior tag
Ha várok 1 percet, akkor dob egy webexception "The operation has timed out"-ot a
private static Stream ConvertToStream(string fileUrl)
{
try
{
if (DEBUG) Console.WriteLine("ConvertToStream: "+fileUrl);
return new WebClient().OpenRead(fileUrl);
}
catch (Exception ex) {
throw ex;
}
}
És így kiderül melyik fájlnál akad el, de a probléma az, hogy a dobott linket böngészőbe írva, simán letöltődik a fájl, és pont ugyanonnan hasonló fájlok (még nagyobbak) letöltése is simán megy a C# programból is. Gyak 21 fájlt kéne letöltenie, és a 19.-nél akad el. Ha nincs párhuzamosság, akkor végigmegy. -
togvau
senior tag
válasz
sztanozs #7755 üzenetére
Parallel.ForEach(alista, paraoptions, file =>
{
try
{
if (DEBUG) System.Console.WriteLine("file: " + file[0]);
string filee = downloadZip(file[0]);
UnzipFromFile(filee,destination,file[1]);
File.Delete(filee);
}
catch (Exception ex)
{
if (DEBUG) System.Console.WriteLine(file[0]+" "+file[1]+" Stack:"+ex.StackTrace);
Environment.Exit(0);
return;
}
}); -
togvau
senior tag
válasz
sztanozs #7747 üzenetére
Van bizony! Sőt az a kezeletlen exceptionöket stacktrace-el amúgy is kidobja az outputra alapon, nem kell mindent try catchelni azért is hogy kíírja, vagy nem kell pipálgatni hogy mivel kapcsolatos exceptionoket dobjon
#7748 Az tökjó, ha már megvan hogy kb hol a hiba... akkor
De ez már régi. Az új az, hogy egy Parallel.ForEach ciklus érdekesen viselkedik. Ha MaxDegreeOfParallelism = 1 akkor minden jó. Ha >1 akkor is megcsinál mindent, de soha nem hagyja el a blokkot, egyszerűen megáll, és így nincs továbblépés, se exception, semmi.
-
togvau
senior tag
válasz
lord.lakli #7740 üzenetére
Nem ez az én fejlesztőeszközöm bizony, a microsoft dzsunka hulladék szoftvereit mindig kerülöm ha lehet. De itt van más? Persze lehet, hogy a microsoft színvonalhoz szokva nem olyan gagyi az, hogy még az outputra sem tud normálisan szöveget kiírni
#7742: nem, tényleg nem kattintottam exception ablakra, mert még soha nem láttam olyat. Csak az outputra ír ki sima szövegeket, oda is csak akkor hasznosat, ha catch-ben van egy Console.WriteLine(ex.StackTrace) Hogy lehet előhozni? Miért ne fikázhatnám? Ha több szöveg kiírás összekeveredik az outputon az hiba, nem is kicsi. Ilyet más IDE-ben még nem láttam.
-
togvau
senior tag
Hogy tudja? Én csak olyat várok, amit az eclipse tudott 10 éve, ahol nyomok egy ctrl-space-t és felkínálja a lehetőségeket. Itt hol válasszam ki? Fel sem kínál semmit. Usingot magától csak a projekt létrehozásakor szúr be. Utána soha nem láttam ilyet.
Mutatok majd példát ha újra találkozok a semmitmondó hibaüzenettel, de annyit csinál, hogy aláhúzza a metódus hívását, és kb annyit ír, hogy VALAMELYIK paraméter nem megfelelő... de hogy miért, és melyik az már nem.
1 third party dolog van a projektben, a sharpziplib. Ennyi. Minden más alap, default, szűz.
SQL szervert nem raktam fel, a VSE telepítője pakolt fel egy rakás fölösleget, de nem merem eltávolítani ismerve a microsoft cuccokat, hiszen akkor error hegyek várhatóak.
Most pl az a nagy gond, hogy jön egy exception, mert szegény C#/.net nem képes egy szerveren lévő http-n elérhető ANSI kódolású text file-t hibátlanul beolvasni, és olyan karaktert olvas egy sortöréssel együtt, ami nincs ott, de sajnos a forrását nem tudom megtalálni, mert a java/eclipse-el ellentétben a lekezeletlen exceptionoknál nem dob egy stacktrace-t minden szükséges infoval, hanem csak ennyit: "A first chance exception of type 'System.Net.WebException' occurred in System.dll"... jaaaaa bocs, nem olvassa azt, csak a hibaüzenetek és debugoláshoz hozzáadott a writelineok ÖSSZEKEVEREDNEK az outputon... tehát egy writeline első karaktere és második karaktere közé beékelődik egy exception hibazüzenet, amit ha nem látnék, nem hinnék el, de látom, több helyen is...
-
togvau
senior tag
érdekes, ctrl-space-re nem tudja megfelelő usingot beszúrni, nem tud normális hibaüzenetet sem megjeleníteni ha valamelyik paraméter rossz... csak pont annyit, hogy valamelyik paraméter rossz, szóval olyanok vannak elrejtve, amit az eclipse 2006-ban már rég tudott... Na meg néha újra kell indítani, mert beragad minden, semmit se csinál kiegészítésre, és a javított hibák aláhúzása is megmarad amíg újra nem indítom.
Újabbat meg nem merek tenni, mert van projekt ami még a 2013-ra van konfigolva, na meg a kéretlen dolgok amiket magával hoz (SQL szerverének a szerverének a szerverének a telepítőjének keretrendszerének a szervere), lehet lefoglalnák az SSD-n a 20 giga szabad helyet.Szóval az írt kód a generált MainWindow.xaml.cs-be került.
-
togvau
senior tag
válasz
BTminishop #7733 üzenetére
private void Button_Click(object sender, RoutedEventArgs e)
{
string destination = Registry.GetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Releaser\\Game", "InstallLocation", null) as string;
if (!File.Exists(destination+"\\app.exe")) {
destination = Registry.GetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Steam App", "InstallLocation", null) as string;
}
else if (!File.Exists(destination + "\\app.exe"))
{
FolderBrowserDialog fbdialog = new FolderBrowserDialog(this);
fbdialog.ShowNewFolderButton = false;
fbdialog.Description = "jelöljed ki a témát";
fbdialog.RootFolder = Environment.SpecialFolder.ProgramFilesX86;
if (fbdialog.ShowDialog() == System.Windows.Forms.DialogResult.OK && File.Exists(fbdialog.SelectedPath + "\\app.exe"))
{
destination = fbdialog.SelectedPath;
}
else
{
System.Windows.Forms.MessageBox.Show("exe not found in the selected directory","Problem",MessageBoxButtons.OK,MessageBoxIcon.Stop);
return;
}
}
System.Console.WriteLine(destination+Directory.Exists(destination));
if (gemail.Text != null || gepassword.Password != null || gemail.Text.Length > 4 || gepassword.Password.Length > 10)
{
//insta.LetsDoThis(gemail.Text, gepassword.Password,destination);
}
} -
togvau
senior tag
válasz
BTminishop #7731 üzenetére
Köszi, így már elfogadja. De még is milyen dialogresultot akart eddig használni? a .net libekben sportot űznek abból hogy pontosan ugyan azokat a neveket használják fel tök különböző dolgokra?
Viszont még így sem jelenik meg semmilyen mappaválaszó, szóval nem ez volt a hiánya. Úgy megy át azon a soron, mintha nem lenne ott semmi.
Van valami paramétere a showdialognak a gazdaablakra, de a this nem jó neki, -
togvau
senior tag
próbálkozom előhozni egy 0 kis mappaválasztó ablakot, de simán a .showDialog()-al nem jön elő semmi, csak továbblép, ezért if-be raknám result ellenőrzéssel, ahogy a példákban van
if (fbdialog.ShowDialog() == DialogResult.OK &&
de a DialogResult.OK-ot aláhúzza ez a notepadnál alig többet tudó VSE 2013."Error 2 'System.Nullable<bool>' does not contain a definition for 'OK' and no extension method 'OK' accepting a first argument of type 'System.Nullable<bool>' could be found (are you missing a using directive or an assembly reference)"
Mit kell tennem, hogy ne húzza alá?
(egyébként létezik valami normális ingyenes fejlesztőkörnyezet ami tud annyit mint egy Eclipse java-ban?)
-
togvau
senior tag
állítólag WPF grafikus felületre hogy lehet egy felugratni egy mappaválasztót?
-
togvau
senior tag
Az kellene nekem, hogy metódus fusson le sokféle paraméterrel, párhuzamosítva, de azért ne túl sok egyszerre, ugyan is a metódusok letöltenek, írnak a lemezre, és mind2 be tud lassulni ha túl sok szál próbálkozik vele.
Java-ban ezt úgy oldottam meg, hogy
ExecutorService pool = Executors.newFixedThreadPool(10);
, aminél a 10-es azt jelenti, hogy 10 szál futhat egyszerre, majdpool.submit(new DownloadTask(downloadlink));
-el megtöltöttem elvégzendő műveletekkel egy ciklusban, majd a cikluson kívülpool.shutdown();
-al lezártam és indítottam a feldolgozást, és apool.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
-al megvárta a fő szál míg mind elkészül.Ilyesmi kéne nekem c#-ban is, találtam ezt a Task.Factory.StartNew(() => csináljvalamit(paraméter)) dolgot, de ezt végül is hogy kell kezelni?
Hol a várakozás, hol van hogy mennyi futhat egyszerre?
-
togvau
senior tag
Hogyan lehet, egy VSE által generált projektnél a WPF felületen egy listboxot felölteni a logikát tartalmazó osztályból?
próbáltam úgy, hogy az egész project namespace.MainWindow.listboxneve de nem, nem kínálja fel, nem látható. Létrehoztam a MainWindow.xaml.cs-ben egy public metódust is aminek adva tölti a listet, de az sem elérhető... az egész "interaction logic" osztály nem elérhető, pedig public.
-
togvau
senior tag
Érdekes fejlemény, de ha átlépem a 00-kat readByte()-al, akkor beolvassa a stringet
Tehát így működik:
reader.ReadByte();
hashlink = reader.ReadString();
reader.ReadByte();
string mpass = reader.ReadString();
//soronként a fájl végéig˘˘
reader.ReadByte();
string user = reader.ReadString();
reader.ReadByte();
string pass = reader.ReadString();
reader.ReadByte();
string id1 = reader.ReadString();
reader.ReadByte();
string id2 = reader.ReadString();
bool notify = reader.ReadBoolean(); -
togvau
senior tag
Na sikerül dekódolni fejben, szóval. Minden string előtt van egy #00, és még egy hex szám ami a string hosszúságát jelöli (nem tudom, hogy byte e vagy karakter, de mivel nincsenek speciális karakterek ezért ebben az esetben a byte és karakterszám az ugyan az) , és ez után jön maga a string.
-
togvau
senior tag
válasz
sztanozs #7699 üzenetére
ANSI-t ír. De ez nem jelent semmit. Minden szerkesztőnél, szépen látszik az összes string, ANSI, és UTF-8 kódolásra állítva is. Még a hulladék windowsos sima notepadban is.
Az első string előtt van egy 00 31 hex és mintha mindegyik adat között lenne egy 00, de nem közvetlen az első string karakter előtt vagy a string után. -
togvau
senior tag
válasz
sztanozs #7695 üzenetére
köszi, sharpziplibel már simán megette (lehet nem véletlen, hogy szinte minden C# programnál ott figyel a sharpziplib dll), minden byte stimmel dekódolás, kicsomagolás után. De a Java-s stringet még mindig nem sikerült olvasni. Ha nyomok C# binaryreaderben egy readString()-et, akkor az eredmény semmi, még hibaüzenet sem. Ugyan ez readcharnál. Csak byteot olvasva jön ki értékelhető.
Java-ban writeUTF()-el van írva a fájlban, és persze readUTF()-el olvasható is.Olvastam róla hogy más az endianossága a c#-és a java-nak, de endianváltó libet is töltöttem, azzal se lehet byteon kívül mást olvasni, hogy legyen valami :\
-
togvau
senior tag
válasz
sztanozs #7693 üzenetére
Na most van valami siker, de már úgy megkavarodtam, hogy azt sem tudom hol vagyok. Szóval az egyik fő probléma az lehetett, hogy a java kódból másolt byte tömböt byte-ként deklaráltam és kezeltem, pedig a java byte-ja a C# sbyte-jának felel meg.
Na a lényeg, hogy ha kiíratom az első dekódolt 32 byteot javaban, és C#-ban, akkor stimmel mindegyik.De ezután kéne jönnie egy kicsomagolásnak Zlib alapon, ami nem megy, mert "An unhandled exception of type 'System.IO.InvalidDataException' occurred in System.dll
Additional information: The magic number in GZip header is not correct. Make sure you are passing in a GZip stream."Java-ban InflaterInputStream-en megy keresztül ami az Inflater() kicsomagolót használja, C#-nál a GZipStream-en menne át ha menne, mert elvileg a zlib, gzip, pkzip kompatibilis egymással.
A javas inflater dokumentációban viszont van egy ilyen: "If the parameter 'nowrap' is true then the ZLIB header and checksum fields will not be used. This provides compatibility with the compression format used by both GZIP and PKZIP. "Gondolom ezért C#-ban pár byteot ki kéne hagyni... de hol és mennyit...
Viszont van már DeflateStream is a .net-ben, ami full Zlib kompatibilis. Ez már más hibát ír ki "An unhandled exception of type 'System.IO.InvalidDataException' occurred in System.dll
Additional information: Block length does not match with its complement." akár akkor is ha egy ReadByte()-ot nyomok -
togvau
senior tag
válasz
sztanozs #7691 üzenetére
Megnéztem. Keysize-ok stimmelnek. De elkezdtem ellenőrizgetni a keyeket.
Amíg sima byte[]-ban van a key, addig stimmel a C#-os a Javassal, de miutánRijndael rijAlg = Rijndael.Create();
rijAlg.Key = Key;
majd egyforeach (var b in rijAlg.Key)
{
sb.Append(String.Format("{0:x2} ", b));
}
System.Console.WriteLine(sb.ToString());Itt már tökmás a végeredmény... Ez hogy lehet?
-
togvau
senior tag
válasz
sztanozs #7688 üzenetére
Valamennyire használható, de így sem dekódolja rendesen amit kéne.
Java-ban amiben működik a dekódolás ilyen a beállítása a dekódolónak:
AlgorithmParameterSpec paramSpec = new IvParameterSpec(iv);
try
{
PBEKey key = (PBEKey)
SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1").generateSecret(new PBEKeySpec(new
String(kulcsbytearr).toCharArray(), salt, 7, 128));
SecretKey encKey = new SecretKeySpec(key.getEncoded(), "AES");
dcipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
dcipher.init(Cipher.DECRYPT_MODE, encKey, paramSpec);C# nem tudom mi ennek a secretkeynek a megfelelője, szóval java-ból kihoztam a végső kulcsot az enckey-ből.
static Stream DecryptStream(Stream cipheredStream, byte[] Key, byte[] IV)
{
// Check arguments.
if (cipheredStream == null/* || cipherText.Length <= 0*/)
throw new ArgumentNullException("cipherText");
if (Key == null || Key.Length <= 0)
throw new ArgumentNullException("Key");
if (IV == null || IV.Length <= 0)
throw new ArgumentNullException("IV");
Rijndael rijAlg = Rijndael.Create();
rijAlg.Key = Key;
rijAlg.IV = IV;
rijAlg.Mode = CipherMode.CBC;
//rijAlg.Padding = PaddingMode.PKCS7;
rijAlg.KeySize = 128;
ICryptoTransform decryptor = rijAlg.CreateDecryptor(rijAlg.Key, rijAlg.IV);
return new CryptoStream(cipheredStream, decryptor, CryptoStreamMode.Read);
}De nem stimmel a dekódolt anyag. Ilyen PKCS5 nincs is a C#-ban, csak 7
-
togvau
senior tag
Kezdő C#-osként egy URL-ről streamként olvasott fájlt kéne dekódolnom, ami AES 128bit kódolású.
Eddig ennyi, oda a ConvertToStream köré kéne a dekódolás.
var reader = new BinaryReader(new GZipStream(ConvertToStream(DB), CompressionMode.Decompress));
Java-ban van olyan, hogy "CipherInputStream", és ott elég egyszerű. De itt hogy?
-
togvau
senior tag
Létezik C#-ban ilyen lokális de maradós változó(tuti van ennek valami szakszerű neve amit tudtam, de most nem jut eszembe)? Tehát olyan ami lokálisként van deklarálva, de ahol deklarálva van ott minden ciklusban elérhető marad, és az értékét is őrzi.
Tudom hogy ezt osztály változóval megcsinálhatom, de már úgy is annyi változója van, ráadásul ezt csak egy metóduson belül kell elérni, jobb lenne nem osztályváltozóként szemetelni.(egy játék update-jében futó metódusról van szó)
-
togvau
senior tag
válasz
sztanozs #7302 üzenetére
Ja behozza, miután a full kód be lett írva. Csak én ahhoz szoktam hozzá, hogy elkezdek írni egy osztálynevet, vagy metódust, és fel is dobja ctrl space-re a lehetőségeket, még azokat a csomagokat(namespaceket) is amik nincsenek még behúzva, és ha kiválasztom valamelyiket belövi azt is. Hát de ezek szerint a microsoftnak ez még túl űrtechnika...
-
togvau
senior tag
Udpclient receive-re mindenhol ipEndPointot írnak, de én ezt a visual studioba sehogy sem tudom aláhúzatlanná tenni...
new IPEndPoint alá van húzva, kiegészítés sincs, mintha egy ismeretlen dolog lenne.
Szóval hogy lehet működésre bírni?Az pedig tényleg komoly, hogy a VSE 2013 elkezdett kódra, és ctrl-space-re nem képes belőni a megfelelő
importotusingot magától?
Ú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!
- TCL LCD és LED TV-k
- Argos: Szeretem az ecetfát
- RAM topik
- Intel Core i3 / i5 / i7 / i9 10xxx "Comet Lake" és i3 / i5 / i7 / i9 11xxx "Rocket Lake" (LGA1200)
- sziku69: Fűzzük össze a szavakat :)
- Vicces képek
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kivégzi a Firewire-t az új macOS verzió?
- World of Tanks - MMO
- Kertészet, mezőgazdaság topik
- További aktív témák...
- Dell Latitude 7410 Strapabíró Ütésálló Profi Ultrabook 14" -80% i7-10610U 16/512 FHD
- Szép! HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 32/512 Iris Xe FHD Magyar
- HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -65% i7-1185G7 8/512 Iris Xe FHD Magyar
- 512 Gb-os NVME-k
- Eladó autós gyerekülések, Römer és Peg-Pérego márkák
- Csere-Beszámítás! Ryzen 9 9950X3D Processzor! 16Mag-32Szál!
- BESZÁMÍTÁS! ASRock FORMULA OC RX 6900XT 16GB videokártya garanciával hibátlan működéssel
- Beszámítás! Apple Mac Studio M2 MAX 2023 32GB 512GB SSD számítógép garanciával, hibátlan működéssel
- Bowers/Wilkins PX8 fejhallgatók (dupla Bluetooth eszköz csatlakoztatása!) - ELKELTEK
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest