Új hozzászólás Aktív témák
-
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:
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 .
-
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.
-
shev7
veterán
válasz FehérHolló #1382 üzenetére
plane hulyeseget, mert shakor86 nem hulyezett le senkit
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
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!
Windows Phone 7 Developer
-
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...
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
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.
-
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...
[ Szerkesztve ]
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
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?
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
ArchElf
addikt
válasz FehérHolló #1418 üzenetére
Ehh, konzol... mod...
AE
[ Szerkesztve ]
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
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.
-
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.
-
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
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
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.
-
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. -
x007
tag
válasz FehérHolló #1427 üzenetére
"...,hogy miért irtózol a BackgroundWorker nélküli marshallozástól"
-
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.
-
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
[ Szerkesztve ]
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
bod101
aktív tag
-
tototos
őstag
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.
-
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.
-
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.
-
tototos
őstag
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?
-
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. -
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.Thank you to god for making me an atheist
-
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.[ Szerkesztve ]
Thank you to god for making me an atheist
-
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.Thank you to god for making me an atheist
Ú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!
- Mobil flották
- Sorozatok
- exHWSW - Értünk mindenhez IS
- EA Sports WRC '23
- A fociról könnyedén, egy baráti társaságban
- Dragon Age: Origins
- PlayStation 5
- sh4d0w: Rebel Moon - Ne nézd meg!
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- További aktív témák...
- Asus ROG Phone 6 - Limited Batman Edition / BONTATLAN - 3 év gari
- Huawei Matebook D14 i5-11.gen/16GB DDR4/512GB PCIe SSD/14" Full HD IPS/Gar.:2025.10
- Rog 4070 Ti //KERESEM!!//
- Binepad BN006, programozható, mechanikus macropad, low profile Kailh Choc v1 Red switchek
- CoolerMaster ControlPad, programozható, mechanikus macropad, Gateron Red switchek