Forum » Programiranje » [c#] problem pri zapiranju aplikacije
[c#] problem pri zapiranju aplikacije
KernelPanic ::
Spostovani!
Spet bi vas prosil za pomoc in zanima me, kako bi se dalo resiti naslednji problem: Imam program, ki iz baze bere neke recorde (nic posebnega), sedaj dela kot svicarska ura (seveda z vaso pomocjo) in te podatke bere v BackgroundWorker threadu. V glavnem oknu GUI dela imam gumb "Zapri", ki konca aplikacijo. Ali je mozno, ko uporabnik stisne ta gumb, da se z zapiranjem aplikacije pocaka toliko casa, da se vsi aktivni query-ji zakljucijo in da ob zaprtju ne dobim vec raznih errorjev?
S spostovanjem in hvala za pomoc,
M.
Spet bi vas prosil za pomoc in zanima me, kako bi se dalo resiti naslednji problem: Imam program, ki iz baze bere neke recorde (nic posebnega), sedaj dela kot svicarska ura (seveda z vaso pomocjo) in te podatke bere v BackgroundWorker threadu. V glavnem oknu GUI dela imam gumb "Zapri", ki konca aplikacijo. Ali je mozno, ko uporabnik stisne ta gumb, da se z zapiranjem aplikacije pocaka toliko casa, da se vsi aktivni query-ji zakljucijo in da ob zaprtju ne dobim vec raznih errorjev?
S spostovanjem in hvala za pomoc,
M.
_Dormage_ ::
Offtopic, kako si potem rešil backgroundWorkerja iz prejšnje teme?
Primitivna rešitev pojma nimam, če je sploh primerno.
Ko klikne na gumb zapri pokličeš funkcijo, ki čaka dokler thread ne konča querijev in potem zapre.
Mogoče malenkost potratno, ampak predvidevam, da query-ji ne trajajo dosti.
Kako pa sedaj dela izhod?
Ubiješ process ali prvo backgroundWOrker-ja pa potem process?
Primitivna rešitev pojma nimam, če je sploh primerno.
Ko klikne na gumb zapri pokličeš funkcijo, ki čaka dokler thread ne konča querijev in potem zapre.
Mogoče malenkost potratno, ampak predvidevam, da query-ji ne trajajo dosti.
Kako pa sedaj dela izhod?
Ubiješ process ali prvo backgroundWOrker-ja pa potem process?
Ericssony ::
Dodaj field tipa bool, ki določa ali so se vse poizvedbe končale. Potem pa v FormClosing dogodku z while zanko preverjaj ta field.
detroit ::
what he said^^
drugače pa hmm aktivni queriji? a to ciljaš na linq objecte ali normaln query na bazo
drugače pa hmm aktivni queriji? a to ciljaš na linq objecte ali normaln query na bazo
Skero
Vesoljc ::
okno "pohajdas", zadaj pa počakas toliko da se vse konča, nato pa še terminate
Abnormal behavior of abnormal brain makes me normal...
KernelPanic ::
what he said^^
drugače pa hmm aktivni queriji? a to ciljaš na linq objecte ali normaln query na bazo
Ne ne, znotraj BackgroundWorker-ja mecem query-je, da dobim potrebne podatke, ki jih potem prikazujem v GUI. In ko uporabnik stisne gumb "Zapri", se vcasih pred zaprtjem pojavijo exceptions glede "aktivnosti", ki se niso koncane.
P.S.: Ni nobenega property-ja v Connection classu, ki bi povedal, ali je trenutno promet na connection-u ali ne?
KernelPanic ::
Offtopic, kako si potem rešil backgroundWorkerja iz prejšnje teme?
Primitivna rešitev pojma nimam, če je sploh primerno.
Ko klikne na gumb zapri pokličeš funkcijo, ki čaka dokler thread ne konča querijev in potem zapre.
Mogoče malenkost potratno, ampak predvidevam, da query-ji ne trajajo dosti.
Kako pa sedaj dela izhod?
Ubiješ process ali prvo backgroundWOrker-ja pa potem process?
BackgroundWorkerja sem resil tako, da sem se 3x prebral dokumentacijo iz msdn ter vase nasvete, nato se spravil programirati. Timerja se nisem implementiral, ostalo pa lepo dela. Mi pa sef tezi, da naj neham bluzit z threadi in da me ima poln k. in naj ne kompliciram, vendar jaz trdim, da je zavoljo morebitnih nadgradenj (ta naprava, iz katere pobiram podatke, vraca vec kot 500 podatkov razlicnih tipov in vec podatkov hoces, vecji delay je), da je to nujno speljati preko niti, da je gui neobremenjen, vendar moje razlage ne sprejema, pa me zanima, ali imam prav ali ne?
Da se vrnem na tvoja vprasanja, nanasajoc na to temo:
1) query-ji so kratki
2) Izhod dela tako, da ko pritisnem Close, enostavno poklicem TableAdapter.Connection.Close() in nato Application.Exit()
Bi bilo smiselno query-je nastavatiti na sihnrone, sedaj so asinhroni?
Lp,
M.
MrBrdo ::
Raje ne ker lahko negativno vpliva na uporabniško izkušnjo, neglede na to da so kratki (lahko je recimo več kratkih eden za drugim). Pa škoda bi bilo časa, ki si ga porabil da si vse asinhrono naredil Pa lahko se zgodi, da se povezava z bazo prekine itd, potem pa bo vse skupaj zamrznilo za nekaj časa. Edino če bi res šel gledat čase in če si lahko prepričan da so npr. pod 50ms in da jih nimaš naenkrat več kot ene par (v glavnem da skupaj traja pod 100ms), potem bi načeloma lahko delal tudi sinhrono da si poenostaviš programiranje. V nobenem primeru pa verjetno ni kakšne dejanske prednosti pri sinhronem, razen lažjega programiranja.
Jaz sem imel enkrat ravno obraten problem, ko sem nekje delal in smo prepisovali vse iz sinhronega delovanja v asinhrono, ker je vmesnik delal obupno počasi in se je stalno zatikalo, in so se potem bog ve koliko časa zafrkavali da so to zrihtali, pa še mudilo se jim je, ker so hoteli ravno dat public. Vsekakor se splača asinhrono po mojem, če ne hekaš lih programčka za domačo uporabo.
Jaz sem imel enkrat ravno obraten problem, ko sem nekje delal in smo prepisovali vse iz sinhronega delovanja v asinhrono, ker je vmesnik delal obupno počasi in se je stalno zatikalo, in so se potem bog ve koliko časa zafrkavali da so to zrihtali, pa še mudilo se jim je, ker so hoteli ravno dat public. Vsekakor se splača asinhrono po mojem, če ne hekaš lih programčka za domačo uporabo.
MrBrdo
Zgodovina sprememb…
- spremenilo: MrBrdo ()
_Dormage_ ::
To, da imaš program večnitno narjen nikakor ni slabo.
Sploh pa je to značilno za grafiko in logiko, da sta ločeni zaradi tekočega delovanja GUI-ja.
Obraten primer je androidova default aplikacija za upravljanje z aplikacijami.
Butasta kot je ne nalaga slikic v svojem threadu zato moraš za nemotemo scroll-anje počakat, da se zloadajo vse ikonce.
A zapiranje aplikacije si sedaj poštimal.
P.S
Tvoj šef je iz stroke?
Sploh pa je to značilno za grafiko in logiko, da sta ločeni zaradi tekočega delovanja GUI-ja.
Obraten primer je androidova default aplikacija za upravljanje z aplikacijami.
Butasta kot je ne nalaga slikic v svojem threadu zato moraš za nemotemo scroll-anje počakat, da se zloadajo vse ikonce.
A zapiranje aplikacije si sedaj poštimal.
P.S
Tvoj šef je iz stroke?
MrBrdo ::
Btw KernelPanic, a se jaz prav spomnim da si že imel neke probleme z šefom? Je to ta isti šef, ali nov?
MrBrdo
KernelPanic ::
KernelPanic ::
Raje ne ker lahko negativno vpliva na uporabniško izkušnjo, neglede na to da so kratki (lahko je recimo več kratkih eden za drugim). Pa škoda bi bilo časa, ki si ga porabil da si vse asinhrono naredil Pa lahko se zgodi, da se povezava z bazo prekine itd, potem pa bo vse skupaj zamrznilo za nekaj časa. Edino če bi res šel gledat čase in če si lahko prepričan da so npr. pod 50ms in da jih nimaš naenkrat več kot ene par (v glavnem da skupaj traja pod 100ms), potem bi načeloma lahko delal tudi sinhrono da si poenostaviš programiranje. V nobenem primeru pa verjetno ni kakšne dejanske prednosti pri sinhronem, razen lažjega programiranja.Ok, vrnil sem se z bolniske, da nadaljujemo debato. Torej ne bo slo drugace kot z thread synchronisation?
Jaz sem imel enkrat ravno obraten problem, ko sem nekje delal in smo prepisovali vse iz sinhronega delovanja v asinhrono, ker je vmesnik delal obupno počasi in se je stalno zatikalo, in so se potem bog ve koliko časa zafrkavali da so to zrihtali, pa še mudilo se jim je, ker so hoteli ravno dat public. Vsekakor se splača asinhrono po mojem, če ne hekaš lih programčka za domačo uporabo.
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | C# .net class vs .net core async await issueOddelek: Programiranje | 1703 (1463) | detroit |
» | C# threadanje in guiOddelek: Programiranje | 783 (674) | darkolord |
» | Vprasanje glede koncepta programa [c#]Oddelek: Programiranje | 2070 (1812) | _Dormage_ |
» | [c#] Vprasanje glede BackGroundWorker classa in spreminanja gui elementaOddelek: Programiranje | 793 (719) | Ericssony |
» | C# BackgroundWorker Class problemOddelek: Programiranje | 1267 (1223) | hendriks |