- Felháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasni
- 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
Új hozzászólás Aktív témák
-
#1774
FehérHolló
veterán
Lortech
#1773
FehérHolló
veterán
válasz
Lortech
#1773
üzenetére
A megfelelő thread cleanupot biztosítani kell ezektől függetlenül, mint ahogy a normál leállást is preferálni kell (thread értesül róla, hogy le kell állnia és leáll, ha van rá idő vagy kritikus megvárni).
Igen, ezt erőltetem. A lényegben tehát egyetértünk. Csak abban nem, hogy szerintem a kérdéses problémát csak a szőnyeg alá söpri a te megoldásod. Ha "rendesen kitakarít" a programozó, akkor semmi szükség rá. Kényelmi funkció, ami szerintem túlzottan óvatlanná teheti az egyszeri halandót.Debugolásról meg annyit, hogy tegyük fel, hogy normál módon akarod leállítani a szálakat, szerinted mindent megtettél ennek érdekében. Ha a háttérben futtatod a szála(ka)t, akkor viszont soha nem fog kiderülni (vagy csak vért izzadás árán) az ellenkezője. Tehát nem/nehezebben jössz rá, hogy mégsem úgy működik valami, ahogy eltervezted.
Konkrét probléma nélkül elég nehéz egzaktabbá tenni a beszélgetést. Én úgy érzem, hogy megértettem a te álláspontodat. Részben egyet is tudok érteni veled. Azonban én hasonló esetben (nagy általánosságban) nem fogom használni a megoldásod a fenti érvek miatt. Mások pedig cselekedjenek a saját belátásuk szerint.
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1772
FehérHolló
veterán
Lortech
#1771
FehérHolló
veterán
válasz
Lortech
#1771
üzenetére
Tudom, hogy miért ajánlottad. Ettől függetlenül nagyságrendekkel nehezebb lesz a háttérbe pakolt szál debugolása. Másrészt teljesen mindegy, hogy az oprendszer, vagy a futtató környezet lövi le, mindkét esetben kicsúszik a kezedből. (Nem azért, mert te nem tutod abortálni, hanem azért ,mert ezek után nem is fog érdekelni, hogy abortálnod kéne.)
Sokkal tisztább az, ha a form closing/closed eseménynél lekezeli az összes szálat.
Szóval van szó arról, amit írtam.[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1770
FehérHolló
veterán
Lortech
#1769
FehérHolló
veterán
válasz
Lortech
#1769
üzenetére
Az mennyire egészséges, ha erről a már háttérben futó szálról soha többé nem derül ki, hogy hibásan fut? :-)
Sőt, a program bezárása után már csak oprendszer szinten lehet majd lelőni.Másrészt szerintem érdemesebb lenne a Closed eseményt nézni. ([link])
Skynet is real. It's called Google.
-
#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.
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#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.
Skynet is real. It's called Google.
-
#1754
FehérHolló
veterán
FehérHolló
#1753
FehérHolló
veterán
válasz
FehérHolló
#1753
üzenetére
Hogy őszinte legyek, pont egy ilyen működést megvalósító osztályt kreaáltam a probléma megoldására... Queue + eventtel kölcsönös kizárás.
Skynet is real. It's called Google.
-
#1753
FehérHolló
veterán
Gregorius
#1752
FehérHolló
veterán
válasz
Gregorius
#1752
üzenetére
Mindjárt megnézem. Értelmesnek hangzik. Én anno linkedlist-tel oldottam meg, a kölcsönös kizárást meg egy autoresetevent (ha karod, szemefor) valósította meg.
Szerk.: Én .NET 3.5-ben dolgoztam, ez 4.0. Hasznos cucc. Köszi!
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#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.
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1738
FehérHolló
veterán
FehérHolló
#1737
FehérHolló
veterán
válasz
FehérHolló
#1737
üzenetére
Úgy tűnik, hogy nem annyira okos, hogy magától tabuláljon.
A szerkesztőd majd tabulálja, ha bemásolod.Egyébként az kimaradt, hogy ezt a while(true) cikluson belülre kell írni, de remélem, egyértelmű volt.
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1737
FehérHolló
veterán
Vasinger!
#1736
FehérHolló
veterán
válasz
Vasinger!
#1736
üzenetére
Ha mindenképp látni akarod a betűt, akkor Console.ReadLine().
Csak akkor kicsit finomítani kell, hogy 0 hossznál ne csináljon semmit és 1-nél hosszabbnál csak az első betűt szeresse a feldolgozáskor.string b_s;
b_s = Console.ReadLine();
if(b_s.Length > 0)
{
b = b_s[0];
if (a < b)
{
Console.WriteLine("A betű előrébb van az ABC-ben");
}
else if (a > b)
{
Console.WriteLine("A betű hátrább van az ABC-ben");
}
else //if (a == b)
{
Console.WriteLine("Talált!");
break;
}
}[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1428
FehérHolló
veterán
FehérHolló
#1427
FehérHolló
veterán
válasz
FehérHolló
#1427
üzenetére
Igazából kicsit hülyén néz ki, hogy a kiírandó adatok beszerzése meg van oldva, a felület külalakra kész, csak a tapasztalatlanságból adódóan problémák merültek fel a kettő rész összekapcsolásával.
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1427
FehérHolló
veterán
x007
#1423
FehérHolló
veterán
A fenébe, pedig nem ezzel akarok most foglalkozni, mégis visszakacsintgatok a fórumra...
Nem irtózok egyáltalán a BGWorkertől, csak nem arra találták ki, amire nekem kéne.
Probléma, ha gyakran kell a GUI-ra írni? Az egész GUI-m arról szól, hogy akárhány (esetemben 2) 500kbit/sec és akárhány (esetemben 1), max 150kbit/sec sebességű, egyenként átlagosan 80%-ban kihasznált hálózat forgalmát jelenítsem meg egy "felhasználóbarát" felületen, on-the-fly szűrési lehetőséggel, meg ilyesmik. Ráadásul úgy, hogy a felhasználó is tudjon manuálisan, vagy ütemezve üzeneteket küldeni.
A kiírandó adatok értelmes pufferelése, pufferek karbantartása, kiírás ütemezése, satöbbi már kész. Csak ez a szerencsétlenség akasztott meg, hogy a GUI-ra csak egy fix szálból lehet írni. Nem akkora gond, eddig is delegate-ekkel dobálóztam a layerek között, de mivel tapasztalatlan voltam ilyen téren, nem számítottam erre az akadályra.[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1422
FehérHolló
veterán
x007
#1421
FehérHolló
veterán
Én úgy látom, hogy Microsoft is érzi, hogy elavult. Például a kezünkbe adtak egy BackGroundWorker osztályt, ami a háttérben végzi el a marshallozást bizonyos esetekben, nem neked kell megírni a kódot, satöbbi.
Igazából jó lenne, ha ez nálam is működne, csak nekem egy while(true) típusú szálból kell adatokat szolgáltatnom. A BackGroundWorker végtelen ciklusosításával ezt jelenleg meg lehet persze csinálni, de ez a megoldás a BGWorker alapcéljától annyira eltér, hogy a későbbi frameworkökkel való kompatibilitásomat kockáztatnám.
shev7: Most nincs sajnos időm. Talán a hétvégén.
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1418
FehérHolló
veterán
FehérHolló
veterán
Hogy őszinte legyek, elég mély lelki válságba taszítottatok a DataGridView-es kérdésemre adott válaszaitokkal.
Eddig csak konzolos alkalmazásokat írtam. Teljesen új volt számomra, hogy az UI szál írhat csak az "ablakba". Konzolosnál nem kell azzal törődni, hogy ha meg akarok jeleníteni valamit, akkor egyetlen szálba kell dobálnom minden megjelenítendő infot a többiből. (Kicsit elavultnak érzem ezt a megoldást, de ez most részletkérdés.)Elég sokat olvasgattam MSDN-t azóta, hogy valamennyire megismerjem ezt a szemléletet. Találtam egy egész jó cikksorozatot, mely ezzel a kérdéssel foglalkozik. Az első része: [link]
Remélem másnak időt tudok spórolni azzal, hogy ezt megosztottam.tagek fórumkeresőnek: Windows Form thread safe safety UI mashall szál
REDeath:
miért mindig postolás után veszem észre a hibám?
Ugyanabban a kórban szenvedünk.[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1414
FehérHolló
veterán
FehérHolló
veterán
shev7 és x007: Köszi a válaszaitokat! Ennyivel úgy gondolom, hogy már boldogulok.
Skynet is real. It's called Google.
-
#1397
FehérHolló
veterán
shev7
#1396
FehérHolló
veterán
Köszi szépen!
Kicsit bővebb info: Olyan alkalmazást szeretnék csinálni, mely egy maximális elemszámú lista elemeit írja ki egy táblába. (Egy hálózaton érkezett és küldött adatok + tulajdonságaik.)
A lista folyamatosan bővül, régi elemeket törlöm a pufferből. Egy szál írja újra a DataGridView-t periodikusan, egy szál tartja karban a puffert és egy tölti azt. Utóbbi két funkció így első nekifutásra összevonhatónak tűnik, de majd elválik.
Előreláthatólag BindingSource-ot fogok használni, unbound DataGridView-val, de ez még elég képlékeny. Szívesen fogadok kódrészletet. Mint mondtam, igazából a thread safety megoldások érdekelnének, mert MSDN-en sehol nincsenek rendesen ledokumentálva a DataGridView manipuláló metódusok ilyenféle tulajdonságai.MSDN-es kódokat végignéztem már.
Skynet is real. It's called Google.
-
#1395
FehérHolló
veterán
FehérHolló
veterán
Tud valaki mutatni egy-egy jó példát az unbound és a bound DataGridView használatára? Főleg a tartalmának dinamikus változtatása érdekelne (plusz mennyire threadsafe a mutatott példa, ilyesmi).
Skynet is real. It's called Google.
-
#1386
FehérHolló
veterán
sunsaw
#1385
FehérHolló
veterán
Az a helyzet, hogy elég sok igazság van ebben, amit írtál. Nekem muszáj volt wrappert használnom (egyetlen interfész egy CAN és LIN hálókártya felé). Előjöttek ezek a dolgok, és rengeteget szívtam miattuk, amíg sikerült minden wrapperbeli hibát kikerülnöm (mivel elhárítani nem tudtam a wrappelés miatt).
Skynet is real. It's called Google.
-
#1382
FehérHolló
veterán
shakor86
#1371
FehérHolló
veterán
válasz
shakor86
#1371
üzenetére
Elég komoly vagy, hogy előre lehülyézed azt, aki majd esetleg segítene neked.
Egyébként meg RightToLeft attribútum.
sunsaw: Mi a bajod a wrapperrel? (Pusztán érdeklődés.)
Ha jól olvasom, itt adtak pár olyat is, ami nyílt forrású: [link]Mi a bús francnak írogatok ide ilyenkor...?
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1206
FehérHolló
veterán
FehérHolló
#1205
FehérHolló
veterán
válasz
FehérHolló
#1205
üzenetére
Ami így visszaolvasva biztos, hogy nem egyértelmű: Nem egy sima XML dokumentumról beszélek, hanem egy olyan XML alapú adatbázisról, mely egy csomó egyéb formai és tartalmi megkötésnek is eleget tesz.
Mindenesetre megoldottam azt a két dolgot, amiért alapban ideírtam, szóval ezek után már mindegy.Nem beszélhetek sajnos konkrétumokban.
[ Szerkesztve ]
Skynet is real. It's called Google.
-
#1205
FehérHolló
veterán
x007
#1204
FehérHolló
veterán
Azóta megoldottam a problémát.
XPath a sémára épül, ami nálam szükségtelenül elbonyolította volna a helyzetet, ugyanis a lekérdezés eredményét egy C# program dolgozza (majd) fel. XML-es LINQ ([link]) tökéletesen megfelelt a célnak. Egyébként ha az SQL alapú adatbázisokat kiterjesztjük úgy, hogy táblában lehet tábla is, akkor már elég értelmes dolog SQL (alakú) lekérdezésről beszélni XML adatbázisoknál is. Véges mennyiségű munkával létre lehet hozni olyan kódrészt, ami az alap "select xy from Z where kifejezés order by szabály" alakú SQL lekérdezést átfordítja XML-es LINQ-re. Az eredmény persze egy XML fa lesz. Hasonló analógiára meg lehet oldani a törlést és a változtatást is.
Az eredeti kérdésem arra irányult, hogy létezik-e ez már .NET keretrendszerben megírva, mert akkor nem kellett volna nekem összegányolnom.Az SQL to LINQ-et pedig nem használhatom.
Skynet is real. It's called Google.
-
#1203
FehérHolló
veterán
FehérHolló
veterán
Létezik valami .NET által támogatott mód XML formátumú adatbázisban SQL alapú lekérdezésre. (LINQ-s lekérdezés működik.)
Esetleg valami .NET-es támogatás SQL lekérdezés -> LINQ lekérdezés konverzióra? (Forditott irányról tudok.)Ha mondotok valami osztálynevet, azzal már ki vagyok segitve, nem vágyom teljes programrészletekre.
Skynet is real. It's called Google.
Ú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!
- 2x8GB 3600MHz Apacer NOX memóriakitek GARANCIÁVAL/SZÁMLÁVAL! ÁRON ALUL! Hűtőbordás, dobozos!
- Eladó! Kishibás Rtx2070 8GB!
- HP ZBook Fury 15 G8 Profi Tervező Vágó Laptop -50% i7-11850H 32/512 FHD IPS NVIDIA RTX A2000 4GB
- Új HP ZBook Firefly 16 G10 Profi Tervező Vágó Laptop -50% i7-1355U 16/1TB FHD+ RTX A500 4GB
- PlayStation 5 Pro + Vertical Stand
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest