Hirdetés
- Lassan állítjuk a fát, és a hardverek is be vannak csomagolva
- Klasszikus kínai festmények ihlették a Colorful legfrissebb memóriáinak külsejét
- Ultrakompakt Key E SSD-vel jelentkezett a Silicon Power
- Mesterséges intelligenciára kihegyezett mini PC jött az ASUS műhelyéből
- ASUS blog: ExpertBook P5 notebook, a munkagép
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- TCL LCD és LED TV-k
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Projektor topic
- Milyen TV-t vegyek?
- CPU léghűtés kibeszélő
- Azonnali processzoros kérdések órája
- Milyen belső merevlemezt vegyek?
- A Microsoft szerint nem alku tárgya a TPM 2.0 szükségessége
- Soundbar, soundplate, hangprojektor
Új hozzászólás Aktív témák
-
dqdb
nagyúr
válasz
Alexios
#10071
üzenetére
A hibaüzenet alapján az lesz a probléma, hogy nem inicializálja minden kódúton a változót, és használná. Az
int[,] palya = nullmegoldja a fordítási hibát, de az ellenőrzéseket persze bele kell tenni a kódba.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
Tomi_78
#10062
üzenetére
Nem kell itt próbálkozni, ott van a
Screen.PrimaryScreen.WorkingArea, azt kell beállítani az ablak pozíciójának, ha az első képernyőd akarod megjeleníteni, és ekkor a tálca nélküli teljes képernyőméretet kihasználod.A te megoldásod elvi szinten bukik el, mert az, hogy a tálca teteje, az esetek egy részében értelmezhető fogalom csak. A tálcát lehet balra, jobbra és felülre dokkolni, emellett el lehet rejteni automatikusan, több monitornál simán lehet, hogy csak az elsődleges monitoron van tálca, a többin nem, stb.
Screen.PrimaryScreen.WorkingArea.Height-(Screen.PrimaryScreen.WorkingArea.Height-ClientSize.Height)
Egyszerűsítsük kicsit a képletet:Screen.PrimaryScreen.WorkingArea.Height - (Screen.PrimaryScreen.WorkingArea.Height - ClientSize.Height) =Screen.PrimaryScreen.WorkingArea.Height - Screen.PrimaryScreen.WorkingArea.Height + ClientSize.Height =ClientSize.HeightEz csak abban az esetben adja meg a tálca tetejének helyét, ha
1. a Windowsban a tálca alulra van beállítva
2. az ablak maximalizálva van
3. az ablaknál aFormBorderStyle = FormBorderStyle.Nonevan beállítva és nincsen menü[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
Tomi_78
#10060
üzenetére
1. Miért 864 képpont nálam C#-ban a képernyőmagasság 1080 helyett?
Mert Windowsban 125%-ra állítottad a scalinget, az alkalmazásod pedig nem jelzi, hogy high DPI támogatással bír, így a Windows a tényleges helyett a scalinggel korrigált virtuális értéket adja át neked2. Hogyan kaphatom meg csak a hasznos területet a képernyőből, tehát a Tálca és a felső menüsor magassága nélküli értéket?
A felső menüsor, az ablakfejléc és a keret az alkalmazás saját felségterülete, azzal azt kezd, amit akar, azok az ablakméreten belül vannak. A tálca nélküli téglalapot aScreen.WorkingAreapropertyben találod.Egy ablak két része szedhető szét: client area, ami a hasznos felülete (a lenti képen pirossal jelezve) és a non-client area, ahová a körítés (fejléc, menü, keret) kerülnek. A hasznos területet a Control.ClientRectangle propertyvel tudod lekérdezni, ez azt a téglalapot adja vissza, ami az ablakod szabadon használható területe.
Érdemes megjegyezni, hogy több monitor esetében mind a DPI, mind a tálca mérete, mind a rendelkezésre álló terület eltérhet, és az alkalmazásodat monitorok között dobálva ez indítás után bármikor bekövetkezhet, szóval érdemes a változásokról érkező eseményeket lekezelni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
Szancsó
#10012
üzenetére
Úgy tűnik, mintha a magyarhoz tartozó comparer elfelejtett volna magyarul, vagy nem tudom.
Nem elfelejtett, hanem megtanult.Itt tudsz kísérletezni, kifejtés itt.
A betűrendbe sorolás
14. c) A magánhangzók rövid-hosszú párjait jelölő betűk (a – á, e – é, i – í, o – ó, ö – ő, u – ú, ü – ű) betűrendbe soroláskor a kialakult szokás szerint mind a szavak elején, mind pedig a szavak belsejében azonos értékűnek számítanak. A hosszú magánhangzót tartalmazó szó tehát meg is előzheti a megfelelő rövid magánhangzót tartalmazót, például:
ír Irán író
Irak írandó iroda
iram iránt iróniaA rövid magánhangzós szó kerül viszont előbbre olyankor, ha a két szó betűsora csak a megfelelő magánhangzók hosszúságában különbözik, például:
Eger kerek szel
egér kerék szél
egyfelé keres szeles
egyféle kérés széles
elöl (hol?) koros szüret
elől (honnan?) kóros szűrettAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
rgeorge
#9982
üzenetére
Az ilyet úgy érdemes megoldani, hogy az eredeti XML az alap, az új pedig XDT transzformációkat tartalmaz, azaz kap pár attribútumot, hogy mit kell adott node-dal kezdeni. Bár ez a leírás a web.config-ra vonatkozik, de jól bemutatja a XML módosítási lehetőségeket, a dokumentációját pedig itt találod. Ha pedig egy nem létező típusú transzformációra van szükséged, akkor azt könnyen bele tudod tenni.
Maga a C# kód alapesetben nagyon egyszerű, ezt saját loggerrel és saját transzformációkkal lehet elbonyolítani.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
A szolgáltatás a Windows\System32 mappában indul el. Teljes path-t használva naplózz egy olyan mappába, ahová mindenkinek van írási joga, vagy a fenti mappában keresd a fájlt (ha volt joga írni oda, ami attól függ, hogy melyik technikai felhasználó nevében futott).
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Ez elvileg kellene, hogy működjön. Gyakorlatilag láttam már olyat, hogy a .NET szolgáltatást a rendszer olyan lassan indítaná el, hogy az SCM kilövi azt még azelőtt, hogy egyáltalán elindulna (nem tudom az okát).
A Program.Main, Service.OnStart és Service.OnStop metódusokba tegyél fájlba naplózást, hogy látszódjon, egyáltalán eljut-e oda a vezérlés. Ha nem, akkor itt a workaroundnál látható módon a gyári 30000 ms-t tornázd fel magasabbra (nekünk volt, ahol elég volt 2 perc, volt, ahol 3 kellett).
És ahogyan a többiek is javasolták, használj LTS verziót, ami a 6.x.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
leslie23
#9792
üzenetére
A Fiddlerrel ha jól értem nekem kellene felépítenem a request XML-t.
Rosszul, ahogyan martonx is írta, a Fiddler csak egy proxy, amin keresztül bonyolítva a forgalmat lehet monitorozni a kéréseket és válaszokat. Opció lehet még a message logging és tracing bekapcsolása.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
leslie23
#9789
üzenetére
Tegyél be egy Fiddlert a webreference-et használó hívási láncba, és máris lesznek kérés-válasz példáid. A cím az ez, azaz az .asmx címe, az actionök azok namespace-ek/típusok, nem pedig konkrét címek.
Érdemes átfutni gyorsan a szabványt, hogy átlásd a séma felépítését.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
joysefke
#9730
üzenetére
Az "Add-Type" valami régi fordítót használ, régi C# verió támogatással és a hibaüzenetei borzalmasak.
A Roslyn előtt azt lehetett kihasználni, hogy a .NET Framework része a csc.exe. A futtatni kívánt snippetből generáltál egy teljes .cs fájlt, ahol a generált kódban #pragma line használatával el tudtad érni, hogy az eredeti fájl nevével és a megfelelő sorszámmal dobja a hibát a fordító, futtattad és parse-oltad az eredményt. Működött ugyan, de eléggé meh, a Roslyn ilyen téren megváltás volt a rugalmasságával.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
joysefke
#9726
üzenetére
Ha C# scriptelést szeretnél, akkor arra ott van a Roslyn, a .NET C#-ban írt C# fordítója, amelyet megfelelő objektummodellel ellátva be tudsz ágyazni saját projektekbe is.
Ez itt egy gyors bevezetés, ez pedig egy minimálisan mélyebb példa annak átlátására, hogy mit is lehet elérni Roslyn segítségével elérni.
Aztán hajrá a C# szintaktikájú saját DSL létrehozásához. Ha nem magadnak írod a cuccot, akkor szerintem érdemes a DSL-nek fluent felületet definiálni, az talán közelebb áll az átlagemberekhez.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Kiolvasod az első két byte-ot a streamről. Ha az
1f 8b, akkor gzip lesz a formátum.Mivel azt a két byte-ot egyszerűen nem tudod visszatenni a stream elejére, ezért ha memóriába belefér a tartalom, akkor létrehozol egy
MemoryStream-et, az elejére beírod a két byte-ot, a végére a stream többi tartalmát, és ezt az objektumot adod tovább aGZipStreampéldánynak vagy aStreamReader-nek.Ha szép megoldást szeretnél vagy a memóriafoglalás is számít, akkor egy olyan
Streamimplementációra lesz szükséged, ami alapvetően proxyként működik a paraméterként kapott streamre, csak éppen visszateszi az elejére azt a két byte-ot.A HTTP header felejtős, az minden esetben gzipet ad vissza.
Bár a fenti taknyolás működik, de ezt igazából a szerveren kellene javítani, hogy helyesen adja vissza aContent-Encodingmezőt.Küldesz amúgy
Accept-Encoding-ot a kérésben? Ha nem, akkor ez még nagyobb probléma a szerveren, ha igen, akkor gyorsan szedd ki, és lehet, hogy megúszod a teljes fejlesztést.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
A compatibility page akkor érvényét vesztette, amikor tavaly lejárt a VS2015 kibővített támogatása is. A VS2017 és VS2019 még az aktív támogatási időszakban vannak, ezeknél lehet elvárásod, azonban ha a VS2015-nél valami eltörik, akkor IJ, ezek a dátumok végig szerepeltek a támogatási roadmapben.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
C# esetében miért ragaszkodsz a 2015-höz? Ha akad VC14-et igénylő interop kód, amit macerás portolni, akkor oké, de amúgy önszívatás a régi .csproj formátumon maradni, sokkal lassabb NuGet csomagfrissítéssel szívni és a .NET Core 2.0 és frissebb támogatás teljes hiányáról ne is beszéljünk.
A VS2015 támogatása már egy éve lejárt, ezért nem tolja az ember képébe a Microsoft oldala, de ettől függetlenül a Community és többi változathoz tartozó ISO elérhető innen.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
Flashback
#9447
üzenetére
A struct ugyanúgy bővíthető metódusokkal, ez nem C, C#-ban a struct mást jelent, mint C-ben. A fenti linkemen a mikor használj structot class helyett listában négyből három feltételt nem teljesít a kódod:
* It logically represents a single value, similar to primitive types (int, double, etc.).
* It has an instance size under 16 bytes.
* It is immutable.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
alratar
#9396
üzenetére
var date1 = DateTime.ParseExact("2020-11-26", "yyyy-MM-dd", CultureInfo.InvariantCulture);Érdemes még a negyedik paraméterként átadni egy
DateTimeStylesértéket is, amiben jelzed, hogy UTC-ről vagy helyi időről van szó.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#9223
dqdb
nagyúr
Jokerpoker
#9222
dqdb
nagyúr
válasz
Jokerpoker
#9222
üzenetére
Project Properties > Build > Prefer 32-bit opció kikapcsolása, hogy lehetőleg 64 bites változat induljon el 64 bites OS-en a programból.
Azt azért megjegyezném, ha előre lehet tudni, hogy hatalmas fájlokkal lesz dolga az embernek, akkor feldolgozás megírásakor a legutolsó utáni dolog után jön csak pár lépéssel az a megoldás, hogy beolvassa a memóriába az egészet.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#9220
dqdb
nagyúr
DrojDtroll
#9219
dqdb
nagyúr
válasz
DrojDtroll
#9219
üzenetére
Ne a rendszerben található, .NET Frameworkhöz tartozó dll-t add hozzá referenciaként, hanem ezt a NuGet csomagot.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Most nézem, hogy az első metódus a hozzászólásomban az
AddhelyettToConsolelett volna, ha nem írom el ... szóval helyesen:public static class StringExtensions
{
public static void ToConsole(this string text)
{
Console.WriteLine(text);
}
}
public static class Test
{
public static string Add(string input)
{
return input;
}
}Az a lényeg, hogy te egy string példányon szeretnél saját metódust hívni, így a String osztályt kell saját metódussal bővítened. Az egész megoldás a syntactic sugar kategóriába tartozik mert ez:
Test.Add("blabla").ToConsole();a háttérben valójában erre fordul le:
StringExtensions.ToConsole(Test.Add("blabla"))tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
-
-
dqdb
nagyúr
válasz
bandi0000
#9130
üzenetére
De most ez a megoldás nem rosszabb, mintha csak csinálnék pl egy osztályt, amibe van egy error és esetleg egy status code tulajdonság amit mindig visszaadok?
Ha kizárólag webes felületet nyújtasz, akkor szerintem ez az exception + middleware páros a legjobb.Ha vegyes felvágott a helyzet, mint nálunk, ahol webes és MQ felület is előfordul, akkor más a helyzet. Ezeknél az adott API implementációból az általad kérdezetthez hasonló üzenet jön ki, az API által dobható exceptionök kezelése belül megtörténik:
public class SomeResponse : IResponse
{
public string RequestID { get; set; }
public class OK : SomeResponse
{
public string SomeData { get; set; }
}
public class FailedBecauseOfThis : SomeResponse, IFault
{
public int Code { get; set; }
public string Message { get; set; }
}
public class FailedBecauseOfThat : SomeResponse, IFault
{
public int Code { get; set; }
public string Message { get; set; }
}
}Proto:
message SomeResponse {
string RequestID = 127;
oneof subtype {
SomeResponseOK OK = 1;
SomeResponseFailedBecauseOfThis FailedBecauseOfThis = 2;
SomeResponseFailedBecauseOfThat FailedBecauseOfThat = 3;
}
}
message SomeResponseOK {
string SomeData = 1;
}
message SomeResponseFailedBecauseOfThis {
int Code = 1;
string Message = 2;
}
message SomeResponseFailedBecauseOfThat {
int Code = 1;
string Message = 2;
}Sikeres válasz:
{
"some_data" : "data"
}Hibás válasz:
{
"code": 123,
"message": "blabla"
}Aztán ha MQ-n keresztül érkező kérésről van szó, akkor a teljes
SomeResponseleszármazott megy vissza protobuf kódolással, ha webes kérésről van szó, akkor általában* egy réteg a hibákat a példány típusa és/vagy kód alapján megfelelő 4xx/5xx státuszkódokra mappeli és a hibaüzenetet tartalmazó JSON-t ad vissza, ha sikeres volt, akkor simán JSON megy vissza (webes kéréseknél aRequestIDsem kerül bele a válaszba, csak a konvertálást, szerializálást, naplózást befolyásoló attribútumokat az egyszerűség kedvéért lehagytam).* általában, mert volt, hogy a 200 azt jelentette csak, hogy a szerver válaszolt, és ugyanúgy protobuf ment vissza a kliens felé
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Szép dolog a szabvány, ha azt nem bonyolítják túl. A SOAP és a köré épülő infrastruktúra azonban túlbonyolított erőteljesen, ha pedig hozzácsapod a WS-Security-t, akkor főleg az lesz nem egyértelműen definiált elemekkel a szabványban. Szép dolog, amikor a Java és a C# világ nem tud beszélgetni egymással egy szabványos felületen keresztül úgy, hogy mindketten támogatják azt, mert adott feature X opcionális lehetősége közül sikerült diszjunkt halmazt implementálni (például bináris adatok hatékonyabb átvitelére a csak MTOM-ot támogató WCF találkozik egy csak SwA-t támogató Oracle alkalmazásszerverrel).
JSON, grpc (protobuf alatt ezt is értettem) eléggé támogatott minden platformon, az utóbbi esetben a túloldal megkapja a .proto fájlokat az interfészleírás részeként, és tud vele szépen dolgozni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Bármi, aminek a támogatása nem igényel akkora bloatware-t sem a kliensen, sem a szerveren, mint a SOAP-é. Ha a legkönnyebb integráció a cél kliensoldalon, akkor JSON vagy sima form data, ha sok a bináris adat, akkor protobuf.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Használj VS2017-et vagy VS2019-et és package reference-eket.
Így nem lesz
packages.config, nem leszpackagesmappa, hanem a csproj fájlba kerülnek be a hivatkozások, a VS automatikusan proxy targets fájlokat generál a csomag hozzáadásakor/visszaállításakor, amelyek a%USERPROFILE%\.nuget\packagesmappa alatti fájlokat használja.Persze a lefordított projektekbe így is, úgy is bekerülnek a DLL-ek, szóval olyan sok helyet nem spórolsz meg, de időt a csomagfrissítéseknél rengeteget.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
alratar
#9095
üzenetére
Ha nem a fő projektnél szerepel az System.Data.SQLite.Core csomag direkt függőségként (hanem csak annak egy függőségénél), akkor tedd be oda is. Feleslegesnek tűnik, hiszen függőség függősége, azonban az olyan csomagoknál, amelyek tartalmaznak az output mappába szánt natív DLL-eket és ezt a másolást csomaghoz tartozó targets fájlban
CopyToOutputDirectorypropertyvel intézik el (és az System.Data.SQLite.Core így tesz, bár próbálkozik bizonyos esetekben direkt másolással is prebuild feltételként és postbuild eventben, biztosra akartak menni ...), ott ezek a natív DLL-ek lemaradnak a kimenetből akkor, ha az adott csomag nem direkt függősége a tényleges alkalmazásnak vagy webalkalmazásnak, hanem csak indirekt.Régen használtam már SQLite-ot és abból is a gyári csomagot, de valaha ezt duális DLL-lel oldották meg (lehet, hogy nem ez volt a neve, de valami ilyesmi), ami egyszerre tartalmazott natív részt benne az interop kóddal és managed részt a .NET felülettel. Úgy nézem, hogy változott azóta, a .NET Core a tippem a változtatás okára. Kár érte, mert ezzel pont ezt a függőségi szívást lehetett kikerülni.
[link]
Vagy használd a C# portját, és akkor biztosan nem lesz szívás natív DLL-ekkel.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Hogy tudom megvalósítani, hogy a hívott URL szerinti metódus fussék le és a kimenetét (return string) adja vissza a HttpListener outputjaként?
Arequest.Uri.Pathtartalmazza a relatív címet, a routingot ez alapján tudod megvalósítani.Ha eléggé nagy a beeső kérés vagy válasz, akkor stringek helyett szerencsésebb streamek használata. Ha van adatbázis vagy más távoli elérés a háttérben, akkor pedig az aszinkron kód írása. Ha az IIS/Kestrel elkerülése a cél beépített HTTP szerverrel, akkor nézd meg ezt a csomagot, könnyű használni, van benne SSL, alapszintű routing támogatás és teljesen aszinkron a teljes felülete.
Annyi, hogy a server.exe egy lokális Win szerveren futna, nyilván ezt task scheduler egyszer elindítaná és ott szépen futna.
Ez nagyon nem nyilván, ilyen típusú működésre a Windows szolgáltatások valók, nem egy random felhasználó nevében elindított exe.Ennek a helyi szervernek nincs nyitott portja a net felé, alapvető biztonság tehát megtéve. És nem is a 80-as portot használná a program.
A 80-as helyett másik port használata nem igazán számít biztonságnövelő tényezőnek.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
-
dqdb
nagyúr
Vagy code injection kellene hozzá, amire jellemzően minden vírusirtó ugrana, amiben van alapszintű BB vagy HIPS. Ráadásul úgy is csak bonyolultan (BeginPaint és EndPaint eltérítése, direkt WM_PAINT kiadása) és okozhatna alkalmazásszintű problémákat.
Vagy meg kell keresni a topmost ablakokat, amelyek kitakarnának a képből, és ezeket el kell rejteni arra az időre.
Szerintem egyik sem éri meg a befektetett időt.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
zsolti_20
#9021
üzenetére
[link]
Forrást végignézve ez jó lesz neked, az előzőtől annyi az eltérés, hogy lekérdezi az aktív ablakot, és annak a koordinátáit használja fel.Azt azért hozzá kell tenni, hogy nem az aktív ablakról tudsz képernyőmentést készíteni, hanem a képernyő azon részéről, ahol az aktív ablak van. Ez a kettő általában megegyezik, azonban abban az esetben, ha az aktív ablakot részben takarja egy másik ablak, amire a z-order szerint feljebb van, akkor azon a részen a másik ablak fog látszani a mentésen.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
-
dqdb
nagyúr
válasz
zsolti_20
#8964
üzenetére
A három felvázolt eset szempontjában teljesen irreleváns, ki írta, csak az számít, hogyan kerül futtatásra az első alkalmazás (feltéve ha konzolos alkalmazás egyáltalán, mert a WriteLine-os példádból az jött le, ha nem, akkor az egy merőben eltérő plusz eset).
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
zsolti_20
#8960
üzenetére
Ha a második program az elsőt indítja, akkor sima output átirányítással megoldható a ProcessStartInfo megfelelő paraméterezésével. Ha nem, és PID vagy .exe neve alapján kell megkeresni az ablakát, akkor szintén megoldható, de ehhez kell egy jó adag P/Invoke. Ha ugyanabban a parancssorban egymás után indítod el, akkor szintén megoldható.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
a command.CommandText nem a behelyettesített értéket adja vissza
Az a property a beállított parancsot adja vissza, amiben paraméterek szerepelnek konkrét értékek helyett. A paraméterek behelyettesítése a szerveren fog megtörténni a már parse-olt SQL parancs felhasználásával, így a komplett parancs olyan szöveges formában, ahogyan te szeretted volna, sosem létezik.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
RedHarlow
#8917
üzenetére
Valami ilyesmi kellene neked fapados megvalósítással:
var delayBetweenRetries = 30 * 1000;
var maxRetries = 3;
var retryCount = 0;
var expectedFileCount = GetExpectedRemoteFileCount();
var actualFileCount = 0;
for (;;)
{
var fileCount = GetRemoteFileCount();
if (fileCount > expectedFileCount)
{
throw new TooManyRemoteFilesException();
}
else if (fileCount == expectedFileCount)
{
break;
}
else if (fileCount == actualFileCount)
{
if (++retryCount > maxRetries)
throw new TooManyRetriesException();
}
else if (fileCount > actualFileCount)
{
retryCount = 0;
actualFileCount = fileCount;
}
else
{
throw new RemoteFileCountMismatchException();
}
Thread.Sleep(delayBetweenRetries);
}Ha a távoli szerveren drága az exportálás és az SCP kapcsolat szeret megszakadni, akkor érdemes úgy megírni a
GetRemoteFileCount()metódust, hogy az kezelje a kapcsolat újraépítését. És persze nem árt a fájlok számának figyelése mellett a tartalmukat is ellenőrizni később.Ha sokkal bonyolultabb hibatűrést megvalósító esetek is előfordulhatnak, akkor a Polly library az egyik legjobb arra a célra, hogy ne kelljen minden távoli hívásnál/lekérdezésnél 30-50 soros logikát megírni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Rosszul közelíted meg a dolgokat.
Konzolos alkalmazás háromféle módon indulhat el Windows alatt:
1. egy másik konzolos alkalmazásból
2. egy másik konzolos alkalmazásból kimenetet és esetleg bemenetet átirányítva
3. nem konzolos alkalmazásbólAz első esetben az alkalmazásod a hívó alkalmazás ablakát örökli meg az ott beállított mérettel, historyval és színekkel, ezt általában nem illik* felülbírálni kódból, mert te ott vendég vagy.
A második esetben az előző annyival bővül, hogy a sima
Console.WriteLinehívások a képernyőre ki sem kerülnek, szóval itt a hívó ablakának beállításait kódból nemcsak nem illik felülbírálni, de értelmetlen is. Ezt az esetet aConsole.IsOutputRedirectedpropertyvel tudod érzékelni.A harmadik esetben a Windows megnézi, hogy az adott elérési úttal rendelkező alkalmazáshoz van-e beállítva alapértelmezett ablakméret/betűtípus/szín/stb. Ha igen, akkor azokkal indítja el az alkalmazásodat, egyébként a cmd.exe-hez tartozó alapbeállításokkal. Ekkor a kapott méreteket és egyéb beállításokat felül lehet bírálni kódból, de általában felesleges és nem szerencsés*, mert ezzel elveszed a felhasználó elől a saját igényeinek megfelelő beállítás alkalmazását. A legjobb megoldás vagy egy megfelelően felparaméterezett shortcut készítése, vagy futó alkalmazás mellett az ablakához tartozó menüben (fejléc bal oldalán lévő ikonra kattintva Defaults) átállítani, és onnantól kezdve az ott megadott értékekkel fog indulni az alkalmazás (egy adott konfigurációhoz egyszer kell beállítani VS-ből indítva, és onnantól kezdve mindig úgy fog elindulni).
* ha az alkalmazásod sima szövegkiíratás helyett valami ncurses-szerű szöveges UI-jal rendelkezik, aminek például a historyban görgetés keresztbe tesz, akkor ott természetesen kódból mindig olyanra be kell állítani az ablakot, amilyenhez a UI tervezve van (de itt is érdemes úgy megoldani a dolgokat, ha lehetséges, hogy a felhasználó által beállított ablakmérethez igazodjon a felület, mint például a FAR Manager esetében)
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
joysefke
#8867
üzenetére
Nem érdemes próbálkozni, a linkelt issue alapján nem működik az én megoldásom, csak az általad talált workaround.
Mindig "élmény" olvasni a NuGet fejlesztőcsapat arrogáns hozzáállását a bejelentett problémákra és szívni, amikor valamilyen újításuktól eltörik a build folyamat
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
joysefke
#8865
üzenetére
<PackageReference Include="YoutubeExplode" Version="4.7.9" Condition=" '$(Configuration)' != 'GooglePlayRelease' and '$(Configuration)' != 'GooglePlayDebug' "/>Így egyszerűbb, nem kell a
Chooseblokk, elég az eredetiPackageReferenceelemet módosítani. Csomagfrissítésnél nézz majd rá a .csproj fájlra, megmaradt-e a feltétel benne.[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
így utólag már mezei file-ok és memória blokkok elegendőek az sql szerver helyett, ami bizony egyszerűbbé teszi a dolgokat - akár hiszed, akár nem.
Tudom, hogy egyszerűbbé tudja tenni a fájlokat használó megoldás az életet, rendszeresen használok ilyet a storage interfész mockolására tesztekben. Persze éles környezetben nem, hiszen a redundancia, rendelkezésre állás kifejezések léteznek, és amíg egy clusterezhető middleware elintézi helyettem az adatok node-ok közötti replikálását, addig egy fájlalapú megoldásnál nekem kellene ezt nulláról lefejleszteni. Nem lehetetlen, csak rettenetesen időigényes, és akármennyi erőforrást is elégetek rá, akármennyi tesztet gyártok hozzá, a saját implementáció kevésbé lesz tesztelve éles szituációban, mint az elterjedt 3rd party megoldások. Vannak esetek, amikor érdemes feltalálni a spanyolviaszt, mert megéri, ez szerintem határozottan nem az.Részemről inkább azt a kérdést tartom nehezen megválaszolhatónak, hogy a c# topikban miért c stuffokat preferálnak a népek?
Én sosem a nyelvhez, hanem mindig feladathoz választok middleware-t, az pedig, hogy miben írták, teljesen irreleváns addig, amíg van hozzá .NET vagy REST API. Így aztán az egyik rendszerünk tipikus telepítése használ Javában, Erlangban és Góban készített middleware-eket (másikban akad Ruby is), miközben a rendszerünk forrása egyetlen sornyi Javát, Erlangot és Gót sem tartalmaz. Nem azért, mert a szivárványos össznyelvi összeborulás volt a cél, hanem azért, mert adott részfeladatra az adott komponenst találtuk a legjobbnak.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Az Iodine támogatja, ezt már sztanozs is jelezte. A másik csak egy egyszerű frontend, elé kell tenni egy rendes webszervert TLS proxynak.
A chrome is, meg a firefox is konkrétan blokkolják, ami nem támogat https-t, legyen az akár csak egy webapi kiszolgáló.
Rossz megközelítés: nem azért kell TLS-t használni, mert a Chrome és a Firefox sír a hiánya miatt, hanem azért, hogy védett legyen a kapcsolat, és ettől mellékesen a Chrome és Firefox boldog lesz. Nem tudom másoknál hogyan van, nálunk már sok-sok éve a fejlesztői rendszerekben is TLS-sel védett minden kapcsolat.könnyű megírni egyébként is
Ja, ha ilyen könnyű összedobni egy skálázható-clusterezhető megoldást, akkor nem szóltam. Kár, hogy a fél világ ezt nem tudja, és Redisre épít, ha cache kell neki.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
-
dqdb
nagyúr
Az Excel fájlban a B1 mezőben van a dátum, nem a B2-ben, ahogyan a forrásban szerepel.
Két megjegyzés:
1. oké, hogy az elvi lehetőség adott a közel teljes UTF8 használatára a forráskódban a szimbólumok nevéhez, azonban nem túl szerencsés ékezetes függvény- és változóneveket használni (és úgy általában nem angolt sem)
2. a GetCellValue metódust át kellene dolgozni, mert jelenleg minden érték kiolvasásánál megnyitod az Excel fájlt, megkeresed a munkalapot, ott mezőt, kiolvasod, majd lezársz mindenttAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Ha az Excelben adott mező formátuma dátum, akkor a
GetCellValuefüggvényből egész számot kapsz vissza szövegként, ha idő, akkor egynél kisebb törtet, ha dátum és idő, akkor törtet. Ha van törtrész, akkor a szövegben tizedespont szerepel, amire aDouble.Parse(value)akkor fog lefutni, ha olyan regionális beállításod van, ami tizedespontot használ, vagy második paraméterként átadsz egy ilyen locale-t. Az előző hozzászólásomban szereplőCultureInfio.InvariantCultureilyen, írd be, és működni fog.43566.556944444441 => 2019.04.11. 13:22:00
43567 => 2019.04.12. 0:00:00[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
RedHarlow
#8736
üzenetére
[link]
erre nem kell regexunrecognised escape characterre jutottam. Stackoverflow-on\googleben\youtubeon is kerestem hasonló hibákat de nem igazán jött össze.
Pedig a nálam legalábbis első találat lenne a megfejtés. Vagy @" vagy .*\\..tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Az Office interop arról szól, hogy egy futó/akkor elindított Excel alkalmazást vezérelsz távolról a COM interfészén keresztül, hogy hajtson végre ilyen-olyan műveleteket, így mindenképpen telepített kliens kell neki mind fejlesztés közben, mind máshová feltelepítve.
Ha Excel telepítés nélkül szeretnél .xlsx fájlokat kezelni, akkor nézz rá az EPPlus és Open XML SDK projektekre.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
RedHarlow
#8720
üzenetére
Nem ártana, ha véletlenszerűen kiollózott részletek helyett a komplett osztály forrását betennéd, mert így senki sem fog tudni semmi értelmeset mondani, legfeljebb találgatni, hogy mit csinálhattál.
Az utolsó előtti hozzászólásodban például az látszik, hogy a pcpath egy lokális változó, aminek értéket adsz, aztán nem kezdesz vele semmit sem.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
t-shirt
#8662
üzenetére
Ez esetben elég ennyi módosítás, és nem fogja a CPU-t tekerni feleslegesen:
using (var port = new SerialPort("COM" + cp))
{
port.BaudRate = 9600;
port.Parity = Parity.None;
port.StopBits = StopBits.One;
port.DataBits = 8;
port.Handshake = Handshake.None;
port.RtsEnable = true;
port.DataReceived += Port_DataReceived;
port.Open();
while (fo_tomb_index <= (fo_tomb_merete-1))
{
receivedNewRequest.WaitOne();
var s = port.ReadExisting();
WriteData(port, fo_tomb[fo_tomb_index]);
Console.WriteLine(fo_tomb[fo_tomb_index]);
fo_tomb_index++;
}
}
}
private static WaitHandle receivedNewRequest = new AutoResetEvent(false);
private static void WriteData(SerialPort port, string readLine)
{
port.WriteLine(readLine);
}
private static void Port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
receivedNewRequest.Set();
}joysefke: a kódodnál nem azért nem fogja feleslegesen terhelni a CPU-t, mert áttetted a futását egy másik szálra, hanem azért nem, mert a példádban a SerialPort.ReadLine hívást használod, ami ReadTimeout időt vár, mielőtt visszatérne, ha nincsen adat, és közben értelmes módon várakozik.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
t-shirt
#8656
üzenetére
Ha a kommunikációban a PC a kliens és az eszköz a szerver, ami a kérésekre válaszol, akkor érdemes egy megfelelő timeout értéket választani és beállítani, amin belül a túloldalnak biztosan válaszolni kell, a DataReceived esemény kezelésére nincsen szükség, és a Read metódussal kiolvasni a választ, ez vár a timeoutnak megfelelő időt, ha nem kap választ. A válasz olvasásának módján a protokolltól függően lehet finomítani (fejléc van-e, kiderül-e előre, mekkora lesz az üzenet és hasonlók).
Ha a kommunikációban a PC a szerver és az eszköz a kliens, aminek a kéréseire válaszol a PC, akkor célszerű lenne a DataReceived eseményben egy AutoResetEvent példányt élesíteni Set metódussal, a fő ciklusban pedig WaitOne hívással várakozni rá, és ott kiolvasni a kapott adatot. Így nem pörögne 100%-on egy mag feleslegesen várakozás közben.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
t-shirt
#8650
üzenetére
A soros port egy olyan állatfajta, amit egyszerre csak egy példányban lehet megnyitni, ráadásul full duplex átvitelre képes, így azon az egy példányon keresztül mehet a küldés-fogadás.
Emellett érdemes rászokni a
usinghasználatára olyan esetben, amikorIDisposableinterfészt megvalósító osztállyal dolgozol, mint aSerialPort, hogy exception esetében is garantáltan meghívódjon aDisposemetódus.Vakon belemódosítva valami ilyesmi lenne:
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
using (var port = new SerialPort("COM4"))
{
port.BaudRate = 9600;
port.Parity = Parity.None;
port.StopBits = StopBits.One;
port.DataBits = 8;
port.Handshake = Handshake.None;
port.RtsEnable = true;
port.DataReceived += Port_DataReceived;
port.Open();
Console.WriteLine("Küldj üzenetet a COM4 portra:");
while (!(Console.KeyAvailable && Console.ReadKey(true).Key == ConsoleKey.Escape)) {
WriteData(port, Console.ReadLine());
}
}
private static void WriteData(SerialPort port, string readLine)
{
port.WriteLine(readLine);
}
private static void Port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
var sp = (SerialPort)sender;
string dataReceived = sp.ReadExisting();
Console.WriteLine("A vissza jövö uzenet a COM4 port ra: " + dataReceived);
}
}
}tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#8598
dqdb
nagyúr
Peter Kiss
#8596
dqdb
nagyúr
válasz
Peter Kiss
#8596
üzenetére
Pedig nincsen szebb annál, amikor az SAP interfészen a mező neve egy rövidített német, egy rövidített angol és egy rövidített magyar szóból áll össze, és ezeket részeket az aláhúzás és kötőjel véletlenszerű kombinációja választja el
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
bandi0000
#8538
üzenetére
(a + bi)(c + di) = ac + adi + bci + bdi² = ac + (ad + bc)i + bdi²
Mivel i = √-1, ezért i² = -1, azaz
ac + (ad + bc)i + bdi² = ac + (ad + bc)i + bd × (-1) = (ac - bd) + (ad + bc)i
Vagyis:
(a + bi)*(c + di) = (ac - bd) + (ad + bc)i
Ha megnézed ennek a .NET Core-ban található implementációját, akkor ott pontosan ez szerepel:
public static Complex Multiply(Complex left, Complex right)
{
return left * right;
}
public static Complex operator *(Complex left, Complex right)
{
// Multiplication: (a + bi)(c + di) = (ac -bd) + (bc + ad)i
double result_realpart = (left.m_real * right.m_real) - (left.m_imaginary * right.m_imaginary);
double result_imaginarypart = (left.m_imaginary * right.m_real) + (left.m_real * right.m_imaginary);
return new Complex(result_realpart, result_imaginarypart);
}Vagyis akárhogyan nézem, jól szoroz össze két komplex számot az ajánlott osztály (csúnya is lenne, ha nem).
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz
bazsy1981
#8499
üzenetére
Ezt a funkcionalitást az OpenFileDialog mögött álló Win32 API függvény végzi, te nem kapod meg az értesítést arról, hogy drag and drop történt az ablakból indítva, ahogyan arról sem kapsz értesítést, ha mappát hoznak létre, és arról sem, hogy átneveztek egy fájlt (pontosítva igen, de finoman szólva sem egyszerű ezt elérni). Ha ilyet szeretnél, akkor neked kell megvalósítanod a fájllista kezelését (például erre építve, de találni erre más megvalósítást is).
UX szempontjából határozottan furcsa lenne az általad kitalált megoldás, lényegében nem arra használnál egy API-t, mint amire szánták, hanem kicsavarnád és abszolút nem intuitívvé tennéd a használatot.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Már csak érdekességből kérdezem: mi az a két bájt, amit kitömörítéskor le kell szedni, betömörítéskor meg hozzá kell biggyeszteni?
2.2 fejezetben a CMF + FLG rész.Alapvetően a webszerver esetén is megvan, de egyrészt a JSON forrása eltérő is lehet, és ott nem biztos, hogy a HTTP-ben történik a tömörítés, másrészt a kliens által visszaküldött anyagot is tömöríteni kell.
A kliens ugyanúgy támogathatja a tömörített adatküldést. Jelenleg fogsz egy JSON struktúrát, összetömöríted, hogy kisebb legyen a forgalmazott adatmennyiség, majd azzal, hogy base64 kódoláson tolod át, generálsz feleslegesen +33% forgalmat.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
Azért, mert a GZDecompress által átugrott első két byte hiányzik a GZCompress által létrehozott adatból.
Streamek és más IDisposable objektumok esetében mindig használd a using kulcsszót.
public static string GZDecompress(string compressedString)
{
try
{
using (var memStream = new MemoryStream(Convert.FromBase64String(compressedString)))
{
memStream.ReadByte();
memStream.ReadByte();
using (var deflate = new DeflateStream(memStream, CompressionMode.Decompress))
using (var reader = new StreamReader(deflate, System.Text.Encoding.UTF8))
{
var decompressedString = reader.ReadToEnd();
return decompressedString;
}
}
}
catch (Exception)
{
return String.Empty;
}
}
public static string GZCompress(string decompressedString)
{
try
{
using (var memStream = new MemoryStream())
{
memStream.WriteByte(0x78);
memStream.WriteByte(0x9c);
var input = Encoding.UTF8.GetBytes(decompressedString);
using (var deflate = new DeflateStream(memStream, CompressionMode.Compress))
{
deflate.Write(input, 0, input.Length);
}
return Convert.ToBase64String(memStream.ToArray());
}
}
catch
{
return String.Empty;
}
}Azt nem egészen értem, hogy miért nem HTTP szinten van megvalósítva a tömörítés, miért kell a kliens logikáját ezzel terhelni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
#8401
dqdb
nagyúr
Peter Kiss
#8398
dqdb
nagyúr
válasz
Peter Kiss
#8398
üzenetére
System32 vs SysWOW64 mappa
64 bites Windowson egy 64 bites alkalmazás a System32 mappát látja System32 mappaként, míg egy 32 bites alkalmazás a WoW64 alrendszer miatt a SysWOW64 mappát látja System32 mappaként. Szóval ott volt a meghívott alkalmazás, csak a rossz System32 mappában.
Registrynél van még hasonló virtualizálás a Wow6432Node node alatt.
sztanozs: az a pont a .dll-ekre és egy egyéb in-process megoldásokra vonatkozik, itt külön folyamat jön létre.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
Ú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!
- Eredeti játékok OFF topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- TCL LCD és LED TV-k
- Napelem
- Windows 11 - HP Pavilion – 15 cc516nh (2LE41EA) laptopon Intel I3-7100U TPM2.0
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Path of Exile 2
- Yettel topik
- Tarr Kft. kábeltv, internet, telefon
- Autós topik
- További aktív témák...
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest