Valery Solovey писал(а):
Если файл лежит в текущем каталоге (а при запуске приложений в ОС Windows так оно обычно и бывает), то можно сделать следующее:
Код:
loc := Files.dir.This( "" );
Log.String( loc( HostFiles.Locator ).path );
Пётр Кушнир писал(а):
к любому каталогу внутри ББ можно обратиться вот так: Catalog/subcatalog/subsubcatalog и т.д.
Например "Std/Rsrc" указывает на подкаталог Rsrc подсистемы Std
И ещё:
SanekSunshine писал(а):
Код:
IF MtFiles.ExistsFile(Files.dir.This(???), 't.txt') = FALSE THEN
ТАК не пишут! Пишут вот так:
Код:
IF ~MtFiles.ExistsFile(Files.dir.This(???), 't.txt') THEN
Илья Ермаков писал(а):
Там строковое представление пути, действительно, получить не очень легко. Я когда-то выкручивался через Kernel, извлекая внутреннее поле name от HostFiles.Locator.
Александр Ильин писал(а):
Насчёт того, что идея рубится на корню, то тут трудно что-то сказать однозначно. Например, почему нет такой функции в Files как "вернуть путь в виде строки"? Потому, что Files независим от платформы, а строка имеет зависимый формат. С другой стороны, модуль Files готов принимать строки в платформенно-зависимом формате и на их основе делать Locator'ы, например. Получается асимметрия интерфейса. Для этого есть особая причина (не вижу) или это упущение дизайнера модуля?
Абстрактный модуль, насколько я понимаю, должен предоставлять интерфейс, который является общим для всех платформ. При этом неизбежно и необходимо что-то упустить из виду (например, тот факт, что для каждого диска Windows помнит "текущий каталог", в который мы попадаем, набрав в командной строке только имя диска c: или d: - в Linux, где единая файловая система данный концепт просто не имеет смысла, так как там нет дисков, а есть единое дерево каталогов и устройств с общим корнем). Расширять абстрактный модуль вряд ли имеет смысл без тщательно продуманного обоснования, тем более если наша цель - получить платформенно-зависимую информацию. В данной конкретной задаче проблема в том, что фремворк ББ редиректом /USE спрятал от нас знание о пути к BlackBox.exe, которое тем не менее, может пригодиться в каких-то задачах. Выхода два - либо поправить фреймворк, либо обратиться к средствам платформы (например, узнать путь к исполнимому модулю по хэндлу текущего процесса). Первое ведёт к несовместимости вашей подсистемы с другими ББ, второе ведёт к несовместимости с другими платформами.
...
Обработав (это оч. сжато) полученную информацию, я немного пошаманил и получил следущее (хочу отметить, по поводу совместимости, что идею
Пётр Кушнир писал(а):
Код:
PROCEDURE Open;
VAR f : Files.File; loc : Files.Locator;
BEGIN
loc:=Files.dir.This(''); (* создаём локатор *)
f:=Files.dir.Old(loc, 't.txt', Files.shared); (* открываем файл в режиме shared, то есть неблокирующий доступ *)
IF f#NIL THEN (* файл успешно открылся *)
ELSE Log.String('Файл не найден. Код ошибки '); Log.Int(loc.res) END; (* иначе код ошибки будет содержаться в поле loc.res *)
END Open;
то же самое с
Код:
IF MtFiles.ExistsFile(Files.dir.This(''), 't.txt') THEN
я еще не использовал):
Код:
...
TYPE Location = Files.Locator;
VAR ...
bbLocator,loc:Location;
PROCEDURE Wai;
BEGIN
bbLocator:= Files.dir.This("");
loc := Files.dir.This(bbLocator(HostFiles.Locator).path+path);
END Wai;
...
Wai;
IF ~MtFiles.ExistsFile(loc, 't.txt') = FALSE THEN ... END;
...
Т.е. при любой манипуляции с файлами выполняется Wai (Where am I?). Wai "осматривается по сторонам" и сообщает программе где он собссно находится. Не обращайте, кстати, внимания на bbLocator(HostFiles.Locator).path+path - другой path это строковая константа, указывающая куда сохранять дальше (т.е. если path = '\Abc\Def\', а BB лежит в 'C:\BlackBox', то файл проверится в 'C:\BlackBox\Abc\Def\')
Если еще чуть-чуть покуролесить можно будет даже отказаться от импорта MtFiles, НО бессмысленно будет это делать, если даже сейчас у меня не получилось реализовать то, о чем спрашивал...
Отдаюсь на ваш справедливый суд - в локатор loc возвращается полный путь или относительный? Я просто в этом не очень разбираюсь, вы, пожалуй, в этом убедились...)