Облегчение программинга GUI-приложений взамен на ...

Find out what others think about your ideas

POLL Итак, Вы

Total votes: 53
За идею
91%
48
Против идеи
9%
5

  • SCRSHOOT и RUN я переделаю сам.
    Не помешала бы еще функция, ограничивающая область рисования в окне.
  • Идея хорошая. Но может лучше добавить новые функции API не меняя старые и так обеспечить совместимость.
  • Serge
    Думаю не стоит особо беспокоиться, так как "пострадают" только приложения, использующие скин ;)
  • mistifi(ator
    А сколько таких приложений ?
  • mistifi(ator
    Я против жесткого отсутствия доступа к этой области.
    Я согласен с предложением Serge'а.
    Я за то чтобы можно было определять местоположение начальной точки вывода специальной функцией.
    Пусть изначально расположение точки вывода и начало окна совпадают, а функцией их можно изменить.
    Такой подход гибче.
    А поскольку такого пункта нет в топике голосования, то я относительно текущего голосования воздержусь.
  • Согласен с Mario79. Пусть новые программы устанавливают способ отрисовки, а для остальных сохраняется старый по умолчанию.
  • Хочу немного прояснить ситуацию.
    Новый стиль как таковой не вводится. Он заменит собой стиль №0 (окно с рамкой в 1 пиксель и неизменяемым размером), так как этот стиль используется от силы в двух-трёх программах.
    Введение функции для определения так называемой точки отсчёта координат мне не нравится. Я не могу себе представить, где это можно использовать, а если и можно, то сейчас это не нужно. А вот когда станет нужно, то координаты этой точки будут задаваться относительно клиентской области.
    Касаемо "недоступности" заголовка. Эти страхи совершенно беспочвенны. Хотя я и не считаю, что какой-либо программе нужно будет что-то рисовать на заголовке (учитывая, что до сегодняшнего дня программы там рисовали от силы кнопку закрытия и строку заголовка, которые после внесения изменений будут рисоваться самом системой), такая возможность будет существовать. Может быть никто и подумать об этом не может (что и неудивительно за столько лет), но это будет возможно реализовать с использованием отрицательных координат при рисовании.

    Итого:
    - стиль окон №0 заменяется на новый;
    - старые программы, использующие стиль №0, переписываются, как, собственно, и все остальные; занимается этим инициативная группа;
    - добавляется функция установки заголовка окна; это позволяет изменять заголовок без перерисовки всего окна;
    - добавление функции установки точки начала координат считаю несвоевременным.
  • ИМХО, новый стиль внятней был бы. Всё ещё бета, но обратная совместимость не помешает ;)
  • Я с утра придумал, как мне кажется, лучшее решение. Заключается оно в том, что в функции №0 в регистре EDX не используется 3 бита. Таким образом, их можно задействовать для передачи ядру флагов управления отрисовкой окна.
    Два флага, которые интересуют нас на данный момент - вывод строки заголовка и рисование относительно клиентской области.
    Если установлен флаг отрисовки ядром заголовка окна, в ESI должен содержаться адрес нуль-терминированной строки заголовка. Заголовок можно будет сменить в любой момент с помощью дополнительной функции. Если на вход этой функции передастся 0 - заголовок рисоваться не будет.
    Если будет установлен флаг рисования относительно клиентской области, ко всем координатам, передаваемым в графические системные функции, будет прибавляться соответствующее смещение. Вероятно, в структуру информации о процессе будут добавлены 2 или 4 поля (координаты и размер клиентской области).
    Следует заметить, что второй флаг будет работать не только для окон стиля №3, но и для окон стилей №0 и №2. Первый - только для окон стиля №3. Для того, чтобы установить заголовок для окон стилей №0 и №2, нужно будет использовать дополнительную функцию, про которую я упомянул выше. Выставлять флаг при этом необязательно.
    Таким образом, обратная совместимость соблюдается, а новые программы можно писать намного комфортнее. Над теми, кто не будет выставлять эти два флага в единицы, лично я буду очень сильно смеяться.
  • 2mike
    +1
  • Я за то чтобы можно было определять местоположение начальной точки вывода специальной функцией.
    Это даст возможность писать универсальные процедуры для рисования GUI компонентов, каждая такая процедура будет рисовать начиная с (0, 0), а перед её вызовом просто перемещать относительные координаты.
    Идею с текстом заголовка давно нужно было реализовать, я за!
  • Надеюсь, ты понимаешь, что придётся вызывать эту функцию перед рисованием *каждого* компонента. Может это и облегчит рисование компонентов, но мне такой подход всё равно не нравится. Извините, но если кто-то и будет это реализовывать, это буду или не я, или я, но не сейчас.
  • Да, я с тобой согласен на счёт того что придётся вызывать эту функцию перед рисованием *каждого* компонента, но это наиболее гибкий вариант, а для того чтобы уменьшить код помогают таблици, например так (написал на скорую руку, могут быть ошибки) :

    Code: Select all

      mov esi, comp_data
      mov eax, func_num
    @@:  
      mov  ebx, [esi] ; not use in sys. call
      test  ebx, ebx
      jz @f
      mov  ecx, [esi + 4] ; new x coord
      mov  edx, [esi + 8] ; new y coord
      int  0x40
      call ebx
      add esi, 12
      jmp @b
    @@:
    
    
    ; other code
    ;........
    ;
    
    comp_data:
      dd component1 ; proc addr
      dd 10  ; X coord
      dd 10  ; Y coord
    
      dd component2
      dd 15
      dd 20
    
      dd 0
    
    ИМХО иначе получится как с курсором мыши : можно загнать в центр экрана но нельзя в произвольную точку, используется только при запуске...
  • mike.dld
    Функция, выводящая число, выводит его относительно края окна.
    Координаты мышки приложение получает относительно края окна.
    Необходимо сделать так, чтобы это тоже делалось относительно края клиентской области.
  • Who is online

    Users browsing this forum: No registered users and 34 guests