Общесистемные горячие клавиши

Applications development, KoOS API questions
  • SoUrcerer wrote:Я так понимаю, там общесистемные горячие клавиши не посылаются всем-всем приложениям.
    Если бы все было так просто. В том же Шиндошс я не замечал залипания клавиш в FAR, при использовании Alt+Tab.
  • Ты про следующую ситуацию, да?
    1) Нажат Alt
    2) Сообщение о нажатии отправлено всем
    3) Нажат tab, переключение произошло, нажатие Tab не отправлено никому

    Событие отжатия Alt не отправляется никому - залипание. Так почему бы не отправить событие отжатия всех кнопок комбинации всем приложениям, если оно действительно произошло?
  • Если приложение не зарезервировало для себя какую либо клавишу как "горячую", то после того как активным станет другой поток буфер клавиатуры по умолчанию будет принадлежать ему. Ядро не может знать кому нужно событие отжатия, а кому нет, если приложение заранее не внесло себя в список.
  • Событие нажатия alt (ctrl,shift) приходит всем или только активному окну?
  • Если все читать через функцию 2, то только активному окну, кроме приложений заранее установивших себе alt (ctrl,shift) как "горячие".
    Однако следует учесть, что общее количество горячих комбинаций ограничено и злоупотреблять их использованием не стоит, потому что обработка большого списка займет слишком много времени и система станет еще менее отзывчивой (здравствуй Квейк!).

    Использование же функции 66.3 не удачное решение. Это увеличит нагрузку на систему, если периодически опрашивать состояние (прощай ф.10), либо можно "прозевать" изменение состояния, если вызывать ф.66.3 сразу после ф.2.
    Last edited by Mario on Wed May 30, 2012 11:30 pm, edited 1 time in total.
  • И после активизации приложения, получающего нажатие "горячей комбинации", прошлое активное приложение не получает событие отжатия. Почему не отправлять отжатие до активизации этого нового приложения?
  • А ты видел код обработчика клавиатуры? Если ты сможешь это сделать, то будешь охуенным программистом.
    А вообще проблема в том, что когда приложение считывает функцией 2 код обычной клавиши, оно очищает буфер клавиатуры и никаких "горячих" комбинаций уже не появится. Потому сначала "горячие" комбинации, а потом уже активное приложение.
  • Что-то я ничего не понял. На трезвую голову посмотрю код обработчика клавиатуры. Здравый смысл подсказывает мне, что можно сделать все правильно и красиво.
  • SoUrcerer wrote:Здравый смысл подсказывает мне, что можно сделать все правильно и красиво.
    Ага, а еще есть идеальный мир в котором находится эталонный код (который правильный, красивый и не содержит ошибок), а то что у нас это неудачные копии того кода.
  • Mario wrote:Кроме выше описанных проблем обнаружилась еще одна проблема - при пользовании mousemul управляющие клавиши (стрелки и 5) срабатывают на активном приложении. У меня нет идей как побороть эту ситуацию, если никто не предложит метод решения, то придется откатить ревизию 2611 и закопать мамонта обратно. Черт с ним с залипанием Shift, Ctrl, Alt - благими намерениями вымощена дорога сами знаете куда.
    Откатить все таки не получится. Если приложению не возвращать код назначенный на горячую клавишу (кстати реализация именно горячих клавиш, а не комбинаций сделана, потому и проблемы возникаю имхается мне), то при назначении горячих комбинаций типа Win (Ctrl, Alt, Shift) + символьная клавиша (в нашем случае R и D) приводит к тому что они становятся недоступными для обычного ввода. Раньше такие комбинации не использовались (назначение символьных клавиш в качестве горячих), потому эта недоработка реализации SVN r.92 не была заметна. С введением же новых горячих комбинаций проблема вылезла во всей красе.
  • Поскольку приложение MOUSEMUL имеет уникальный статус, то я ввел новую пару функций 66.6 и 66.7, для решения проблемы. SVN r. 2709, 2710
  • Похоже есть баг: f66.3 не присылает комбинации с альтом.

    В аттаче приложение: исходник на православном асме и бинарник.
    Логика приложения проста: если f66.3 что-то вернула - выход если пусто, продолжает работу.
    Spoiler:

    Code: Select all

      use32              ; включить 32-битный режим ассемблера
      org    0           ; адресация с нуля
    
      db     'MENUET01'  ; 8-байтный идентификатор MenuetOS
      dd     1           ; версия заголовка (1 либо 2, см. док-ю)
      dd     START       ; адрес первой команды
      dd     I_END       ; размер программы
      dd     MEM         ; количество памяти
      dd     STACKTOP    ; адрес вершины стэка
      dd     0
      dd     0
    
    include "macros.inc"
    
    START:
    
    red:
       call draw_window
    
    still:
        mcall 10
    
        cmp  eax,1  
        je   red 
        cmp  eax,2 
        je   key 
        cmp  eax,3
        je   exit
    
        jmp  still 
    
    
    ;---------------------------------------------------------------------
    
    
      key: 
        mcall 2 
    
        mcall 66, 3
        test eax,0    <------------ мякотка тут
        jne still
      exit:
        mcall -1
    
        jmp  still          ; вернуться к началу цикла
    
    draw_window:
        mcall 12, 1       ; функция 12: сообщить ОС о начале отрисовки
        mcall 0, <200,500>, <400,150>, 0x33FFFfff, ,title
        mcall 4, <5, 20>, 0x90000000, message
        mcall 12, 2                  ; функция 12.2, закончили рисовать
        ret                          ; выходим из процедуры
    
    message db 'Любая клавиша закроет окно, кроме Альта и комбинаций с ним.',0
    title db 'f66.3',0
    
    I_END:                  ; метка конца программы
      rb 4096               ; память для стека
    align 16
    STACKTOP:
    MEM:
    Ctrl+1, Ctrl+f, Shift+P, Shift+4 - Выход
    Alt+n - продолжает работать

    Баг?
    Attachments
    EXAMPLE.ASM (1.16 KiB)
    Downloaded 142 times
    EXAMPLE (240 Bytes)
    Downloaded 143 times
    Из хаоса в космос
  • Code: Select all

    test eax,0
    This always sets zero flag because AND X, 0 is always 0. Therefore the following JNE branch is never taken. Hence mcall -1 is always executed when a key event is received by a program.

    The reason why Alt+letter keys are not sent to the program is that
    1. Programs expect ASCII codes by default, not scan codes, and
    2. /programs/system/taskbar/trunk/KEYMAP.KEY file doesn't mention any ASCII codes for Alt+letter keys. So the kernel doesn't send any event to the program.

    In addition, Alt+number keys are global hotkeys to change keyboard layout.

    I can think of two solutions:
    1. Add ASCII codes to Alt+letter keys to the keymap file. This way Alt+letter will also put characters to editboxes, is it desirable behavior?
    2. Switch the program to receive scan codes.
  • Hmm... Looks like I have to use scan codes.
    Thanks a lot for investigation!
    Из хаоса в космос
  • Who is online

    Users browsing this forum: No registered users and 6 guests