[C#] Jak obsłużyć skróty z pustym TargetPath w IWshRuntimeLibrary?

Witam

Mam taki kod do sprawdzania poprawności skrótów:

Jednak jest problem z niektórymi skrótami - shortcut.TargetPath jest wtedy ciągiem pustym.
Dzieje się tak ze skrótami, które eksplorator wyświetla w ten sposób (patrz "Element docelowy"):


Jak to "rozgryźć"?

w tym konkretnym przypadku lokalizacja rozpoznawana jest prawdopodobnie na podstawie rozszerzenia/typu.

Generalnie przeszukiwane są katalogi ze zmiennej PATH

Dżyszla napisał:

w tym konkretnym przypadku lokalizacja rozpoznawana jest prawdopodobnie na podstawie rozszerzenia/typu.

Rozszerzenie to zawsze lnk...

Dżyszla napisał:

Generalnie przeszukiwane są katalogi ze zmiennej PATH

Generalnie nie łapię.

W zmiennej path - nie PATH - jest przekazywana pełna ścieżka do pliku ".lnk" (łącznie z nazwą pliku).
Mogę prosić o jakiś przykład, szczegóły, czego szukać, aby sprawdzić poprawność takiego skrótu?

1. Rozszerzenia zlinkowanego pliku, a nie linku.
2. Wielkość liter zmiennych systemowych nie ma znaczenia - set path i set PATH zwrócą to samo.

Ostatniego akapitu ja nie rozumiem zupełnie. Zmienna PATH zawiera listę katalogów, które są przeszukiwane do odnalezienia pliku, który wywoływany jest bez podania katalogu oraz nie znajduje się w katalogu roboczym. Poprawność takiego skrótu, który właśnie nie podaje katalogu można sprawdzić przeglądając wszystkie katalogi ze zmiennej PATH (kolejność też ma znaczenie tak na marginesie).
Przy okazji, Windows NT (chyba) wprowadził taką zmienną, jak PATHEXT, która wskazuje rozszerzenia plików, jakie mają być przeszukiwane w katalogach ze zmiennej PATH.

Po co komu PATH skoro nawet nie wiadomo czego szukać?
Rozszerzenie zlinkowanego pliku (razem z nazwą) to właśnie coś o co pyta autor tego tematu - jak to odczytać, bo w obiekcie klasy WshShortcut nie ma NIC. Ani ścieżki, ani nazwy, ani rozszerzenia.

I jestem dalej w punkcie wyjścia.
Ścieżkę folderu mogę sobie znaleźć w zmiennej systemowej Path - ale skąd wiedzieć, która jest właściwa, jeśli były by dwie ścieżki z docelowym plikiem, wziąć pierwszą?

Skąd odczytać jakiego pliku mam szukać?

Na przykład otwierając "Opcje zasilania" zostaje uruchomione:

Jak to wszystko odczytać?

Dodano po 27 [minuty]:

Otworzyłem ten skrót w notatniku i...

Cytat:

L
 Ŕ F
"
 PŕOĐ ę:i˘Ř +00ť . ě!ę:i˘Ý +00ťř 6˙˙˙ j ! 1 C : \ W I N D O W S \ s y s t e m 3 2 \ p o w e r c f g . c p l O p c j e z a s i l a n i a K o n f i g u r u j u s t a w i e n i a o s z c z 
d z a n i a e n e r g i i d l a t e g o k o m p u t e r a .

Czyli wygląda na to, że z tą zmienną Path to było nie trafione...

PanBo - a skąd taki wniosek? Ja rozumiem, że aplikacja miała sprawdzać istnienie elementu docelowego. A poza tym WIADOMO gdzie szukać - w katalogu roboczym, jak nie ma to w pierwszym katalogu zmiennej PATH, jak nie ma to w drugim katalogu zmiennej PATH itd. Nie ma żadnych niewiadomych.

LED5W - tak, bierzesz pierwszą w przypadku istnienia pliku w dwóch z podanych ścieżek.

Co do paneli sterowania - ich uruchomieniem zajmuje się plik DLL, którego funkcję wywołuje program rundll32. Zaś to, że on jest skojarzony z danym rozszerzeniem to już kwestia systemu Windows i wpisu w kluczu HKCL.

Do czytania linków posługuj się funkcjami systemowymi i na nich bazuj, bo nigdy nie wiadomo, jak dany system zapisuje linki.

(Zrobiłem mały test i faktycznie system zawsze podstawia ścieżkę - ale przed XP mogło tak nie być).

Jak to nie ma niewiadomych? Funkcje systemowe zwracają puste stringi w przypadku np skrótów z panelu. Jak dla mnie to niewiadoma, bo własny loader plików *.lnk to rozwiązanie paskudne.

Temat mnie zainteresował i trochę pownikałem, co prawda celu nie osiągnąłem ale może się przyda to co znalazłem:
1. Dodając referencję COM na "Microsoft Shell Controls And Automation" uzyskasz dostęp do interfejsu ShellLinkObject i tym samym do metody Resolve, która próbuje znaleźć cel skrótu i jeśli to się nie powiedzie wyświetla systemowy komunikat. Niestety, o ile komunikat można wyłączyć to nie udało mi się z poziomu kodu dojść do informacji czy ten skrót udało się rozwiązać czy nie, mimo że MSDN twierdzi że funkcja to zwraca. Jednak wykorzystanie mechanizmu Resolve byłoby pewnie najlepsze (do weryfikacji poprawności skrótów).
2. Po dodaniu do projektu kodu stąd uzyskuje się dostęp do metody IShellLink::GetPidList zwracającej wartość która wydaje się kluczem do sukcesu (jednak nie udało mi się na szybko wyciągnąć z tego nic sensownego)

Pozdr.

PanBo napisał:

Temat mnie zainteresował i trochę pownikałem

Fajnie.

2. Chodzi o ten ostatni kod? Bo nie widzę tam GetPidList.

Coś będę z tym kombinował. Jednak byłbym bardzo wdzięczny za działający przykład.

Jakoś sobie z tym nie radzę.
PanBo. Mógłbyś podać kody, których używałeś do testów?