некая странность обнаружилась. для чтения параметра из файла не в текущем каталоге достаточно проставить относительную ссылку:
( файл stalked.ini находится в каталоге data)
Add(Ini,15103339,182,126)
{
FileName=".datastalked.ini"
Section="main"
Key="gamepath"
Type=1
}
однако для записи этого же параметра путь необходим абсолютный, причем с двойными слешами:
Add(Ini,8976951,308,189)
{
FileName="D:\soft\tools\HiAsm\stalker\data\stalked.ini"
Section="main"
Key="gamepath"
Type=1
}
очнь неудобно держать два компонента для одного ключа. да еще и две переменные, хранящие путь к файлу.
Этот топик читают: Гость
Ответов: 499
Рейтинг: 1
|
|||
карма: 0 |
|
Ответов: 9906
Рейтинг: 351
|
|||
HikeR писал(а): однако для записи этого же параметра путь необходим абсолютный, причем с двойными слешами:Доказательства в студию |
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
HikeR писал(а): однако для записи этого же параметра путь необходим абсолютныйнеподтверждается. HikeR писал(а): причем с двойными слешамидвойной должен стоять только перед каталогом tools |
|||
карма: 27 |
|
Ответов: 3514
Рейтинг: 184
|
|||
FileName=".datastalked.ini"
точка там нафиг? |
|||
карма: 0 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
стандартное обозначение текущего каталога
|
|||
карма: 27 |
|
Ответов: 3514
Рейтинг: 184
|
|||
Я делаю без точки, и всё отлично читается и записывается
![]() |
|||
карма: 0 |
|
Ответов: 499
Рейтинг: 1
|
|||
такс... я так понимаю, что проблема в том, что " " - это табуляция, "
" - конец строки (или что типа этого) можно список всех спецсимволов, которые HiAsm интерпетирует как управляющие? p.s. блин, даже в надписях слэш трактуется как начало спецсимвола... |
|||
карма: 0 |
|
Ответов: 3514
Рейтинг: 184
|
|||
ставь два слэша
|
|||
карма: 0 |
|
Ответов: 9906
Рейтинг: 351
|
|||
HikeR, проблема совершенно в другом
Что 99% новичков (и не только) не понимают, что понятие "очевидно" - ОТНОСИТЕЛЬНОЕ Это твоими очами видно, что у тебя на компе. А нашими - не видно. Если ставить ставки как в казино - я бы поставил на то, что ты перед записью каким-то образом менял текущую папку. Впрочем, с самого начала предполагать, что она совпадает с папкой запуска программы - не умно как минимум. Но это гадание на кофейной гуще, которое мало кому интересно. Прочитай разделы !Наши_правила! !Обмен_файлами! И выложи простенькую схему, которую каждый сможет у себя воспроизвести и увидеть твою незадачу. И помощь получишь незамедлительно А словесами можно еще неделю упражняться - и бестолку От тебя не просят ничего сверхестественного: лишь чтобы то, что видишь ты - увидели другие. А про обратные косые - читаешь справку, и все |
|||
карма: 9 |
|
Ответов: 499
Рейтинг: 1
|
|||
я не совсем новичок, просто то, что для вас очевидно, для меня стало не сразу.
вот схема.
обрабатываются неверно (для этого примера) реальный пример. при запуске программы проверяется наличие файла настроек, в котором указан путь к некоторому каталогу для дальнейшего использования. если файла нет, то предлагается выбрать файл, лежащий в нужном каталоге, потом из его полного пути выкидывается имя файла, и оставшийся путь пишет в файл настроек (не нашел средство для выбора просто каталогов). если файл есть, и путь прописан, то считывается значение пути и присваивается глобальной переменной. (в примере нет) вот пример. для упрощения выбираем путь к самом экзешнику программы, но в реале нужный каталог может быть где угодно.
пока элемент "память" содержит этот путь в виде data\test.ini все хорошо. здесь встретилась буква "t" в имени, этот случай понятен и решаем, так как мы сами определяем имя файла. но если расположение файла настроек будет предварительно указываться пользователем? тогда придется элементу "работа c ini-файлами" передавать полный путь, в котором могут встретиться "запрещенные" последовательности... |
|||
карма: 0 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
пример из второй схемы работает.
HikeR писал(а): но если расположение файла настроек будет предварительно указываться пользователем? тогда придется элементу "работа c ini-файлами" передавать полный путь, в котором могут встретиться "запрещенные" последовательности...замена спец символов происходит на этапе кодогенерации и к конечному приложению отшения не имеет. |
|||
карма: 27 |
|
Ответов: 499
Рейтинг: 1
|
|||
хорошо. второй пример и должен работать.
сидел тучу времени, чтобы найти пример, который не работает. все таки нашел, только фичу или багу - еще не понял. (код внизу поста) вот пожалуйста. логика та же. - выбираем любой файл в том же каталоге, где сама программа (например ее саму). - выбрасывается имя файла, остается путь. - записывается этот путь в INI файл. - тут же считывается и выводится в ListBox - пока элемент "память" хранит значение error.ini или .error.ini (string) можно выбирать где угодно лежащие файлы, и в листбоксе будет показываться путь до них и error.ini будет создаваться в каталоге, где лежит программа. меняем условия. - элемент "память" меняем на ..error.ini - перекомпилируем программу, запускаем. - выбираем файл в каталоге с программой (или ее саму) - пока все правильно, уровнем выше создался error.ini - уходим в любой другой каталог уровнем выше, чем программа - наблюдаем error.ini уровнем выше, чем выбранный файл. то есть, элемент "работа с ini-файлами" в моем примере ведет себя вот так: Add(Ini,8976951,427,238) { FileName="" (пусто !!!) Section="main" Key="path" Type=1 } так как FileName не задан в свойствах, а задается внешним элементом "память" (так как имя может менятся), то поданный на вход в качестве значения параметра ini-файла полный путь он принимает за значение FileName. пусть я ему сунул на входе таку строку: "d: emp", тогда FileName="d: emp" а потом, видимо, он видит, что внешний элемент тоже содержит путь, в нашем случае такой "..error.ini". получается что FileName="d: emp..error.ini" что, как всем хорошо понятно, FileName="d:error.ini" в итоге там ini-файл и пишется. а у меня изначально проблема была в другом. инишник должен был лежать в подкаталоге относительно самой программы, т.е. внешнее значение .dataerror.ini даже при наличии такого каталоге на уровне программы путем этих махинаций превращается в случае подачи на вход того же "d: emp" в следущее: FileName="d: empdataerror.ini" а не FileName="каталог_программыdataerror.ini" такого пути есстественно не наблюдается (если только случайно). создавать ini-файлы с нуля элемент умеет, а каталоги - нет, в результате чего ничего туда не пишет. только вот непонятно, почему при указании в элементе "память" полного имени файла от начала диска все получается? то есть ini-файл создается именно там, где надо? ведь пользуясь вышеописанной логикой работы можно предположить, чтоэтот путь в итоге превратится в кашу.. то есть, если выбрали тот же "d: emp", а полный путь к ini-файл в "d:softdataerror.ini", то должно получится такое: FileName="d: empd:softdataerror.ini" как такое переваривается? или при работе элемент сам прошаривает, что это такое и как это надо использовать? вобщем полночи убил, в связи с чем пожелание. дабы предусмотреть такие случаи не изменить ли логику обхода заданных параметров? то есть если есть 4 свойства, 2 заданы внутри, 1 через внешний элемент, то любой поданный на вход параметр считать оставшимся четвертым без вариантов. ну и вот этот злополучный код...
|
|||
карма: 0 |
|
Ответов: 9906
Рейтинг: 351
|
|||
HikeR писал(а): пока элемент "память" хранит значение error.ini или .error.ini (string) можно выбирать где угодно лежащие файлы, и в листбоксе будет показываться путь до них и error.ini будет создаваться в каталоге, где лежит программаНе правда. error.ini будет создаваться и читаться в текущей папке. Которая запросто меняется после работы ODialog. HikeR писал(а): а потом, видимо, он видит, что внешний элемент тоже содержит путьЧего народ-то смешить: кто он, и кого видит ??? Делать ему (осталось выяснить - кому) больше нефиг, как чего-то смотреть и пытаться кого-то надурить. Когда в ODialog (это просто виндячий модал) Вы выбираете d: empxxx, текущей папкой для всего процесса становится d: emp Это не наша логика, а логика винды, и нам ее поменять - не судьба. Не пользуйтесь относительными путями, не будет проблем. Даже скажу больше, что гарантий того, что у Вас при старте программы текущая папка процесса совпадает с папкой приложения - НИКАКИХ. То что делает пользователь Вашей программы, Вы не контролируете. А он обязательно запустит ее как-нибудь хитрозадо (уверяю Вас, пользователь может сделать все что возможно, и даже нет - это аксиома), совершенно из другого места. И что, опять топик для обсуждения создавать ![]() |
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
HikeR, правильная схема будет такая:
code_1169.txt |
|||
карма: 27 |
| ||
файлы: 1 | code_1169.txt [1.2KB] [379] |
Ответов: 9906
Рейтинг: 351
|
|||
Dilma, а мне не показалось, что менять расположение INI-файла входит в задачу
|
|||
карма: 9 |
|