Board.KolibriOS.org

Круто (про mgtk, хотя рисовался тоже крута )
Насколько mgtk реализует функционал gtk ?

_________________

В mgtk под Менуэт (да, именно под Менуэт!) реализовано всё, что нужно для построения простого интерфейса. Отличие от GTK - использование классов. А так есть классы приложения, виджета в общем, а также конкретно битмапа, кнопки (как обычной, так и радио или чекбокса), события, пера, слайдера, текста (ну и может ещё какие-то классы добавились - я библиотеку пол года назад скачивал).

Версия 0.4.
Исправлены указанные баги, улучшена работа с памятью.
Пока приостанавливаю разработку этого приложения, переключаюсь на панель задач (viewtopic.php?f=9&t=809&start=15).

Albom, mgtk полезная библиотека, но в прилагавшемся примере у меня не работает GInputLine (возможно, потому что пример скомпилен под Menuet, а не под Koilibri?).

to barsuk
Я ради интереса скачал mgtk и потестил. В общем фишка такая: текстовое поле воспринимает только латинские буквы и цифры, в общем-то всё кроме кириллицы. Этот контрол (элемент) надо переделать, т.к. работа с клавиатурой в Менуэте и Колибри отличается, да и сам контрол реализован ч\ж.

как и многое в этой (да и не только этой) ОС!


а зачем больше? для ввода формул сойдёт!

Наконец сумел прикрутить edit_box от <Lrz>. В честь этого версия 0.5.
И добавил кнопку "Edit", которая открывает указанный файл в tinypad для редактирования.

Что-то я компонента не наблюдаю в программе при запуске. В самом бинарнике есть обширные области инициализированные как 0х0 О_о . Если нужен кусок памяти, можно попросить у системы выделить его, в крайнем случае инициализировать область в конце программы. К примеру, так:
- иницализация массива из 500 байт в конце программы

use32                ; транслятор, использующий 32 разрядных команды
    org 0x0                 ; базовый адрес кода, всегда 0x0
    db 'MENUET01'           ; идентификатор исполняемого файла (8 байт)
    dd 0x1                  ; версия формата заголовка исполняемого файла
    dd start                ; адрес, на который система передаёт управление
                            ; после загрузки приложения в память
    dd i_end      ; размер приложения
    dd i_end      ; Объем используемой памяти, для стека отведем 0х100 байт
    dd i_end      ; расположим позицию стека в области памяти, сразу за телом программы. Вершина стека в диапазоне памяти, указанном выше
    dd 0x0,0x0                ; указатель на строку с параметрами.

start:
.....
array_of_500:
rb 500 ; резервирует 500 байт
align 16
rb 0x100 ; это место для стека
i_end:

Вот такая последовательность обеспечит инициализацию 500 байт за кодом приложения и без включения кода типа 0x0 в бинарник. Конечно, перед использованием, нужно очистить массив.

А я что-то так и не понял, что в архиве: graph.kex (от 23.10), которая не запускается и просто graph, которая запускается нормально, но это версия от 16.06

<Lrz>, а чем плох такой подход: выделять массив как придется, а затем сжимать kpack'ом, и все нули сожмутся в несколько байт?


Просто graph попал по ошибке, это старая версия. Новая - graph.kex. Для запуска необходим box_lib.obj. Если используется эмулятор KlbrInWin, box_lib.obj нужно поместить на рамдиск.

barsuk
1. Если нет kpack, то размер приложения увеличивается.
2. Если тебе нужен массив данных, то его можно выделять в стеке, или как я предложил (для небольших данных). Твой подход, не совсем правильный, т.к. пользователь не всегда использует kpaсk.
Все это имхо. Я не использую области в коде, когда мне нужно выделить значительные участки памяти.

barsuk

Если надо динамически выделять память то смотри ф. 68.11 68.12 68.13
P.S. Эту память не надо обнулять.

Пример, когда не нужно объявлять данные посреди кода прост: может случиться так, что в результате недостаточности проверок, данные затрут код. Утверждение, конечно же, не относится к константным инициализированным данным.

_________________
in code we trust

<Lrz>, расположение данных за кодом просто осуществить в FASM и непонятно как в Visual C++, так что использую динамическую память (но для буфера для параметров вызова приложения этот способ не годится).
Serge, в модулях Колибри для С++ была реализация malloc/free через функцию 64. Я переписал их под 68.11/68.12 (раз они предпочтительнее для использования).
mike.dld, если объявить данные после кода, они в такой ситуации выйдут за границы выделенной памяти или затрут другие данные... Проверки важны в любом случае, но затирание кода, имхо, легче заметить (по падению приложения), чем затирание других данных.

Так он есть в папке sys/lib, или у тебя какая-то своя версия? Если такая же, как в eolite и htmlview, то ИМХО не нужно городить огород из бокс-либов в каждой папке, а прописать в программе путь к /rd/1/lib/box_lib.obj. К тому же программа перестала понимать параметры запуска - если запускать из eolite файлы *.cvs, то открывается пустое окно программы, типа файл не загружен.

Теперь box_lib.obj берется из /sys/lib/. Годится любая версия, но я тестировал с последней (29.09.2008).
С параметрами запуска был баг. Теперь они работают как нужно.