- Magga: PLEX: multimédia az egész lakásban
- vrob: Az IBM PC és a játékok a 80-as években
- Parci: Milyen mosógépet vegyek?
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Argos: Szeretem az ecetfát
- gban: Ingyen kellene, de tegnapra
- Flashback: Építsünk PC-t akciós alkatrészekből, lassan. upd: 05.28
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bambano: Bambanő háza tája
Új hozzászólás Aktív témák
-
Karma
félisten
válasz
tototos
#7056
üzenetére
Azért ez messze nem gyerekjáték, mindenképpen kell egy Windows driver ahhoz, hogy hardvereszközt emulálhass. Viszont pont erre a feladatra találtam egy még élő megoldást: vJoystick, ami a szöveg szerint tartalmazza az aláírt drivert, és C# SDK-n keresztül is lehet hajtani.
-
-
Karma
félisten
válasz
tototos
#6600
üzenetére
Ott valamit nagyon elnézel, az input változó biztosan nem egy szöveget tartalmaz. Mondjuk ha megpróbálod kiíratni, akkor tényleg ezt kaphatod.
Az a helyzet, hogy a LINQ query szintaxis, hasonlóan a legtöbb LINQ metódushoz, nem listát ad vissza, hanem egy IEnumerable-t; leegyszerűsítve egy "képletet", hogy hogy lehet végrehajtani az általad felsorolt műveleteket. Nem is fut végig a stringlistádon ekkor még.
Ha a visszakapott IEnumerable-ön hívsz egy ToList()-et, végigfut a ciklus és megkapod a tényleges listát.
var lines = File.ReadLines(fileName);
var input = (from line in lines
where (!line.Contains("dblink"))
select line).ToList();Így már input egy List<String> lesz, benne a neked kellő sorokkal.
A metódus formában ez így nézne ki, igazából szerintem egy ilyen egyszerű szűrésnél sokkal jobban olvasható:
var lines = File.ReadLines(fileName)
.Where(line => !line.Contains("dblink"))
.ToList();---
A ToListen kívül a ToArray, ToDictionary, ToLookup metódusok hívásakor, továbbá foreach ciklussal vagy XAML bindinggal is kiértékelődik a képlet.
Nagyon oda kell figyelni arra, hogy ahány ilyet hívsz, annyiszor újrakezdi a teljes számolást! Ezért miután a képleted teljes, célszerű a ToListtel materializálni a listát, és így megspórolni a felesleges újraszámolásokat.
---
Csendben kicseréltem a ReadAllLines hívást ReadLinesra. Ennek a verziónak az a hatalmas előnye, hogy nem olvassa fel azonnal a teljes fájlt a memóriába, hanem soronként dolgozza fel, ahogy materializálódik az eredmény, memóriát spórolva. Jobban is passzol a LINQ filozófiájához.
-
#5674
Peter Kiss
őstag
tototos
#5673
Peter Kiss
őstag
válasz
tototos
#5673
üzenetére
Szia!
Azt hiszem, látszik, hogy semmit.
Ez egy tervezési megfontolás miatt lett így kialakítva.A kódban használhatjuk úgy ennek az osztálynak egy instance-át, hogy tudjuk, van valami a működésében, ami igényli a használata után, hogy megszabaduljunk tőle, dispose-oljuk (a forrás mögött lehetnek unmanaged erőforrások, amiket mindig érdemes lezárni, pl. file strem, database connection és hasonlók). Jelenleg nincs ilyen, de később előfordulhat, hogy szükség lesz rá, illetve az implementált interface is jelzi már ezt a lehetséges viselkedést, készülni kell rá.
-
#5626
Peter Kiss
őstag
tototos
#5621
Peter Kiss
őstag
válasz
tototos
#5621
üzenetére
Kicsit áthegesztettem: Visual Studio 2013-as project
Nyilván nem tudom, működik-e rendesen, de van benne pár ötlet.
Megjegyzések:
- parser-t nem összekeverni: adattárolóval (DataSet), mentő megoldása (CreateFile)
- parser, saver, writer blabla dolgokat mindig érdemes IDisposable interface-szel ellátni
- DataSet ne maradjon véletlenül sem gazdátlanul, mert a ctor-ban alapból van egy GC.SuppressFinalize((object) this); hívás
- nem kell mindennek mindent ismernie
- miért nem XML-lel megy?
- CultureInfo csak parse-olásnál volt állítva, mentésnél nem, de parse esetén sem volt visszaállítva
- a többit nézd meg -
Karma
félisten
válasz
tototos
#5623
üzenetére
Íme:
class LDF_akarmi
{
private DataTable _signals = new DataTable("Signals");
private DataTable _frames = new DataTable("Frames");
public LDF_akarmi()
{
InitTable(_signals, SignalTableColumns);
InitTable(_frames, FrameTableColumns);
}
private static readonly IList<Tuple<string, Type>> SignalTableColumns = new[]
{
new Tuple<string, Type>("Name", typeof(string)),
new Tuple<string, Type>("Size", typeof(byte)),
new Tuple<string, Type>("Initval", typeof(UInt16)),
new Tuple<string, Type>("TypeID", typeof(string)),
};
private static readonly IList<Tuple<string, Type>> FrameTableColumns = new Tuple<string, Type>[]
{
new Tuple<string, Type>("Name", typeof(string)),
new Tuple<string, Type>("ID", typeof(UInt16)),
new Tuple<string, Type>("Size", typeof(byte)),
new Tuple<string, Type>("SlotTime", typeof(Single)),
new Tuple<string, Type>("Transmit", typeof(byte))
};
private void InitTable(DataTable table, IEnumerable<Tuple<string, Type>> columns)
{
table.Columns.AddRange(columns.Select(col => new DataColumn(col.Item1, col.Item2)).ToArray());
}
}Szerintem elég drasztikus a különbség. A DataColumn[] tagváltozóid egyébként meg teljesen feleslegesek, így tömörítve meg még csak létre se jönnek külön. Ja és for ciklus se kellett, hiszen van AddRange metódusa a Columnsnek
Amúgy miért használsz DataSetet meg DataTable-t? Megjelenítésnél kihasználod ezeket az osztályokat? Mert ha nem, akkor valószínűleg jobban járnál, ha a Signalnak és a Frame-nek külön osztályt vezetnél be az ilyet táblás zsonglőrködés helyett.
-
Karma
félisten
válasz
tototos
#5621
üzenetére
Három dolog vágott szembe elsőre:
1) A System.Type.GetType(string) egy törékeny, és teljesen felesleges mellélövés, használd inkább a typeof operátort. Így biztos, hogy nem írod el a névteret, és azt a típust jelenti, amit szeretnél.
Például System.Type.GetType("System.String") helyett typeof(String).
2) Másrészt a kódod rettenetesen redundáns.
a) Például a két konstruktort (filename paraméteres és paraméter nélküli) simán össze tudnád vonni egybe, opcionális paraméterrel vagy a this konstruktor láncolással.
b) Magában a konstruktorban jön ki nagyon, hogy ismételed önmagad: ugyanaz a szerkezet ismétlődik újra meg újra meg újra, copy-paste-tel gondolom egyszerű volt megírni, de ez is nagyon törékeny és karbantarthatatlan. Az oszlopok definícióit ki kéne szervezned egy static readonly tömbbe (benne pl. string+Type Tuple-ökkel), és for ciklussal helyettesíteni az ismétlődő részeket.3) Túl hosszú és monolitikus. A 600 soros blob helyett szét kéne szedni – felelősség szerint – 100-150 soros darabokra.
-
vlevi
nagyúr
válasz
tototos
#5371
üzenetére
Idisposable classoknal erdemes a usingot mindig hasznalni.
En egyszer nagyon megszivtam egy kepkonvertalo progimmal, ahol a kepeket nem usinggal hasznaltam, es parezer kep atkonvertalasa kozben elszallt out of memroyval 8G ram mellett!
Usingba rakva 3-4M volt a max memoriahasznalata a proginak. -
Karma
félisten
válasz
tototos
#5371
üzenetére
Ha nem használsz try-finally-t akkor igen. Ebben az esetben ha bármi hiba történik és exceptionnel robban a kódod, a close nem hívódik meg, míg a using garantáltan lezárja. A finally blockba helyezett close szintén.
Attól még egy invalid path ugyanúgy exceptionnel robban, viszont a fájl meg garantáltan le lesz csukva.
-
Karma
félisten
válasz
tototos
#5251
üzenetére
Ettől még ne akard kódba rakni, mert az nagyon nem oda való, és amúgy is egy undorító félindiai megoldás. A resource-oknak ellenben pont ez a lényege, hogy belefordulnak az assemblydbe.
Ha resx fájlt adsz a projekthez, akkor string konstansként éred el a tartalmakat (és a solutionben egy fájl lesz, benne a két tartalommal); de olyat is csinálhatsz, hogy a solutionben külön fájlok, a kódban meg streamként éred el.
-
sztanozs
veterán
válasz
tototos
#4879
üzenetére
Kicsit sokáig állt a hsz-em szerkesztésben
A CurrentCulture.NumberFormat nem jó, mivel vsz nem English formátum van beállítva a gépen.
A default beállításhoz a következőt kell csinálni a kiírás előtt.System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
-
#4748
Peter Kiss
őstag
tototos
#4747
Peter Kiss
őstag
-
-
-
Karma
félisten
válasz
tototos
#3883
üzenetére
Nem túloztad el felénk a specifikálást
Például feltételezhető, hogy a sorazonosítóban és a harmadik mezőben (Steering_msg_1:)-es mezőben nem lehet szóköz, és a második mező (256) biztosan szám? Mert ha igen, elég könnyű rá regexet írni, és capture groupokkal kirángatni a megfelelő értékeket. Ha viszont nem lehet feltételezni a szóköztelenséget, akkor nagyobb baj van.
Így pl. fel lehet darabolni, ha igaz a feltételezés: (.+?) ([0-9]+) (.+?): (.*)
C#-ban konkrétan (nem teszteltem!) ilyesmi:
var regex = new Regex(@"(.+?) ([0-9]+) (.+?): (.*)");
var match = regex.Match(input);
if (match.Success)
{
var lineId = match.Groups[1].Value; // fontos! 1-től kezdődnek a groupok!
var something = match.Groups[2].Value;
var something2 = match.Groups[3].Value;
var message = match.Groups[4].Value;
} -
kingabo
őstag
válasz
tototos
#1798
üzenetére
Na megírtam a progit nem nagyzolás miatt csak, hogy tudjak segíteni ha elakadsz/ne ajánljak hülyeséget, nem akarnám 1:1-ben odaadni, inkább jöjj rá a dolgokra Te! (nem szivatásból, csak sok buktató van, amit jó ha magad is megtapasztalsz, így késöbb tudni fogod, hogy hogyan kell megoldani) De igaziból azt is jó lenne tudni, hogy mit tanultál, meg mennyi van meg.
Nagyjából így oldottam meg: gombra katt, ami létrehoz egy új thread-et és feldobja az ablakot, ebben a thread-ben nagy számítás szimulálására létrehozok egy timert, aminek a tick eseményére megnövelem a másik formon a progressbar értékét. Hogy a lyúzer ne tudja kilőni felíratkoztam a formclosing eseményre, ennek az eseménykezelőjében, ha nem végeztem a számolással, akkor az e.Cancel = true; utasítással nem engedem, hogy bezárja. Ha végeztem a számítással bezárom az ablakot.
Ha valamit nem értesz, kevés,... kérdezz nyugodtan.
-
kingabo
őstag
válasz
tototos
#1793
üzenetére
Hali!
BackgroundWorker-rel sokkal könnyebb lenne megoldani, illetve a gombra kattintáskor le kell tiltani az összes formon lévő gombot és nem tud a lyúzer semmire sem kattintani. Vagy ha a gombletiltás nem tetszik, akkor egy bool változót kell deklarálnod a form-hoz, ha elkezdesz számolni igazra állítod, ha vége, akkor false-ra és minden gomb click esemény kezelőjében megvizsgálod, hogy a változó false-e, ha nem(vagyis számolsz), akkor return.
-
-
#1758
FehérHolló
veterán
tototos
#1757
FehérHolló
veterán
válasz
tototos
#1757
üzenetére
Így első nekifutásra ha a ConcurrentQueue-t használod, akkor valamivel meg kell fognod a fogyasztó (nálad protokoll) szálat üres queue esetén, különben megzabálja a procit üresjáratban.
Ha blokkolni is szeretnél, akkor szerintem (megint első nekifutásra) hasznosabb lehet a BlockingCollection osztály. Ez blokkolja a fogyasztó (protokoll) szál futását üres queue, a termelő (kártya) szálat pedig teli puffer esetén.De szerintem jobban jársz, ha megvárod Gregorius válaszát. Ő nagyon nagy valószínűséggel jobban ért a .NET 4.0-hoz.
És igen, elég késő van.
-
#1756
FehérHolló
veterán
tototos
#1755
FehérHolló
veterán
válasz
tototos
#1755
üzenetére
Ez körülbelül arra jó, hogy egy puffert threadsafe módon kezel. Tehát egyszerre csak egy szál férhet az osztály egyes példányaihoz hozzá. Megspórolja egy csomó munkádat, átláthatóbbá teszi a kódot.
Más: Úgy látszik, nem igazán tudtam helyesen írni az előbb. Pedig még nem is ittam szinte semmit. Szóval bocs.
-
#1750
FehérHolló
veterán
tototos
#1748
FehérHolló
veterán
válasz
tototos
#1748
üzenetére
Gondolom, ez egyértelmű, de több szálon kell megoldanod.
A CAN-t figyelő thread töltsön egy puffert, ami az üzenetek leíróját tartalmazza. Miután megjött X darab (ne egyesével), szóljon a feldolgozó szálnak egy AutoResetEvent típusú példányon keresztül. A feldolgozó szál pedig pakolja ki a puffert, és az üzenet típusától függően dolgozza fel azokat.
Ehhez ami kell MSDN-ről ([link]):
- Linkedlist ([link])
- Szálkezelés ([link]) + tutorialok.
- AutoResetEvent: [link]Konkrét megoldát nem akarok, és nem is tudok mondani, esetleg csak részleteket. Ha új vagy C#-ban és többszálas programozásban, ráadásul a CAN kártya is teljesen új számodra, akkor olyan 30-40 óra körülire saccolom a feladatot.
Ha esetleg a KB monogramra hallgató cégnek csinálod ezt, vagy egy Vector cég által gyártott CAN kártyával akadt dolgod, akkor kérlek vedd fel velem a kapcsolatot privátban!
ArchElf: OnReceive csak a WinFormson alapértelmezett tudtommal. Amilyen CAN wrapperekkel eddig találkoztam, mind ipari szemét volt a Microsoft elképzeléseihez képest.
Ha gondoljátok törölhető a comment.
Ez egy tervezési megfontolás miatt lett így kialakítva.
Ú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!
- Apple iPhone 14 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- Honor Magic7 Lite 512GB, Kártyafüggetlen, 1 Év Garanciával
- Honor 400 lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- HP Prodesk 600G4 SFF - i5-8500, 16GB DDR4, 512GB NVMe SSD, ATI R5 430 2GB eladó!
- 120 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- BESZÁMÍTÁS! ASUS H170M i7 6700 16GB DDR4 512GB SSD GTX 1660 Ti 6GB KOLINK Observatory Lite TT 500W
- Eladó szép állapotban levő Huawei P30 Pro kék 6/128GB 12 hónap jótállással!
- 15,6" Dell Latitude laptopok: E6540, E5550, E5570, 5580, 5590, 5500, 5501, 5510/ SZÁMLA + GARANCIA
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged