Új hozzászólás Aktív témák

• #1775 Lortech addikt FehérHolló #1774

  Új Válasz 2011-02-28 14:09:59 #1775

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Lortech

  addikt

  válasz FehérHolló #1774 üzenetére

  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.
  Nem pont erre asszociáltam debugolás kapcsán, de azt hiszem, értem mire gondolsz.
  Adott esetben nem feltétlenül van jelentősége, hogy a thread hogy ért véget, mert pl. épp csak monitorozott valamit és nem érdekes, hol állt meg, vagy a gui thread nélkül nincs is értelme tovább futnia, vagy hosszan fut egy-egy tevékenység benne, és nincs idő megvárni, amíg rájön, hogy le kell állnia. Mit csináljon, várjon egy percet amíg befejezi (remélhetőleg) és eljut a következő szálban maradási ellenőrzésig? De lehet, hogy a felhasználó nem szeretné megvárni, hanem kikapcsolja a gépet, és végül fogalmunk sem lenne így sem, hogy mi történt. Vagy pedig ilyen esetben engeded kimúlni background threadként, és lekezeled a threadabortexceptiont és kilogolod a megfelelő infókat.
  No de visszakanyarodva az eredeti kérdésre, ha más lett volna a kontextus, akkor nem az isBackgroundot ajánlom elsőkörben. A kérdésből úgy tűnt, hogy nem cél kontrollálni a threadet, nem cél bármi cleanupot elvégezni, csak pusztuljon a szál a processzel együtt - mivel eleve csak akkor merült fel az egész kérdés, mikor már kiderült, hogy valami nem klappol, nem áll le a processz. Persze ez lehet, hogy a körültekintés hiányából fakad, és nem tudatos.

• #1773 Lortech addikt FehérHolló #1772

  Új Válasz 2011-02-28 10:16:36 #1773

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Lortech

  addikt

  válasz FehérHolló #1772 üzenetére

  De akkor mi volt az, hogy idézem: "már csak oprendszer szinten lehet majd lelőni", valamint "ha erről a már háttérben futó szálról soha többé nem derül ki, hogy hibásan fut" ?

  -Hogy háttérszál-e vagy sem, nincs relevanciája a debugoláskor.
  -"Nem csúszik ki a kezedből", ha nem akarod.
  A background thread továbbra sem különbözik semmiben egy foreground száltól, kivéve abban, amiről szó van, hogy nem fut tovább a processz miatta, ha az utolsó nem háttérszál leáll. 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).
  Ha valami egzaktabb érvek mentén folyna a diskurzus, akkor lehet, hogy hamarabb dűlőre jutnánk.

• #1771 Lortech addikt FehérHolló #1770

  Új Válasz 2011-02-28 00:04:19 #1771

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Lortech

  addikt

  válasz FehérHolló #1770 üzenetére

  A daemon threadet pont azért ajánlottam, hogy le tudja állítani normálisan az alkalmazást, le fog állni az ilyen thread, ha a többi fő thread is leállt. Szó nincs arról, amikről írsz.
  A válasz az volt, amit írtam + az első link, a form closingot csak úgy mellékesen linkeltem, a megoldáshoz nincs rá szükség.

• #1759 Gregorius őstag FehérHolló #1758

  Új Válasz 2011-02-24 22:20:09 #1759

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Gregorius

  őstag

  válasz FehérHolló #1758 üzenetére

  Ha jól látom, a BlockingCollection<T> az egy wrapper a ConcurrentQueue fölött, úgyhogy ha blokkoló viselkedésre van szükség, akkor ez a megoldás.
  Továbbá ha nem szigorú követelmény, hogy a feladatokat érkezési sorrendben kell megoldani, akkor még ajánlanám a Task Parallel Library áttanulmányozását (TaskFactory.StartNew, stb). Ezzel pofonegyszerű több szálra szétpakolni a feldolgozást.

• #1757 tototos addikt FehérHolló #1756

  Új Válasz 2011-02-23 23:12:20 #1757

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  tototos

  addikt

  válasz FehérHolló #1756 üzenetére

  hmm, lehet késő van már és fáradt vagyok. Szóval a kártya szálljában pakolom bele az üzeneteket, majd a protocol szálljában meg szedem ki, és adom tovább a függvényeknek. Ha kiürült a puffer akkor vár az üzenetre és ha bekerült egy akkor megint kiolvassa vagy nekem kell erről gondoskodni? Szóval megúszhatom a szálak közti jelzést?

• #1754 FehérHolló veterán FehérHolló #1753

  Új Válasz 2011-02-23 20:51:07 #1754

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1752 Gregorius őstag FehérHolló #1750

  Új Válasz 2011-02-23 20:20:39 #1752

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Gregorius

  őstag

  válasz FehérHolló #1750 üzenetére

  Ha itt egy termelő-fogyasztó patternt kellene megoldani, ahhoz inkább a ConcurrentQueue<T>-t kellene használni. Ld. még System.Collections.Concurrent.

• #1751 tototos addikt FehérHolló #1750

  Új Válasz 2011-02-23 20:10:04 #1751

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  tototos

  addikt

  válasz FehérHolló #1750 üzenetére

  Hali.

  Köszi a választ. Fél évet tanultam egyetemen C#-t meg többszálú alkalmazást is írtam. A kártyát is ismerem nagyjából. Írok privit.

• #1747 bod101 aktív tag FehérHolló #1745

  Új Válasz 2011-02-22 14:11:50 #1747

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bod101

  aktív tag

  válasz FehérHolló #1745 üzenetére

  Köszönöm, ott is próbálkozom.

• #1739 ArchElf addikt FehérHolló #1737

  Új Válasz 2011-02-21 08:32:38 #1739

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ArchElf

  addikt

  válasz FehérHolló #1737 üzenetére

  Console.ReadKey(false) is elég - mondjuk akkor nem árt utána egy Console.WriteLine(), hogy ne csússzon össze a szöveg a beírt betűvel.
  Persze, ha enterrel szeretné bevinni a karaktert, akkor kell a ReadLine()

  Amúgy befejezéshez is elég egy Console.ReadKey(true) - és akkor tényleg bármilyen gomb lenyomására vár, nem csak egy enterrel tud kilépni.

  AE

• #1738 FehérHolló veterán FehérHolló #1737

  Új Válasz 2011-02-20 16:12:52 #1738

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1431 x007 tag FehérHolló #1427

  Új Válasz 2010-07-09 15:02:33 #1431

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  x007

  tag

  válasz FehérHolló #1427 üzenetére

  "...,hogy miért irtózol a BackgroundWorker nélküli marshallozástól"

• #1429 Gregorius őstag FehérHolló #1427

  Új Válasz 2010-07-09 14:59:16 #1429

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Gregorius

  őstag

  válasz FehérHolló #1427 üzenetére

  Probléma, ha gyakran kell a GUI-ra írni?
  Probléma. Egyrészt azért, mert a marshallozásnak költsége van, ami visszafogja a normál működést, másrészt mert az átlag emberi agy reakcióideje legjobb esetben is tizedmásodpercekben mérhető, vagyis teljesen felesleges ezredmásodpercenként frissíteni a GUI-t, mert mire a szerencsétlen felhasználó tudatáig eljut egy adat, addigra már a hatszázzal későbbi minta is rendelkezésre áll. Vagyis 599 mintát tök fölöslegesen írnál ki.

• #1428 FehérHolló veterán FehérHolló #1427

  Új Válasz 2010-07-09 14:58:28 #1428

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1424 ArchElf addikt FehérHolló #1422

  Új Válasz 2010-07-09 14:26:20 #1424

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ArchElf

  addikt

  válasz FehérHolló #1422 üzenetére

  BGW hogy csinálja meg?

  Amúgy nekem ilyen típusú multithreading alkalmazásaim szoktak lenni:
  Form -> BGW (szálvezérlésre) -> csomó Thread (dolgozó szálak)
  Így viszonylag könnyű szétválasztani a megjelenítést a dolgozó szálaktól, nem oda integrálod be a szálvezérlést (másrészt akár form nélkül is tud futni a program).

  AE

• #1423 x007 tag FehérHolló #1422

  Új Válasz 2010-07-09 14:22:08 #1423

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  x007

  tag

  válasz FehérHolló #1422 üzenetére

  Nem értem, hogy ettől miért lenne elavult. És azt se értem, hogy miért irtózol a BackgroundWorker nélküli marshallozástól, szerintem nem egy bonyolult dolog...

  Probléma akkor lehet, ha nagyon gyakran akarsz a GUI-hoz hozzányúlni. Ilyenkor érdemes bufferezni a kéréseket marshal előtt, majd egyszerre átadni egy "nagyobb" adagot. Ez az ami egyedül gondot okozhat szvsz.

• #1421 x007 tag FehérHolló #1418

  Új Válasz 2010-07-09 13:14:10 #1421

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  x007

  tag

  válasz FehérHolló #1418 üzenetére

  Nem elavult, minden GUI framework vezérlése egyszálú. Voltak próbálkozások többszálú GUI kialakítására, de nem igazán jött össze senkinek, amolyan Failed Dream maradt.

• #1420 ArchElf addikt FehérHolló #1418

  Új Válasz 2010-07-09 12:49:42 #1420

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ArchElf

  addikt

  válasz FehérHolló #1418 üzenetére

  Ehh, konzol... mod...

  AE

• #1419 shev7 veterán FehérHolló #1418

  Új Válasz 2010-07-09 11:42:40 #1419

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  shev7

  veterán

  válasz FehérHolló #1418 üzenetére

  "Kicsit elavultnak érzem ezt a megoldást, de ez most részletkérdés"

  Ez egy erdekes tema, kifejtened?

• #1399 shev7 veterán FehérHolló #1397

  Új Válasz 2010-07-06 17:52:57 #1399

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  shev7

  veterán

  válasz FehérHolló #1397 üzenetére

  Akar bindingSource-on keresztul akar manualisan updateled a View-t csak akkor threadsafe ha az UI threadbol csinalod.

  Ha nem UI threadbol csinalod akkor marshalloznod kell (debug mode-ban erre figyelmeztet is a VS), es ugy threadsafe marad.

  x007: marshall-lal mi a baj? Thread safe is, es abbol a szalbol hivod amelyikbol akarod...

• #1398 x007 tag FehérHolló #1395

  Új Válasz 2010-07-06 17:50:31 #1398

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  x007

  tag

  válasz FehérHolló #1395 üzenetére

  WinForms elemekhez csak a GUI szálból férhetsz hozzá, különben kivétel dobódik (ki lehet kapcsolni, de ne tegyük, nem kibaszásból csinálták . Ezzel kizárva az Items propertyn keresztül való hozzáadás.

  Ha BindingSource-t használsz, akkor is kivétel dobodik, hiszen a BindingSource is egy WinForms control.
  personBindingSource.Add(new Person() { FirstName = "Jakab", LastName = "Gipsz" });
  
  ThreadPool.QueueUserWorkItem((s) =>
  {
  personBindingSource.Add(new Person() { FirstName = "John", LastName = "Smith" });
  });

  BindingList-tel viszont lehet másik szálból hozzáadni elemet. Engem ez személy szerint meglepett, mert WPF-be ilyenkor is kivétel dobódik (szerintem ez utóbbi a helyes működés).

  var collection = new BindingList<Person>();
  dataGridView1.DataSource = collection;
  
  collection.Add(new Person() { FirstName = "Jakab", LastName = "Gipsz" });
  
  ThreadPool.QueueUserWorkItem((s) =>
  {
  collection.Add(new Person() { FirstName = "John", LastName = "Smith" });
  });

  Én azt tanácsolom, hogy csak GUI szálból adj az adatforráshoz elemet. Nagy szívásokba eshetsz bele, ha nem tartod ehhez magad.

• #1396 shev7 veterán FehérHolló #1395

  Új Válasz 2010-07-06 15:42:11 #1396

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  shev7

  veterán

  válasz FehérHolló #1395 üzenetére

  konkret peldat most nem tudok csak a threadsafe reszre valaszolnek.

  ListView-t hasznaltam databinding-gal. Ha a bind-olt valtozot az UI threadbol updateled, akkor ugye minden ok. Ha masik threadbol, akkor hiaba modositod a valtozot, a ListView nem frissult. Viszont ha a valtozot modosito hivast marshallozod, akkor minden ok.

  Ha addig nem valaszol senki es nem felejtem el, este masolok be kodot ha kell...

• #1385 sunsaw tag FehérHolló #1382

  Új Válasz 2010-07-03 12:38:23 #1385

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sunsaw

  tag

  válasz FehérHolló #1382 üzenetére

  Nem tudom, irtozom az ilyen "csomagolt" megoldásoktól, mint amilynek a wrapperek, nem látom értelmét a mannaged kódolásnak, ha közben unmanaged kódokra hivatkozik a wrapper. És ha már van managed is, akkor inkább azt részesitem elönyben... jó, mondjuk egy 7zip-nél még ez talán nem akkroa probléma, de azért nem szeretek mások kodjának bugmentességében megbizni... akármikor szembe jöhet egy C-ben megirt memalloc bug egy wrappelt valamiben, és akkor "az én programom lesz szar". Szóval inkább a managed alternativákat részesitem elönyben... lehet, hogy nincs igazam!

• #1383 shev7 veterán FehérHolló #1382

  Új Válasz 2010-07-03 11:47:44 #1383

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  shev7

  veterán

  válasz FehérHolló #1382 üzenetére

  plane hulyeseget, mert shakor86 nem hulyezett le senkit

• #1206 FehérHolló veterán FehérHolló #1205

  Új Válasz 2010-02-05 15:46:33 #1206

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #1204 x007 tag FehérHolló #1203

  Új Válasz 2010-02-04 15:50:35 #1204

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  x007

  tag

  válasz FehérHolló #1203 üzenetére

  Pongyolán megfogalmazva: Az XML egy hierarchikus adatbázis, az SQL pedig relációs adatbázisokhoz van. Innentől nincsen értelme a kérdésnek . XPath segítségével lehet lekérdezéseket definiálni XML-hez.

  http://en.wikipedia.org/wiki/XPath_1.0

  A másik problémádra szerintem biztos, hogy nincsen beépített .NET osztály. Egy ilyet találtam viszont:

  http://www.sqltolinq.com/

  Nem próbáltam ki, de van egy olyan érzésem, hogy több bajod lesz vele, mintha magadtól írnád át a lekérdezéseket .

Új hozzászólás Aktív témák