Hirdetés
- Feháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasgatni
- A luxusmárkáknak kell a bitcoin, az USA jegybankjának nem
- Letiltja az USA a politikusokat a telefonhívásokról és szöveges üzenetekről
- Nagy áttörés jön a napelemek piacán, nem kell annyi hely a paneleknek
- Belenyúlt az USA az Epic Games igazgatótanácsába, nyomoz az NVIDIA
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Milyen routert?
- Jelszókezelők
- Mozilla Firefox
- KAÜ/Ügyfélkapu – már elérhető a kétfaktoros hitelesítés
- Tényleg betilthatja a TP-Linket az USA
- Mikrotik routerek
- Feháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasgatni
- Vivaldi (böngésző)
- PHP programozás
Ú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 = null
megoldja 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.Height
Ez 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.None
van 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.WorkingArea
propertyben 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 aGZipStream
példánynak vagy aStreamReader
-nek.Ha szép megoldást szeretnél vagy a memóriafoglalás is számít, akkor egy olyan
Stream
implementá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-Encoding
mező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
-
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
-
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
Add
helyettToConsole
lett 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
SomeResponse
leszá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 aRequestID
sem 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 leszpackages
mappa, 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\packages
mappa 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
CopyToOutputDirectory
propertyvel 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.Path
tartalmazza 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.WriteLine
hí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.IsOutputRedirected
propertyvel 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
Choose
blokk, elég az eredetiPackageReference
elemet 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
GetCellValue
fü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.InvariantCulture
ilyen, í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
using
használatára olyan esetben, amikorIDisposable
interfészt megvalósító osztállyal dolgozol, mint aSerialPort
, hogy exception esetében is garantáltan meghívódjon aDispose
metó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
-
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
-
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
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Path of Exile 2
- Szólánc.
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Futás, futópályák
- Windows 11 - HP Pavilion – 15 cc516nh (2LE41EA) laptopon Intel I3-7100U TPM2.0
- Apple asztali gépek
- De mennyi az annyi?
- Kémia topic
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- AKCIÓ!!! GAMER PC: RYZEN 9 5900X + RTX 3060 12GB GDDR6! GARANCIA/SZÁMLA!!!
- BONTATLAN Új Iphone 16 PRO 128Gb - 1TB Független 1év Apple GARANCIA Deák Térnél Azonnal Átvehető.
- BONTATLAN Új iPhone 16 PRO MAX 256-512GGB Független 1év Apple GARANCIA Deák Térnél Azonnal Átvehető.
- Tamron SP 70-200mm f/2.8 Di VC USD G2 objektív ( Nikon )
- Azta! Yoga Slim 7 Prémium Ultrabook 14,5" -40% AMD Ryzen 5 7640S 16/512 RADEON 760M 2GB 2,9K OLED
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Axon Labs Kft.
Város: Budapest