Jak w Delphi programowo pobrać ścieżkę dostępu do modułu?

Witam.
czy jest możliwość aby programowo po skompilowaniu do exe pobrać ścieżkę dostępu do modułu? Np. jestem w module

OsobaForma.pas

(dla upuszczenia) i chcę zrobić procedurę

Sciezka:= SciezkaModulu(OsobaForma.pas); 

tak, żeby po kompilacji i uruchomieniu polecenia w exe pobrało mi tą ścieżkę, obojętnie jaką czy pełną czy względną.
Mógłbym oczywiście zrobić coś takiego:

Sciezka:= ExtractFilePath(Application.ExeName) +'lib_dane\lib_osoby\OsobaForma.pas';

Ale przy pracy nad innym projektem i po przeniesieniu modułu do innego podfolderu musiałbym pamiętać o zmianie ścieżki inaczej nie zadziała. Wolałbym nie zmieniać tego w każdym module w jakim mi jest to potrzebne, bo to by było przy wszystkich formach, a wiec nie małe ilości.
Ma ktoś jakiś pomysł?
PS Google nie chce pomóc, albo nie trafiłem na odp link.

Nie wiem po co Ci dostęp do plików *.pas, skoro uruchomiony program to przecież skompilowane moduły, więc w ten sposób dynamicznie nie będziesz mógł wpływać na działanie programu; Znowu zakładasz o tym wątek, jakbyś nadal nie mógł zrozumieć, że Delphi to nie jest język skrytowy (chyba że potrzebujesz to do czegoś innego);

Z tego co mi wiadomo nie ma jakiejś przewidzianej do tego metody; Modułami zarządza środowisko, więc musiałbyś pogrzebać np. w jego kodzie i sprawdzić jak to robi, ale w Delphi kodu nie masz i mieć nie będziesz; Pod Lazarusem można by sprawdzić jak zarządza się modułami w projekcie, ale dostępu do tych mechanizmów z poziomu projektu najpewniej nie uzyskasz; Chyba że jakimiś hakierskimi zaklęciami, których póki co nie znam;

Ale przy pracy nad innym projektem i po przeniesieniu modułu do innego podfolderu musiałbym pamiętać o zmianie ścieżki inaczej nie zadziała.

To raczej normalne - nie zapiszesz ścieżek tak, aby pasowały do wszystkich projektów; Pliki modułów najlepiej jest trzymać w jednym miejscu, a nie dzielić w kilku folderach; Gdybyś je trzymał w jednym katalogu to nie miałbyś problemu;

Najlepiej by było, jakbyś napisał do czego Ci to potrzebne - bo póki co wygląda to na jakieś kosmiczne kombinacje i utrudnianie sobie pracy;

Jeśli nie znajdziesz sposobu na programowe odczytanie ścieżek, to zawsze pozostanie Ci funkcja, która na podstawie wejściowej nazwy modułu przeszuka wszystkie podkatalogi, łącznie z folderem, w którym znajduje się plik wykonywalny i zwróci gotową ścieżkę; Jedyne co będzie Ci potrzebne to FindFirst, FindNext i ukochana rekurencja.

Zmień język na C/C++ tam masz __FILE__ i __LINE__

Dlaczego.
Żeby mieć np. grafikę lub inne pliki potrzebną do danej/ danych formy lub modułu trzymam to w folderze z modułem, albo w podfolderze. Nie mówię tu o takiej sytuacji gdzie 1 moduł jest w folderze ale mam np dość rozbudowane klasy i jeśli cały projekt z plikami towarzyszącymi przekazuję komuś do kompilacji/ rozbudowy przy pracy nad większym projektem. to właśnie nie chciałbym musieć pamiętać że projekt i moduły muszą być w dokładnie takiej samej ścieżce.

Oczekiwany efekt.
Tuż po kompilacji danego exe, w tym samym exe chce mieć procedurę/ procedury które mi te pliki z pobranych ścieżek + podfoldery przenoszą we wskazane miejsce np do folderu BIN\Grafika. Żeby potem nie szukać grafik po wszystkich folderach z modułami i demami tylko już było tam gdzie chcę.

Po to istnieją pliki *.rc -> *.res

Tuż po kompilacji danego exe, w tym samym exe chce mieć procedurę/ procedury które mi te pliki z pobranych ścieżek + podfoldery przenoszą we wskazane miejsce np do folderu BIN\Grafika. Żeby potem nie szukać grafik po wszystkich folderach z modułami i demami tylko już było tam gdzie chcę.

Nadal kombinujesz jak konik pod pagórek; Trzymaj grafiki we wspólnej lokalizacji - po co zaprzęgasz program (czyli już "gotowy" produkt) do organizowania źródła? Przecież to nie ma sensu - cały proces działa odwrotnie niż działać powinien, bo uruchomiona aplikacja ma mieć wszystko gotowe, a nie przygotowywać własne źródła do własnej kompilacji...

Równie dobrze w opcjach projektu masz możliwość uruchomienia skryptu batcha po kompilacji, który mógłby zorganizować pliki projektu; Tego typu zabiegi stosuje się np. do usuwania plików kopii zapasowych po kompilacji, czy pakowania pliku wykonywalnego jakimś stripperem czy UPXem - Ty też mógłbyś z nich skorzystać.

Tzn dlatego pytam bo zależy mi na efekcie a nie na wyważaniu otwartych drzwi.

Tylko teraz tak bo procedura w module głównym inicjująca która by organizowała zasoby, w momencie kiedy projekt jest gotowy na 105% po jej wykorzystaniu może być skomentowana i jej rola się kończy. Robi się instalkę programu i finał.

Natomiast jak ugryźć tego *.BAT żeby się nie okazało ze znów muszę kolejno ręcznie podawać ścieżki dostępów do wybranych plików bo tego chce właśnie uniknąć. Wszystko się rozbija o to ze przy niewielkiej ilości modułów i klas to nie ma sprawy można ręcznie ale niektóre klasy robiące coś tam i podpięte do innych klas już nawet nie pamiętam że są a się okazuje że nagle program nie chodzi bo wyskakuje komunikat brak pliku... I tego chcę właśnie uniknąć, ujednolicić system i niech się samo robi co tylko może automatycznie.

Tzn dlatego pytam bo zależy mi na efekcie a nie na wyważaniu otwartych drzwi.

Ty próbujesz wyważyć całą ścianę z gołą framugą, bez drzwi :]

Natomiast jak ugryźć tego *.BAT żeby się nie okazało ze znów muszę kolejno ręcznie podawać ścieżki dostępów do wybranych plików bo tego chce właśnie uniknąć.

Od samego początku proponujemy Ci korzystanie z jednakowych ścieżek, żeby była zgodność we wszystkich projektach/lokalizacjach; Pliki batcha nie mają Cię zwolnić z konieczności tworzenia jednakowych katalogów, a z implementowania organizacji projektu w kodzie aplikacji, której być nie powinno; Plik batcha ma przenosić różne duperele, ale także będzie potrzebował statycznych ścieżek, aby w ogóle mógł działać; Zaś produkt nie będzie ingerował we własne źródła i we własną kompilację;

Rozumiesz? Organizacja plików projektu należy do Ciebie, a nie do środowiska - tym bardziej nie dla aplikacji, którą tworzysz na podstawie źródeł i plików drugorzędnych.

Rozumiem> W takim układzie poczytam o tym bo ta "gałąź" funkcji kompilatora była mi obca .. taka "mała" nieumiejętność. Tak to jest jak się niektóre sprawy traktuje po macoszemu to potem z kilofem na słońce .. jak to w Korei podobno wodzowi plazmę ze słońca przywieźli :)