Widziałem inny temat i mam inny problem. Proces się rozpoczyna (zobaczyłem w menedżerze zadań), ale folder nie otwiera się na moim ekranie. Co jest nie tak?
System.Diagnostics.Process.Start("explorer.exe", @"c:\teste");
Widziałem inny temat i mam inny problem. Proces się rozpoczyna (zobaczyłem w menedżerze zadań), ale folder nie otwiera się na moim ekranie. Co jest nie tak?
System.Diagnostics.Process.Start("explorer.exe", @"c:\teste");
Odpowiedzi:
Czy upewniłeś się, że folder „ c:\teste
” istnieje? Jeśli tak się nie stanie, eksplorator otworzy się, pokazując domyślny folder (w moim przypadku „ C:\Users\[user name]\Documents
”).
Aktualizacja
Wypróbowałem następujące odmiany:
// opens the folder in explorer
Process.Start(@"c:\temp");
// opens the folder in explorer
Process.Start("explorer.exe", @"c:\temp");
// throws exception
Process.Start(@"c:\does_not_exist");
// opens explorer, showing some other folder)
Process.Start("explorer.exe", @"c:\does_not_exist");
Jeśli żaden z nich (no cóż, poza tym, który zgłasza wyjątek) nie działa na twoim komputerze, nie sądzę, że problem leży w kodzie, ale w środowisku. W takim przypadku spróbuję jednego (lub obu) z poniższych:
Process.Start(path)
aktywuje okno (może migać tylko na pasku zadań, nie jest przenoszone na wierzch); explorer.exe
+ parametr otwiera nowe okno zawsze z przodu (ale wielokrotnie to samo okno). Więc obaj mają zastrzeżenia.
Process.Start(@"c:\temp")
należy używać ostrożnie. Jeśli c:\temp.com
istnieje, c:\temp.com
zamiast tego zostanie otwarte wywołanie funkcji . Więcej informacji można znaleźć na forums.iis.net/p/1239773/2144186.aspx .
Process.Start(@"c:\temp")
to spowodować otwarcie innego folderu, takiego jak C:\temp.exe
lub C:\temp.cmd
. Zobacz ten problem, w którym sam VS wykazuje błędne zachowanie . Możesz tego uniknąć, używając explorer.exe
wariantu lub (lepiej, IMO) zawsze dołączając plik Path.DirectorySeparatorChar
. Na przykład Process.Start(@"C:\temp\")
.
Dla kompletności, jeśli wszystko, co chcesz zrobić, to otworzyć folder, użyj tego:
System.Diagnostics.Process.Start(new System.Diagnostics.ProcessStartInfo() {
FileName = "C:\\teste\\",
UseShellExecute = true,
Verb = "open"
});
Upewnij się, że nazwa_pliku kończy się Path.DirectorySeparatorChar
na, aby jednoznacznie wskazywała na folder. (Dzięki @binki.)
To rozwiązanie nie będzie działać w przypadku otwierania folderu i wybierania elementu, ponieważ nie wydaje się, aby to oznaczało.
C:\teste.exe
lub C:\teste.cmd
istnieje, Eksplorator otworzy się do tego innego folderu zamiast tego, który zamierzałeś. Aby tego uniknąć, możesz dołączyć Path.DirectorySeparatorChar
do ścieżki. Zobacz, jak sam VS popełnia ten sam błąd .
Verb = "select"
, ale niestety nie możesz. Niezależnie od tego, świetna odpowiedź!
Verb = "open"
nie było konieczne. (Testowane w systemie Windows, inne systemy operacyjne mogą się różnić.)
.Verbs
właściwości pod adresemProcessStartInfo
( docs.microsoft.com/en-us/dotnet/api/… )
Używasz symbolu @, który eliminuje potrzebę ucieczki przed ukośnikami odwrotnymi.
Usuń znak @ lub zamień \\ na \
Nie potrzebujesz podwójnego odwrotnego ukośnika, gdy używasz ciągów bez znaku zmiany znaczenia:
System.Diagnostics.Process.Start("explorer.exe",@"c:\teste");
Powinieneś użyć jednego z System.Diagnostics.Process.Start()
przeciążeń. To całkiem proste!
Jeśli nie umieścisz nazwy pliku procesu, który chcesz uruchomić ( explorer.exe
), system rozpozna go jako prawidłową ścieżkę do folderu i spróbuje dołączyć go do już działającego procesu Eksploratora. W takim przypadku, jeśli folder jest już otwarty, Explorer nic nie zrobi.
Jeśli umieścisz nazwę pliku procesu (tak jak to zrobiłeś), system spróbuje uruchomić nową instancję procesu, przekazując drugi ciąg jako parametr. Jeśli ciąg jest prawidłowym folderem, jest otwierany w nowo utworzonym procesie, jeśli nie, nowy proces nic nie zrobi.
W każdym razie nie wiem, jak nieprawidłowe ścieżki folderów są traktowane przez proces. Użycie System.IO.Directory.Exists()
powinno wystarczyć, aby to zapewnić.
Path.DirectorySeparatorChar
. W przeciwnym razie, jeśli istnieje folder o tej samej nazwie, ale .cmd
lub .exe
ewentualnie z innymi przyrostkami, Eksplorator otworzy się do tego innego folderu - lub jeśli są to pliki wykonywalne lub skrypty, uruchomi je zamiast otwierania folderu zgodnie z zamierzeniami.
Użyj przeciążonej wersji metody, która przyjmuje wystąpienie ProcessStartInfo i ustaw właściwość ProcessWindowStyle na wartość, która działa dla Ciebie.
Uciekasz przed ukośnikiem odwrotnym, gdy znak „at” robi to za Ciebie.
System.Diagnostics.Process.Start("explorer.exe",@"c:\teste");
System.Diagnostics.Process.Start("explorer.exe",@"c:\teste");
Ten kod działa dobrze w środowisku VS2010 i poprawnie otwiera folder lokalny, ale jeśli hostujesz tę samą aplikację w usługach IIS i spróbujesz otworzyć, na pewno się to nie powiedzie.
Właśnie miałem ten problem i dowiedziałem się, dlaczego. mój powód nie jest tutaj wymieniony, więc każdy, kto napotka ten problem, i żaden z nich go nie naprawia.
Jeśli uruchomisz Visual Studio jako inny użytkownik i spróbujesz użyć Process.Start, będzie on działał w tym kontekście użytkownika i nie zobaczysz go na ekranie.
Dziwne.
Jeśli nie może znaleźć explorer.exe, powinieneś otrzymać wyjątek. Jeśli nie może znaleźć folderu, powinien nadal otworzyć jakiś folder (np. Moje dokumenty)
Mówisz, że w menedżerze zadań pojawia się kolejna kopia Eksploratora, ale nie możesz jej zobaczyć.
Czy to możliwe, że otwiera się poza ekranem (np. Inny monitor)?
A może przypadkiem robisz to w usłudze nieinteraktywnej?
Czy otwiera się poprawnie po uruchomieniu „explorer.exe c: \ teste” z menu Start? Jak długo tego próbujesz? Widzę podobne zachowanie, gdy mój komputer ma wiele procesów i kiedy otwieram nowy proces (ustawia np. IE) .. uruchamia się w menedżerze zadań, ale nie pojawia się w interfejsie. Czy próbowałeś ponownie uruchomić?
Poniższy kod powinien otwierać nowe wystąpienie eksploratora
class sample{
static void Main()
{
System.Diagnostics.Process.Start("explorer.exe",@"c:\teste");
}
}
Czy podczas próby masz uruchomionych wiele aplikacji? Czasami napotykam dziwne zachowanie w pracy, ponieważ w moim systemie zabrakło uchwytów GDI, ponieważ mam otwartych wiele okien (nasze aplikacje używają dużo).
Kiedy tak się dzieje, okna i menu kontekstowe nie pojawiają się długo, dopóki coś nie zamknę, aby zwolnić niektóre uchwyty GDI.
Domyślny limit w XP i Vista to 10000. Nie jest niczym niezwykłym, że moje DevStudio ma 1500 uchwytów GDI, więc jeśli masz kilka otwartych kopii Dev Studio, może je dość szybko pochłonąć. Możesz dodać kolumnę w TaskManager, aby zobaczyć, ile uchwytów jest używanych przez każdy proces.
Istnieje modyfikacja rejestru, którą możesz zrobić, aby zwiększyć limit.
Więcej informacji można znaleźć pod adresem http://msdn.microsoft.com/en-us/library/ms724291(VS.85).aspx
System.Diagnostics.Process.Start("explorer.exe",@"c:\teste");
Po prostu zmień ścieżkę lub zadeklaruj ją w pliku string