box_lib.obj - библиотека gui компонентов

Discussing libraries simplifying applications development
  • Там вон viewtopic.php?f=9&t=2122&p=66983#p66982 перестало работать.
    Предположительно из-за этого изменения http://websvn.kolibrios.org/filedetails ... 75#line-28
  • Pathoswithin wrote:А в чём магия? Что мой код всего лишь на строчку короче? Ну да, компиляторы неплохо оптимизируют код... нормальный код, без ООП.
    Я ошибся - код одинаковый, по 11 команд.
    И у компилятора тоже есть неочевидная для меня

    Code: Select all

    lea   eax, DWORD PTR [eax+eax*2]
    Так что счет равный.

    Влил ToolTip и пример использования в библиотеку.
    В исходниках - полезная для будущих компонент фича для использования структур в асме.
    Spoiler:

    Code: Select all

    Пишем один раз описание структуры
    struc tooltip txt, next, zone_x, zone_w, zone_y, zone_h, col_txt, col_bkg, tm_wait
    {
        .txt     dd  txt   ; указатель на текст asciiz, разделитель \r 13
        .next    dd  next	; следующиий tooltip в цепочке или 0
        .zone_y  dw  zone_y   ; зона контроля (в 90% случаев совпадает с размером контрола)
        .zone_x  dw  zone_x   ;
        .zone_h  dw  zone_h   ;
        .zone_w  dw  zone_w   ;
        .col_txt dd  col_txt   ; цвет текста тултипа, включая размер SysFn4
        .col_bkg dd  col_bkg   ; цвет фона тултипа
        .tm_wait dw  tm_wait   ; время ожидания х10мс
    ;временные переменные
        .font_sz dd  ?   ; font size
        .mouse   dd  ?   ; предыдущее положение (x, y)
        .tm_strt dd  ?   ; время запуска таймера (входа мыши в зону) х10мс
        .video   dd  ?   ; память для сохраненного под тултипом
        .video_y dw  ?    ; координаты запомненной области экрана, или 0 если пусто
        .video_x dw  ?
        .video_h dw  ?    ; размер предрасчитывается при init
        .video_w dw  ?
    }
    
    virtual at edi
    	ttip tooltip ?, ?, ?, ?, ?, ?, ?, ?, ?
    end virtual
    
    Потом используем 
        mov edi, [ttip] ;  регистр смещения указанный в virtual
       обращаемся просто 
        mov [ttip.mouse], 0
       ...
        stdcall get_font_size, [ttip.col_txt]
    итп
    
  • Siemargl, молодец, конечно, что старался.
    Но это всё-таки не совсем tooltip получился.
    Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.
    Ну ничего, в принципе, как пример это можно оставить.
    Как только появится время, постараюсь добавить нормальный ToolTip.
    В исходниках - полезная для будущих компонент фича для использования структур в асме.
    кстати, можно нормально пользоваться структурами в асм через virtual директиву. см новый тултип
    Америку открыл, да? :lol:
  • Насчёт editbox-a.
    Думаю, лучше было взять дополнительные байты из "внутренних" переменных, таких как, например, ed_shift_pos, ed_shift_pos_old, cl_curs_x, cl_curs_y. Потому как реально там не нужно по 4 байта. Сами эти переменные можно сдвинуть в памяти, они же внутренние, их никто кроме самого editbox-а не использует. Так что, это ещё и экономия памяти.
  • 0CodErr wrote:Siemargl, молодец, конечно, что старался.
    Но это всё-таки не совсем tooltip получился.
    Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.
    Дизайнер есть, насоветует - рисовку улучшим.
    0CodErr wrote:
    В исходниках - полезная для будущих компонент фича для использования структур в асме.
    кстати, можно нормально пользоваться структурами в асм через virtual директиву. см новый тултип
    Америку открыл, да? :lol:
    Судя по коду бокс_либ и твоим проблемам с байтами - таки открыл )
  • Siemargl, посчитай ещё раз.
    Мой код (без "магии"):

    Code: Select all

            mov     ecx,ed_text_color
            mov     ebx,ecx
            shr     ecx,28
            shr     ebx,24
            and     ebx,7
            inc     ebx
            mov     eax,6
            jecxz   @f
            mov     al, 8
    @@:
            mul     bl
    Впрочем, мерятся с компилятором всё равно что играть с ботами...
  • Так нечестно - ты сейчас выкинул and c маской и у тебя jecx отработает при любых старших битах, например asciiz.

    В целом я и не спорю, что ручная оптимизация лучше, да и компилятор иногда такое нарисует (особо относится к gcc),
    а поинт был в том, что если уж писать асм руками, то делать это понятным для человека.

    Раз пошла такая пьянка, вот ресурс, позволяющий оценить, что напишет бот-компилятор для примера, с выбором ботов. А потом уже можно и напильником.
    AFAIK, компиляторы пока сами не умеют хорошо использовать SSE.
  • and dword ed_text_color,17FFFFFFh - это общая валидация для всего editbox, она нужна в обоих случаях.

    А ещё, компиляторы не умеют использовать rep movs, lods, stos...
    Last edited by Pathoswithin on Tue Nov 08, 2016 2:01 pm, edited 1 time in total.
  • Хорошо, я сам это сделаю тогда viewtopic.php?f=24&t=1220&p=67000#p66992
    Никто ведь не против сохранения обратной совместимости? :)
    Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.
  • Pathoswithin wrote:and dword ed_text_color,17FFFFFFh - это общая валидация для всего editbox, она нужна в обоих случаях.
    А ещё, компиляторы не умеют использовать rep movs, lods, stos...
    В данном случае нет. Компилятор тестирует конкретный бит.
    0CodErr wrote:Хорошо, я сам это сделаю тогда viewtopic.php?f=24&t=1220&p=67000#p66992
    Никто ведь не против сохранения обратной совместимости? :)
    Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.
    Я против - ты поломаешь C-Layer, а у gcc какие то болячки с отключением выравнивания в структурах. Еще потом с байтами трахаться (со словами не придется).
    Лучше исправить поломавшиеся программы на нормальный код с родными бокс_либовскими макросами
    Last edited by Siemargl on Thu Nov 10, 2016 11:37 am, edited 1 time in total.
  • Siemargl ух кокой толстый тролинг :lol:
    Кому не нравится обратная совместимость, могут смело форкать проект.
  • Проверил. Экономия 12 байт в структуре стоит дополнительных 32 байта в коде из-за префикса размера у не 32-битных команд в 32-битном режиме.
  • Pathoswithin, ты собираешься исправлять или как?
    Экономия 12 байт в структуре стоит дополнительных 32 байта в коде
    А ты сейчас серьёзно насчёт экономии памяти?
    Тогда я тебе тоже сейчас серьёзно и отвечу.
    Для трёх EditBox-ов экономия составит уже 12 * 3 = 36 байт, в то время как в коде BoxLib это будут по-прежнему те же самые 32 байта.
    Siemargl wrote:Я против - ты поломаешь C-Layer
    Отвечу тебе твоими же словами. Тебе нужно всего-то
    Siemargl wrote:исправить поломавшиеся программы на нормальный код с родными бокс_либовскими макросами
    То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm :mrgreen:

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

    Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.

    Вообще, хотелось бы по этому поводу комментариев администрации. Я считаю, что такое положение дел это ну никак нормальным назвать нельзя. А представьте, что проблемы с совместимостью возникли бы у гораздо большего количества разработчиков, например 20-30?

    Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
  • Еще и скорость обращения к полусловам наверное тоже ниже, хотя для интерфейсной части это вряд ли критично.

    >То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm
    Именно. Автосборка системы решает эту проблему, а fasm - стандартный для системы транслятор. Новая версия системных библиотек тянет за собой требование к тестированию и/или обновлению юзер-программ, это всегда и везде так.

    >Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.
    В С-- структура уже исправлена (т.е.WebView и Eolite вычеркиваем), остальные можешь проверить и сказать, поломались или нет )

    >Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
    Такая идеология в static linux http://sta.li
  • Who is online

    Users browsing this forum: No registered users and 4 guests