Hej, Du skulle kunna prova att bryta ut koden som ska spara tillbaka filen i databasen genom att prenumerera på händelsen att applikationen är avslutad, tex: Hej Johan, Hmm, jag har laborerat vidare med detta och jag undrar om jag inte lyckats att lösa detta genom att ange en parameter till WinWord.exe. Tackar för infon, ska testa lite med det och återkommer. Ser dock ett litet problem med att använda parametrar och det är att man måste använda sig av olika parametrar för olika typer av program eftersom samma problem uppstår oavsett om det är Word-filer eller PDF-filer man öppnar. Tyvärr är det nog så att det beror lite på hur de applikationer som du vill starta flera processer av är skrivna. Prova exempelvis med enkla "notepad.exe", där får jag inte det här problemet verkar det som. ja det verkar stämma. Kan kanske bli lite knivigt att använda sig av denna metod. Håller på att testa ett annat spår där tanken är att programmet ska kontrollera om filen används mha ngt Windows API. Verkar som om informationen går att hämta från NtQuerySystemInformation (ntdll.dll). Dock har jag inte kommit på hur jag anroppar den dll:en än. Hmm, har inte kollat vad den metoden gör, men det känns inte som om att du kommer kunna "lura" alla eventuella applikationer som är skrivna för att utnyttja samma session och jobba med "modala" dokument istället för nya sessioner, att förändra sitt uppträdande. Ok... jag får undersöka detta närmare... återkommer då jag hittat ngt lösning (om det nu finns ngn) Tackar för hjälpen :D Kan du inte ;vervaka filen, se om det finns n[gra ;ppna filhandtag till filen. N'r filhandtagen st'ngs kan du kontrollera om filen har 'ndrats och i s[ fall fr[ga anv'ndaren om de vill spara f;r'ndringarna. Har du ngn kod för hur man kollar om det finns filhandtag till en fil? Fungerar detta även för t.ex. notepad som enbart verkar öppna filen läsa av innehållet och sen stänga den igen, eller håller även notepad ett filhandtag till filen hela tiden? Notepad håller det nog inte. Och även om notepad skulle göra det så gör inte min applikation arnepad det.Öppna program mha Process.Start()
Har en liten applikation som lagrar olika typer av dokument i en databas. Då användaren ska titta på ett dokument skapar jag en ny tråd som hämtar upp dokumentet det från databasen och sparar ner det temporärt på hårddisken. Sen anropas Process.Start() för att öppna filen med det program den är associerad med. Därefter körs Process.WaitForExit() för att avvakta tills dokumentet stängs. Slutligen sparar tråden ner dokumentet i databasen igen.
Funkar bra så länge man inte öppnar 2 dokument som är associerade med samma applikation. Problemet uppstår då jag öppnar 2 filer (t.ex. 2 word-dokument). Det som händer är att Process.WaitForExit() inte returnerar en ny process för det andra dokumentet, utan funktionen återanvänder den befintliga word-processen för att öppna det andra dokumentet. Detta medför att Process.WaitForExit() inte stannar utan programmet exekverar vidare.
Ngn som har ngn lösning på detta. Nedan är koden för den tråd som skapas varje gång användaren vill öppna ett nytt dokument:
delegate void OpenDocument(int iDokumentID);
private void OpenDocumentHandler(int iDokumentID)
{
// …
// Hämta dokument från database och spara ner på disk
//…
Process oProcess;
// öppna det med associerat program
oProcess = new System.Diagnostics.Process();
oProcess.StartInfo.FileName = "\"" + sDocumentPath + iDokumentID + "." + oDokumentProfil.Filtyp_str + "\"";
oProcess.Start();
// vänta på att användaren ska stänga dokumenet
oProcess.WaitForExit();
//..
// Skriv tillbaka till filen och spara ner i databsen
//..
}Sv: Öppna program mha Process.Start()
<code>
...
{
Process proc = new Process();
...
proc.EnableRaisingEvents = true;
proc.Exited += new EventHandler(proc_Exited);
proc.Start();
}
static void proc_Exited(object sender, EventArgs e)
{
// Spara dokumentet här
}
</code>Sv:Öppna program mha Process.Start()
Jag testade ditt förslag men tyvärr så uppstår samma problem som tidigare. Om man har en wordprocess igång sedan tidigare så återanvänds denna process och Process.Start(); returnerar false. Detta betyder att en ny process inte skapats och då kan av naturliga skäl inte händelsen "oProcess.Exited += new EventHandler(OnExit);" kopplas på ngn process (eftersom det inte skapats ngn). Lite luddigt beskrivet kanske men jag hoppas att det går att förstå. Skulle vara bra om det gick att hitta ngn lösning som gör att en ny process startas varje gång oavsett om det redan finns en igång.Sv: Öppna program mha Process.Start()
<code>
Process proc = new Process();
proc.StartInfo = new ProcessStartInfo("winword.exe");
proc.StartInfo.Arguments = "/w";
</code>
Utmaningen är dock att den flaggan öppnar word med ett tomt dokument, men det finns fler flaggor för dig att pröva på på följande sida: http://support.microsoft.com/kb/210565/
Hör av dig igen!Sv:Öppna program mha Process.Start()
Sv: Öppna program mha Process.Start()
Sv:Öppna program mha Process.Start()
Sv: Öppna program mha Process.Start()
Hur många olika filtyper gäller det och kan du förändra beteendet i applikationen istället?
Om det nu är så att du vill att dina använda ska genom att trycka på en knapp bara automatiskt ladda hem en fil lokalt, uppdatera den med en annan applikation och sedan när den applikationen stängs automatiskt ladda upp förändringarna igen, så tror jag inte ens att det är löst i exempelvis SharePoint utan där har de funktionerna separerats. Ladda hem en fil - Uppdatera - Ladda upp en fil
MvhSv:Öppna program mha Process.Start()
Sv: Öppna program mha Process.Start()
Sv:Öppna program mha Process.Start()
Sv: Öppna program mha Process.Start()
Glöm, glöm, glöm. Minns ni inte tidigare diskussion?
Du kan aldrig få en generell 100%-ig lösning på det sättet. Du har följande val:
1. Du kan kontinuerligt kontrollera filer. Osäker på om det går att göra utan pollning, och då har du ändå inte 100%. Nästan dock. Detta kräver att ditt program kör en speciell övervakning, och kräver rimligtvis kod på ganska låg nivå. Det är inte omöjligt att du får lattja med lite filkontrollblock (gissar att det heter så även i Windows).
2. Du kan, om du har kontroll över alla inblandade applikationer, konstruera ett protokoll att arbeta mellan.
3. Om du har ett litet antal specifika applikationer med specifika versioner så har du eventuellt möjlighet att specialstyra beteendet för varje program.
4. Du kan försöka med en kombination. Det blir dock besvärligt, och framförallt benäget att ge konstiga val.
eller så låter du användarens filsystem och applikationer arbeta som de gör, och istället göra något av följande:
1. Skapa egna applikationer för att ändra filer (ingen höjdarlösning).
2. Låta bli alltihopa och istället låta användaren säga till när filen är klar och du laddar då upp den.
3. Låta bli alltihopa och låta filsystemet vara det du utgår ifrån. Allt sparas lokalt på en dator. När någon begär en fil så levererar du det från datorn i det skick det just då befinner sig i.
4. Skicka ut information till alla som har öppnat filen om att ändringar sker.
Det här är befintliga problem hos nuvarande distribuerade filsystem, anta hellre en policy (alt. 2, 3 eller 4 här) och stå sen för den.
Det är min definitiva övertygelse.