Sikre at kode udføres uanset hvordan program lukkes

Du kan ikke fange hvis de lukker *processen* på den måde - hvis de lukker jobbet får du en WM_CLOSE som du dermed håndtere som når programmet lukkes normalt, men du kan ikke forhindre det hvis det er processen der lukkes.

http://blogs.msdn.com/oldnewthing/archive/2004/07/22/191123.aspx

Ligeledes kan du jo heller ikke sikre dig mod at strømmen går, eller systemet bluescreener og genstarter - så vil din kode heller ikke blive kørt.

Hvad skal du helt præcist bruge det til? Der er højst sandsynligt en bedre måde at opnå det du vil, men det er jo svært at sige med sikkerhed når vi ikke ved hvad meningen med det er.

hrc> Kan du ikke på en eller anden måde, lave en update af login evt. hvert 5. minut. Ved næste login kan du så tjekke hvor lang tid siden der har været en update, og evt. fjerne flaget såfremt den har hængt mere end 15 min. eller lign. ?

pidgeot: Jeg gik lidt i selvsving over try-finally konstruktionen og tænkte at måske var der et eller andet der altid blev udført - uanset hvad.

Jeg troede i øvrigt problemstillingen var klar nok. Der er loginprompt til programmet og når man er logget ind ét sted, skal andre ikke kunne logge ind med samme initialer andetsteds. Derfor sætter jeg @@SPID'et i min bruger-tabel (logning og den slags kan derved få fat i rette brugerID). Samtidigt skulle dette også låse for andre, men da SPID ikke tæller fortløbende men genbruger numrene, kan dette ikke bruges.

Det er lang tid siden jeg sidst har set "BSoD", nu har vi også måtte trækkes med den ... i knap 15 år.

Jeg kan egentlig godt lide bensons forslag da det er let at koble på min brugerklasse, som en tråd der løbende opdaterer login - men - tråden skal nok loope ret tit for at have virkning, for hvis et program dør klikker man straks på ikonet igen, ikke? Medmindre jeg opdaterer med 5s mellemrum vil det ikke virke.

En variant af bensons forslag er en usynlig programinstans (tråd eller service) der ikke hænger på hovedprogrammet. Her tjekkes løbende om programmets handle er validt. Hvis det er væk nulstilles flaget (og tråden/servicen terminerer selv). Mod strømsvigt er der stadig ikke nogen løsning.

Nå ja. Har lige fundet ud af et timestamp er en fortløbende tæller - ikke et ... timestamp sådan som navnet ellers svagt indikerer.

Desuden har min variant af bensons forslag samme svaghed som hvis man opdaterede tabellen direkte.

hvad med at vise en dialog der siger at brugeren er logget på på en anden maskine ( evt. maskinen ip ) og så spørge om man vil ligge ind ( og derved logge den anden af )

Hej igen hrc>
Det kan godt være jeg er galt på den, men... hvis programmet afsluttes, og du hurtig starter det igen, vil det så være et problem at antage at du stadig er logget ind ? Vil det give problemer for programmet. Du kan vel se hvem det er der har låst tabellen, og at det er denne "ejer" der har startet sit program igen (og dermed skal have adgang igen), og updaten igen kører upåklageligt.

PS! Jeg har ikke fulgt linket for at se hvad det er, tænkte bare lige på denne løsning. ;-) Måske for simpelt og uhåndterbart :-o

benson: Det ligger i brugen af MSSQL's @@SPID der returnerer første ledige tal fra 50 og opefter. Jeg kan derfor ikke vide om det SPID der er gemt i bruger-tabellen er det som brugeren havde lige før.

martin: Jeg har allerede denne dialog, men vil gerne udtænke en måde at begrænse dens fremkomst. Hvis jeg registrerer brugerens IP (har overvejet dette) kan jeg s.... højt og flot på værdien af SPID

Kombinationen af bensons og dit forslag er nok vejen frem. En løbende opdatering af login-flaget og en registrering af IP-nummeret. Derved kan jeg vist fange det meste.

Jeg prøver videre ad den vej. Læg et svar benson og martin.

Helt forkromet burde alt det her ske via Active Directory, men det er en verden jeg ikke har lyst at bevæge mig overi.

Kan jeg godt forstå ( AD ) :)

hrc> Ahaaa.... (lys) så kan jeg godt se det bliver svært :(

held og lykke med projektet. Pointene springer jeg over ;)

Havde ellers lagt lidt flere af til dig og Martin. Som brødre I deles, Martin tager det hele(s).

hehe :)