http://lrz.land.ru/ обновил компонент editbox. Доступен так же на svn.
От: Maxxxx32
Кому: <Lrz>
Добавлено: Sun Feb 11, 2007 1:04 am
Тема: Ошибка в обработке Backspace
Ошибка в обработке Backspace: На экране текст удаляется, а в памяти остаётся.
RE:
Эта "фитча" Что бы не выполнять личних действий, сделано следующее: Если я набираю текст - он заностися в память, но при Del or Backspace изменяется лишь указатели на размер выводимиого текста, затираниее не присходит.
Существуют 2 выхода из этой ситуации.
1) Перекроить программу, что бы она обрабатывала конец пути по указателю ed_size. (Что я считаю более логичным)
2) Перекроить компонент, так что бы в конце он вставлял завершающий символ или затирал всю память целиком т.е. вставлял 0.
Это не составит труда реализовать.
<Lrz> 13.02.2007 убрал по возможности мерцание, улучшена обработака перерисовки фона
добавил фитчу внесения 0х0 по адресу ed_size+1 иначе у Maxxx32 были несостыковки в коде. Пречниа в том, что оптимизация была сведена к тому что я не чистил символы в буфере, когда удалял, я просто их не выводил, и потом когда вносился новый символ, он по просту затирал уже имеющийся. Если бы программа обрабатывала конец строки по ed_size, проблем бы не возникло. Но сейчас этот недостаток исправлен.
Обращаю внимание всех, кто использует edit_box. необходимо обновить компонент.
Эффективное программирование в KOLIBRI OS
Upgrade component edit_box
; <Lrz> 15.02.2007 улучшение снятия выделения и перерисовки очищаемой области, значительно приятнее работает компонент
; <Lrz> 15.02.2007 улучшение снятия выделения и перерисовки очищаемой области, значительно приятнее работает компонент
Lrz есть предложение. Пока программ, использующих editbox немного (run, screenshoot, rdsave). Поэтому чтобы избежать путаницы, может ты бы обновлял компонент сразу во всех этих программах на svn?
Есть рациональное предложение, в каждой программе использующей edit_box прописать путь
include '../../../develop/examples/editbox/trunk/editbox.inc' к edit_box. Это избавит от наличия разных копий компонента и уменьшит код.
include '../../../develop/examples/editbox/trunk/editbox.inc' к edit_box. Это избавит от наличия разных копий компонента и уменьшит код.
А может сделать что-то типа include '%kolibri_editbox%/editbox.inc' и задавать эту переменную окружения при сборке? Такая практика, в принципе, применима ко всем компонентам.
Это будет правильнее ))
Есть пара предложений по editbox:
* сделать выделение текста мышью, а не только shift + стрелки
* будет лучше, если щелчок мыши по эдитбоксу будет снимать выделение
* сделать выделение текста мышью, а не только shift + стрелки
* будет лучше, если щелчок мыши по эдитбоксу будет снимать выделение
В каких то проектах видел с помощью средств svn импортируют в проект сторонние файлы. Может лучше так делать? (за подробностями к ману, я не в курсе как )
Heavyiron
Планируется сделать в дальнейшем. Пока необходимо устранить существуеющие баги и оформить код.
Планируется сделать в дальнейшем. Пока необходимо устранить существуеющие баги и оформить код.
У нас с Lrz возник вопрос, какой код будет работать быстрее.
Этот (используется в radiobutton):
Этот (используется в radiobutton):
Или этот (я предложил в качестве альтернативного):mov eax,38 ;рисование линии
movzx ebx,word op_left ;положение по х
mov ecx,ebx ;сохраним в регистре cx значение bx 1 микрооперация
shl ebx,16 ;сдвинем на 16 разрядов в лево (умножим на 65536)
mov bx,cx ;восстановим значение bx
movzx ecx,word op_top ;загрузим в cx значение y
mov esi,ecx ;сохраним значение регистра cx в регистр указатель si
shl ecx,16 ; сдвинем на 16 разрядов в лево (умножим на 65536)
mov cx,si ;восстановим значение регистра cx
mov cx,si ;восстановим значение регистра cx
add ecx,op_size ;[координата начала по оси y]*65536 + [координата конца по оси y]
mov edx,dword op_border_color ;Цвет линии
int 0x40 ;рисование вертикальной левой линии квадрата (прямоугольника)
;
mov ebp,ebx ;сохраним регистр bx в регистре указателя базы
add ebx,op_size ;[координата начала + длина стороны по оси х]
ror ebx,16 ;[координата начала + дина стороны по оси х]*65536
add ebx,op_size ;[координата начала+длина стороны по оси х]*65536 + [координата начала+длина стороны по оси x]
int 0x40
mov bx,bp ;восстановим значение регистра bx
mov cx,si ;сохраним значение регистра cx в регистр указатель
int 0x40
add ecx,op_size ;добавим размер стороны
mov esi,ecx ;сохраним значение регистра cx в регистр указатель si
shl ecx,16
mov cx,si
int 0x40 ;нарисовали прямоугольник
mov eax,13 ;закрашиваем его. Функция 13 - нарисовать полосу
movzx ebx,word op_left ;загрузить в bx, положение по х
add ebx,1 ;сдвинем на 1 т.е. прибавим 1 иначе затрется рамка
shl ebx,16 ;сдвинем на 16 разрядов в лево (умножим на 65536)
mov bx,op_size ;прибавим длину стороны прямоугольника
sub ebx,1 ;вычтем 1 т.к. иначе затрется рамка
mov bp,bx ;сохраним регистр bx в регистре указателя базы
movzx ecx,word op_top ;загрузим координаты по y
add ecx,1 ;сдвинем на 1 т.е. прибавим 1 иначе затрется рамка
shl ecx,16 ;сдвинем на 16 разрядов в лево (умножим на 65536)
mov cx,bp ;восстановим значение регистра cx
mov edx,dword [sc.work] ;загрузим цвет полосы
int 0x40 ;закрасили
По размеру второй вариант получше, но как со скоростью?mov eax, 13
mov ebx, op_left
shl ebx, 16
add ebx, op_size
mov ecx, op_top
shl ecx, 16
add ecx, op_size
mov edx, op_border_color
int 0x40 ;рисуем рамку
mov edx,[sc.work]
add ebx, 1 shl 16 - 2
add ecx, 1 shl 16 - 2
int 0x40 ;закрашиваем внутренности чекбокса
Возможно что второй вариант будет быстрее. Чекбоксы маленькие и отрисовка двух маленьких прямоугольников может быть быстрее чем накладные расходы на вызовы ядра. Если бы была аппаратная отрисовка то второй вариант был бы стопроцентно быстрее.
Heavyiron
Можно выполнить каждый код N раз, замерить время до и после mcall 26,9 и поделить на N. N лучше брать как можно больше.
Правда как показал мой опыт (отлаживал KFM) отдельно взятый участок кода в тестовом приложении и в рабочем приложении может иметь разную скорость, поскольку появляются дополнительные факторы, влияющие на скорость.
Можно выполнить каждый код N раз, замерить время до и после mcall 26,9 и поделить на N. N лучше брать как можно больше.
Правда как показал мой опыт (отлаживал KFM) отдельно взятый участок кода в тестовом приложении и в рабочем приложении может иметь разную скорость, поскольку появляются дополнительные факторы, влияющие на скорость.
http://lrz.land.ru/ обновил компонент editbox. Доступен так же на svn.
Полностью переписал структуру управлениния выделения с shift. Как видно из даты ушло на это около месяца, достаточно уложнился алгоритм, заодно пофиксил баги. Есть одна особенность. В буфере необходимо выделять на 2 символа больше чем возможно внести в буфер, иначе происходит затираниие следующего байта, после буфера.
Эта версия почти не мигающая, т.е. происходит расчет того что нужно нарисовать, и что удалить.
Как всегда рад критике и предложениям.
Полностью переписал структуру управлениния выделения с shift. Как видно из даты ушло на это около месяца, достаточно уложнился алгоритм, заодно пофиксил баги. Есть одна особенность. В буфере необходимо выделять на 2 символа больше чем возможно внести в буфер, иначе происходит затираниие следующего байта, после буфера.
Эта версия почти не мигающая, т.е. происходит расчет того что нужно нарисовать, и что удалить.
Как всегда рад критике и предложениям.
<Lrz>
Мне лично нужно, чтобы компонент использовал предустановленный текст, например путь к файлу. В текущем варианте это не получается. Текст почему-то затирается.
Мне лично нужно, чтобы компонент использовал предустановленный текст, например путь к файлу. В текущем варианте это не получается. Текст почему-то затирается.
Who is online
Users browsing this forum: No registered users and 5 guests