OberonCore

Допустим, мой BlackBox.exe лежит в какой-нибудь произвольной директории. Каким путем я могу в переменную строкового типа вернуть эту самую директорию? Может подсистема какая нибудь есть? Подскажите пожалуйста, заранее спасибо.

Если файл лежит в текущем каталоге (а при запуске приложений в ОС Windows так оно обычно и бывает), то можно сделать следующее:

А у loc какой тип? Files.Directory?

Тип Files.Locator.

Да, забыл указать тип...

И ещё: это был пример для понимания сути. В том виде, как я это показал, использовать идею не стоит, потому что Files.Locator не обязательно должен расширяться именно HostFiles.Locator-ом. В общем случае он может быть и чем-нибудь другим, поэтому проверяйте тип при выполнении второй строки.

Но при использовании ключа -USE возвращаться будет именно "рабочий" каталог. Так что только через WinApi

О! Класс. Все работает. Только последний вопрос...а как к ней теперь обращаться?

к любому каталогу внутри ББ можно обратиться вот так: Catalog/subcatalog/subsubcatalog и т.д.
Например "Std/Rsrc" указывает на подкаталог Rsrc подсистемы Std

И ещё:ТАК не пишут! Пишут вот так:

Это-то я знаю, спасибо, просто сейчас требуется узнать ИМЕННО местоположение ядра, там находится файл...В полях loc нет строковых массивов, следовательно их никак не вызвать, от того сейчас на душе тяжко... Мне интересно, как в переменную Files.Locator можно сохранить директорию и как ее потом оттуда "достать"? Не спрашивайте зачем:)

Вам же ещё раньше ответили про местоположение "ядра". Всё просто, если все каталоги внутри ББ определяются как "Catalog", то путь к ББ будет записываться пустой строкой, ведь никаких подкаталогов нет.
В ББ зачастую вообще не нужно знать текстовое представление пути. Только при создании локатора. Дальше можно оперировать локатором, при необходимости вычисляя путь, как в примере Valery Solovey через приведение типа к типу реализации.

то же самое с

А в чём состоит ваша задача, если не секрет?

Там строковое представление пути, действительно, получить не очень легко. Я когда-то выкручивался через Kernel, извлекая внутреннее поле name от HostFiles.Locator.

Огромное спасибо, Петр



Я знал, что вы спросите

Моя задача - исправить трапающее сохранение свойств сессии при распространении на доменах сервера. Т.к. путь на сервер закрыт, требуется сохранять файл на полный путь, не на относительный (рядом с загрузочным пакетиком, плюс в паре подкаталогов).



Ууф....Вот уж точно)))))

Если так уж сильно надо, добавьте объекту HostFiles.Locator метод GetPath, и пусть возвращает вам строку.

Одно маленькое уточнение (хотя думаю Александр это и имел ввиду ). Метод нужно добавлять в модуле Files, а в HostFiles добавить реализацию этого метода. Потому как прикладной модуль хоть и может, но не должен мпортировать модуль реализации, так как на корню рубит саму идею, ради которой создавался модуль реализации.

И ещё, как только вы добавите такой метод, так тут же потеряете совместимость со всеми остальными оригинальными экземплярами ББ, поэтому такой вариант даже нельзя рассматривать. Разве что в качестве мысленного экспериимента

Почему? Он же будет действовать в пределах только этого бб... В другом просто не будет и упоминания о нем Совсем другое дело, как это все "сварить".)

Если Вам нужно решить конкретную задачу и это поможет, имхо - делайте.Если изменить интерфейс в Files, которым пользуется весь ББ, то "сварить" (скомпилировать) это действительно будет сложно; при этом всему ББ такая функция не нужна. Она нужна нам, в конкретном месте; мы про неё знаем, и, через приведение типа всегда вызовем... Хотя тогда не понятно, в чём разница между функцией и обращением к полю path...

Теперь слово предоставляется Александру - пусть пояснит, что он имел ввиду.

Я, в общем-то, имел в виду то, что написал. Если интересует мой вариант обоснования, то оно у меня таково. Если нужно платформенно-зависимое решение (а пути в Windows отличаются от путей в Linux, например), то лучше импортировать HostFiles, подчеркнув эту зависимость. В этом случае правится только один модуль (HostFiles), а не два (Files и HostFiles), так что необходимые изменения лучше локализованы. Если волнует совместимость с другими дистрибутивами ББ (что довольно редкий случай само по себе), то ещё возможен вариант создания собственного драйвера, например, с именем PrivHostFiles, и последующее прямое использование этого модуля при проверке типа: WITH loc: PrivHostFiles.Locator DO... Реализацию PrivHostFiles можно получить копированием HostFiles в подсистему Priv (имя Priv зарезервировано для частного использования, поэтому не может конфликтовать с другими подсистемами ББ) и добавлением нужных функций, либо публикацией нужных полей, если они уже там есть.

Насчёт того, что идея рубится на корню, то тут трудно что-то сказать однозначно. Например, почему нет такой функции в Files как "вернуть путь в виде строки"? Потому, что Files независим от платформы, а строка имеет зависимый формат. С другой стороны, модуль Files готов принимать строки в платформенно-зависимом формате и на их основе делать Locator'ы, например. Получается асимметрия интерфейса. Для этого есть особая причина (не вижу) или это упущение дизайнера модуля?

Абстрактный модуль, насколько я понимаю, должен предоставлять интерфейс, который является общим для всех платформ. При этом неизбежно и необходимо что-то упустить из виду (например, тот факт, что для каждого диска Windows помнит "текущий каталог", в который мы попадаем, набрав в командной строке только имя диска c: или d: - в Linux, где единая файловая система данный концепт просто не имеет смысла, так как там нет дисков, а есть единое дерево каталогов и устройств с общим корнем). Расширять абстрактный модуль вряд ли имеет смысл без тщательно продуманного обоснования, тем более если наша цель - получить платформенно-зависимую информацию. В данной конкретной задаче проблема в том, что фремворк ББ редиректом /USE спрятал от нас знание о пути к BlackBox.exe, которое тем не менее, может пригодиться в каких-то задачах. Выхода два - либо поправить фреймворк, либо обратиться к средствам платформы (например, узнать путь к исполнимому модулю по хэндлу текущего процесса). Первое ведёт к несовместимости вашей подсистемы с другими ББ, второе ведёт к несовместимости с другими платформами. Смотрите, что вам важнее. Многое зависит от конкретной задачи - например, от того, планируется ли распостранять результат в виде подсистемы под разные ББ, или как скомпонованное приложение в виде exe-модуля. Не зная всей полноты условий, я могу только поделиться общими соображениями, что и сделал в данном посте. Спасибо за внимание.

Вы хотели сказать, что это рубит идею, ради которой создавался абстрактный модуль, а не модуль реализации. : )

Мой ответ будет такой. Поскольку абстрактный модуль создавался для независимости от платформы (а не от реализации), то платформенно-зависимые модули, в том числе из пользовательского приложения, вполне могут обращаться к ним напрямую, если те предоставляют необходимую информацию, отсутствующую в абстрактном интерфейсе. Мы же не удивляемся тому, что модули подсистемы Host могут импортировать друг друга напрямую. Если не получается написать на абстрактном интерфейсе, то всего лишь получим платформенно-зависимое приложение. Ничего особо страшного в этом нет, полно задач можно найти, необходимых на одной платформе и бессмысленных на другой (например, узнать текущий путь того или иного диска, см. пред. пост). Если нужна и специфика, и независимость, то придётся выкручиваться иначе - либо дорабатывать каркас, либо вводить собственную прослойку (драйвера - аналоги Host*).