IgorA
Посмотрел - выглядит хорошо, только вопрос возник - будешь прикручивать к Box_Lib или отдельной библиотекой?
В принципе прикручивание к Box_Lib ничем не ограничено, кроме формата вызова - надо с вызовом функции ложить в стек указатель на блок данных, ну и желательно, чтобы все переменные сохранялись в этом блоке, для полной реентерабельности компонента.

Mario wrote:только вопрос возник - будешь прикручивать к Box_Lib или отдельной библиотекой?

Думаю можно прикрутить, отдельной библиотекой смысла нету, ведь Box_Lib создавалась для элементов управления.

Mario wrote:прикручивание к Box_Lib ничем не ограничено, кроме формата вызова - надо с вызовом функции ложить в стек указатель на блок данных, ну и желательно, чтобы все переменные сохранялись в этом блоке, для полной реентерабельности компонента

Так и стараюсь делать, есть внутренние функции, которые не для экспорта, они это условие нарушают, например: Добавил в элемент возможность задавать текстовую подпись рядом с картинкой, при добавлении нового узла (item-a). Если еще добавить: реакцию на кнопки, мышь и скролинг то элемент можно нормально использовать, и потом крутить его к Box_Lib.
Я правда не понял, как определяется элемент в фокусе, с учетом реентерабельности библиотеки ? Если в библиотеку тулить указатель на элемент в фокусе, то библиотека не будет реентерабельной. А если указатель на элемент в фокусе вставить в саму структуру элемента, то как избежать ситуации, при которой несколько элементов могут оказаться в фокусе ? Этот вопрос и мешает сделать реакцию элемента на кнопки, мышь ... А использовать скролинг без прикручивания к Box_Lib тоже нормально не получится.

IgorA

Так и стараюсь делать, есть внутренние функции, которые не для экспорта, они это условие нарушают, например:

Внутренние функции на усмотрение программиста (на то они и внутренние), главное соблюсти правильную передачу параметров между библиотекой и приложением.

А если указатель на элемент в фокусе вставить в саму структуру элемента, то как избежать ситуации, при которой несколько элементов могут оказаться в фокусе ?

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

А использовать скролинг без прикручивания к Box_Lib тоже нормально не получится.

Идеология Box_Lib такова, что все компоненты являются независимыми и базовыми, более сложные компоненты создаются кодом за пределами библиотеки, за счет комбинирования этих базовых элементов.

немного изменил элемент:
1) добавил функцию клавиатуру (управление курсорами и пробел)
2) добавил текстовые подписи к узлам
3) при нажатии пробела происходит открытие/раскрытие родительских узлов (стрелка должна стоять на узле, который открывается)
4) исправил 2 ошибки в коде

Поскольку лог на сайте не обновляется с ревизии 1233 (Nobody cares? Надоело мне владельца ресурса выискивать и сообщать о каждой поломке), то отписываю здесь.
Ревизии 1243, 1244, 1248:
1) Исправления компонента FileBrowser
2) OpenDialog: для вывода пути используется EditBox, переключение между элементами FileBrowser и EditBox клавишей Tab и кликами мышки, поправлена сортировка, иконки от Leency, дополнительные ассоциации по типам файлов к иконкам.

Обновил элемент Tree List : добавил функцию на мышь, обновил и добавил другие функции.
Из значительных доработок осталось добавить скролинг. Следущую версию наверное встрою внутрь box_lib .

IgorA
Bugreport:
1) Уход стрелки за пределы своего поля.
2) Стрелка не должна перемещаться дальше в пределах поля на не определенную область.
3) Доработать перерисовку. Сейчас при перемещении мышки, происходит перерисовка всего поля.
4) Запускаем приложение, удаляем все символы из edit_box. Пробуем вставить пустой Node. Все ок, возвращаемся в edit_box пишем "123456789" а Node вставляется со значением "56789". Это явно баг.
5) Я отметил на рисунке желтым кругом, как я считаю стоит доработать элемент. Наличие подобных связей лучше просматривается в при увеличении кол-ва элементов.
6) Возможно стоит попросить Линси или другого дизайнера представить концепцию программы.

Все выше это мое мнение (imho).

<Lrz>
Согласен с тобой, а по поводу 4-го расскажу почему так :

<Lrz> wrote:4) Запускаем приложение, удаляем все символы из edit_box. Пробуем вставить пустой Node. Все ок, возвращаемся в edit_box пишем "123456789" а Node вставляется со значением "56789". Это явно баг.

В виндовсе у каждого узла есть свойство ItemData = 4 байта (длинное целое), оно служит для связи узла с какими либо другими объектами в программе. Я сделал так, что на каждый узел можно выделять произвольное количество байт для хранения пользовательской информации. Т. е. цифры "1234" из твоего примера не печатаются не случайно, они могут быть каким либо указателем на объект, функцию или индексом какой либо структуры, все зависит от того как пользователь решить использовать эту "не печатаемую" память.
---
info_size - размер байт на каждый узел (пользовательская память + подпись).
info_capt_offs - параметр, указывает сколько байт из info_size брать для пользовательских нужд. Если он = 0 то весь текст из editbox будет на экране.
---
Может смутить и то что info_size типа dw, а info_capt_offs - dd, но info_capt_offs типа dd для удобства написания функций, его значение не должно быть больше чем dw.

Сделал 4 примера использования TreeList, код элемента и описание функций на svn. На svn много папок не знаю куда добавить примеры, потому пока ложу на форум.

Немного обновил примеры с учетом изменений элемента на svn (rev 1309) . Добавил 1 пример на использование функций tl_load_mem и tl_save_mem (работа с памятью).

Говорил сегодня с <Lrz> решили реорганизовать библиотеку box_lib.obj для решения некоторых проблем.
Добавил новый файл box_lib.mac который должен будет заменить файл editbox_ex.mac. Устранил дублирование программного кода в макросах. Изменения облегчат написание программ за счет усовершенствования логики построения библиотеки.

Почему-то не работает ctrldemo
Собираю так - fasm 1.68, исходники из SVN, а именно:
ctrldemo.asm
load_lib.mac
opendial.mac
data.inc
w_about.inc

компилируется без проблем, 3898 байт.

Из дистрибутива 0.7.7.0 не запускается, ничего не выводя. На доске в Kernel:
Page fault
EAX B08
EBX A000
ECX 0
EDX 10022058
ESI AC8
EDI 0
EBP E18
EIP 1002C022
ESP 00001712
Flags: 1246
CS: 1B (application)
destroy app object

В KlbrInWin выдает - "Недостаточно памяти"

Если убрать какую-то из библиотек с законного места, не падает, а выдает сообщение об ошибке, как положено - "Файл не найден".

По всей видимости, я что-то упускаю?

Поскольку это не рабочая программа, то писать код дополнительных сообщения, для некоторых ошибок, я не стал.
Например OpenDialog четко сообщает чего ему не хватает, но стоило это некоторого количества моих человеко-часов.
Я так предполагаю, что в папке где находится исполняемый Ctrldemo, отсутствует reload_16x16_8b.png - нужен для работы компонента DinamicButton.

Такая вот мысль, хотя, может быть, авторы библиотеки будут против подобных идей?
Библиотека замечательно работспособная, но внешне совершенно непривлекательная.
Вот, например, скролл выглядит сейчас так (для тех, кто вдруг не знает): Хотя вполне мог бы выглядеть, например, вот так: Или вообще вот так: Мне кажется, разница видна невооруженным глазом. Программы с более привлекательным интерфейсом будут и сами по себе более привлекательны для пользователя.
Разумеется, я понимаю, что сейчас код оптимизирован для высокосоростной отрисовки.
Но - в той же Console.lib в качестве скролла используется картинка. DynamicButton отрисовывает png. Значит - не так критично по скорости отрисовки, как может показаться?
Плюс если сделать отрисовку элементов из внешней картинки (то есть поддержку шкурок) - то будет вообще замечательно.

Вопросы: займется ли этим кто-нибудь в ближайшее время, если нет - имеет ли смысл ковыряться самому?
Иными словами, нужно ли это кому-нибудь ещё, или всех устраивает так?