[c#] problem pri zapiranju aplikacije

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?

what he said^^

drugače pa hmm aktivni queriji? a to ciljaš na linq objecte ali normaln query na bazo

detroit je 10. avg 2011 ob 21:25 izjavil:

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?

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.

Btw KernelPanic, a se jaz prav spomnim da si že imel neke probleme z šefom? Je to ta isti šef, ali nov?

MrBrdo je 16. avg 2011 ob 11:09 izjavil:

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.

Ok, vrnil sem se z bolniske, da nadaljujemo debato. Torej ne bo slo drugace kot z thread synchronisation?