SovietPony писал(а):
смысл искать корень какими-то ненадежными методами если лучше спроить ящик напрямую?
с этим есть забавная проблема (уже сейчас): пути, которых не существует на FS. в документации написано:
Цитата:
PROCEDURE (d: Directory) This (IN path: ARRAY OF CHAR): Locator
NEW, ABSTRACT
blah-blah… This does not check if the specified path exists.
и вот тут мы имеем проблему: ящик не знает, во что развернуть "X:mydir", если диска "X:" не существует вообще. и по документации — он не имеет права выяснять, существует ли такой диск. он умеет разворачивать или абсолютные пути, или относительно положения бинарника.
это я к тому, что `Files.dir.This()` всегда разворачивает пути в полный дисковый вариант, а здесь это невозможно. ломать такой разворот — значит, поломать кучу кода, которая полагается на такое поведение. а распарзить такой несуществующий путь без системно-зависимого кода и без локатора нельзя.
да, такое возможно только на винде, и проблема
очень экзотическая. но если мы введём платформо-независимый API для парзинга путей в текстовом виде, то это будет стимулировать людей писать переносимый код даже для такой редкой ерунды, а не прибивать гвоздями проверки ОС. и если вдруг появится ещё одна ОС, где может быть подобное — то «правильный» код будет Просто Работать, а код с прибитыми проверками придётся чинить. «Defence-In-Depth», однако.
SovietPony писал(а):
сепаратор тоже туда можно сунуть. одна CHAR переменная никому не помешает.
и не поможет, потому что у винды, например, два равноправных сепаратора, а не один. именно затем и нужна функция.
SovietPony писал(а):
но какие варианты если нет никаких сепараторов или они специфические?
забить. если сепараторов нет, значит у нас плоская фс. если они меняются по правилам драконего покера — значит, мы такое сумасшествие игнорируем, и пусть с ним играется тот, у кого оно зачем-то завалялось.
SovietPony писал(а):
нужна тогда какая-то функция что бы получить локатор уровнем выше
тогда пусть `loc.This("..")` работает как это вот самое. тем не менее, проблемы с FilesBrowser всё ещё есть: мне нужно короткое имя каталога локатора (только последняя часть), чтобы спозиционировать на него курсор по выходу на уровень выше (потому что LocInfo возвращает список локальных имён). опять надо парзить путь ручками, знать про сепараторы, и прочая-прочая. ну, или городить адский ад, создавая по локатору на каждое короткое имя в списке, и сравнивая их.
то есть, мы опять приходим к необходимости платформо-независимого API для работы с текстовым представлением путей. неважно, будет оно в Dialogs, или будет оно в Files, или будет оно в Locator. окей, пусть мой дизайн кривой (а он кривой, я с этим не спорю) — тогда предложи дизайн лучше, с максимальным сохранением совместимости со старым кодом. я же не настаиваю на своём, мне любой пойдёт — лишь бы он был.