Board.KolibriOS.org

SVN r. 1582 - поддержка сохранения размеров и корректировки положения для программ KIV и Rtfread.

Надобно будет обновить страницу :
http://wiki.kolibrios.org/wiki/OpenDialog/ru
потому что там подключение диалога еще через макрос opendial.mac .
Ну и также программы planet_v и t_editor .

SVN r. 1583 - прикрутил использование вызова OpenDialog через библиотеку proc_lib.obj, к программе MidAmp. Поддержка сохранения размеров и корректировки положения OpenDialog.

Как только дойдут руки. Программы я поправлю, а вот Википедию редактировать пока времени нет.

я только что подправил planet_v, так что может и остальное сделаю

Вот и замечательно, а то мне еще zSea и ctrldemo править. И с кривоватым меню MidAmp плюхаться.
Ты пожалуйста здесь отпишись или в темах программ своих, чтобы знать общий фронт работ и не терять времени.

Отредактировал пример подключения OpenDialog в википедии

SVN r. 1585 - использование вызова OpenDialog через библиотеку Proc_Lib.obj, в программе CtrlDemo (демонстрация некоторых элементов управления библиотеки Box_Lib.obj). Поддержка сохранения размеров и корректировки положения OpenDialog.

SVN r. 1588 - нижнее меню в MidAmp теперь также использует OpenDialog. Можно добавлять одиночные файлы и содержимое папок (исключая вложенные папки с файлами). Также удален код работы с устаревшим Sysxtree.

Исправил программу t_editor.

Работая над t_editor-ом появилась идея по усовершенствованию OpenDialog-а. Если при запуске диалога мы задаем пустую строку в dir_default_path:

align 4
OpenDialog_data:
.........
.dir_default_path   dd openfile_path ;+20
.........

То диалог сам по умолчанию открывает диск RD/1. Но при этом в текстовом поле не прописывается RD/1, оно остается пустое. Если мы выберем какой-либо файл с диска RD/1, то диалог благополучно закрывается, но путь к файлу остается неполный ... Далее тут возможны глюки, если пользовательская программа по умолчанию работает с диском RD/1, то такой путь ей подойдет. При повторной попытке открытия диалога он выдает ошибку, т. к. не указан полный путь к файлу и он не знает где его искать.

Предложение такое, если программист задал пустой путь в dir_default_path, то при запуске диалога в текстовое поле должен вписываться открытый диалогом путь RD/1 .

А зачем вообще трогать?

.dir_default_pach   dd communication_area_default_pach   ;+20

Этот путь оставлен как резервный, когда совсем нечего брать программе. То что программа подставляет /rd/1/ сама, так это вообще левое - на случай если она запущена не через макрос opendial.mac (который теперь в Proc_Lib.obj), а например файловым менеджером.
Для использования рабочего пути есть заранее предусмотренный параметр:

.opendir_pach      dd temp_dir_pach   ;+16

А вот если уже он пустой, то используется значение адреса, которое по смещению +20.
Во время работы в адрес по +16 копируется меняющийся путь к последней открытой директории, если операция по выбору файла прошла успешно. При старте это обычно пустая область, но если туда прописать путь к директории, то он откроет именно нужную директорию. Разумеется если она существует.

А если скопировать путь к файлу в область:

.openfile_pach          dd fname_buf ;+36

так можно даже с очисткой пути от имени файла не мучаться - код в opendial.mac сам обработает и поместит путь к директории в область, по адресу указанному в +20.
В последнем случае это должно быть сделано до вызова:

    call    [OpenDialog_Init]

SVN r. 1594 - исправление KIV
SVN r. 1595 - исправление Midamp
Теперь при запуске с параметром "путь к файлу" - OpenDialog открывает ту директорию, откуда открыт файл. Раньше в первый раз всегда открывалось /rd/1

Я имел ввиду ситуацию когда и в смещении +20 и в +16 одновременно идут пустые строки.

Приведу 2 ситуации:
1) пути в +16 и +20 пустые
2) путь в +16 пустой а в +20 путь указывает на rd/1
Действия диалога открытия файлов в этих случаях:
1) открывается путь rd/1, в текстовом поле пусто
2) открывается путь rd/1, в текстовом поле стоит rd/1

Если оставить все как есть, тогда программистам нужно объяснить эти ньюансы. Я по не знанию оставил и там и там пустой путь, и у меня возникала ситуация с самостоятельной подстановкой rd/1 и пустым полем ... хотя мне в программе нужно было именно поле с полным путем.
Если считаешь нужным оставляй все как есть, тогда в справочной системе прийдется больше писать.

Ну, поскольку в теме этой мы этот вопрос подняли, то я считаю достаточно. Ситуации разные бывают, все возможные учесть и сложно и бесполезно. У меня вот с приложениями такого не было, по этому я воспринимаю твою ситуацию как академическую и не требующую написания лишнего кода.

Так просто много к чему можно придраться - программист может например взять и в двух указателях один и тот-же адрес написать. Такую ситуацию я тоже не обязан учитывать. Ну мало ли что человеку вообще взбредет в голову.

SVN r. 1606 прикрутил использование OpenDialog (через библиотеку proc_lib.obj) - для программы RDsave.