Finns det något bra sätt att kontrollera om en fil är öppen i något program?

Ja, genom att försöka öppna den.

Den kontrollen gör jag idag men jag vet inte om filen är skrivskyddad eller öppen i något program.

För att kolla om en fil är skrivskyddad kan man använda GetFileAttributes i Kernel32.dll.

Eller varför inte vb funktionen GetAttr()??? Onödigt att använda api för det.
<code>
If GetAttr("C:\autoexec.Bat") And vbReadOnly Then
Msgbox "Skrivskyddad"
Else
Msgbox "OK!"
End If
</code>

> Eller varför inte vb funktionen GetAttr()???

För att jag alltid använder api-funktionerna direkt utan att gå omvägen via VB och därför inte känner till vilka api-funktioner som VB har egna namn på.

Jag anser att man bara bör använda API anrop när det behövs pga prestanda eller att det saknas. Att använda API'er för allt är ju lite overkill.

Om filen ligger i en katalog som man bara har läsrättigheter till fungerar det inte att titta på filen om den är skrivskyddad.

Jag trodde att det finns något bra api eller så som kollar om en fil är öppen i något program.

Hej
>Att använda API'er för allt är ju lite overkill.

Konsekvensen i dina inlägg är inte så stor.Många många gånger
har du predikat optimering i koden,då med långa API haranger.
Nu plötsligt är det overkill.Klart att man skall använda API
om det finns något bra.

Tycker
Sven

Vid det tillfällen jag använder API anrop är det ofta för att anropa något som ej stöds av vb. T.Ex sätta storleken för en fil. Onödigt att skapa en ny. Om man vill krympa den. Krävs några API'er för det.

Men att använda api'er för att hämta filattributer eller t.ex. ställa om datum eller tid som du faktist rekomenderade i ett annat inläg. Där håller jag med dig. VB's funktioner är smidigare och enklare.

Det finns ju t.ex CommonDialogs kontrollen och en del andra kontroller som förenklar vissa anrop. Jag anser att CommonDialogs kontrollen är "onödig". Gör installationen onödigt stor. när det går att seklarera anropen i en modul istället.

När det gäller subclassing är komponenter en grund för en stabil utvecklings miljö.

Detta pga att komponenter brukar ofta ställa till det vi distrubetion och installation. De som t.ex arbetat med crystal reports vet. Vilket helvete det är att få e installation att fungera perfekt.

Men oftersom det flesta API anrop är föråldrade i .NET så bör vi igentligen inte lägga ned så stor tid på att lära oss alla.